* how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
@ 2013-11-13 13:58 Stefan Priebe - Profihost AG
2013-11-13 14:12 ` Veaceslav Falico
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 13:58 UTC (permalink / raw)
To: Linux Netdev List
Hello,
while my vlans, bridging and bonding stuff was working until 3.9 i never
thought about how it is right. So maybe i was always wrong.
I've this:
eth2
\
-- bond1 -- vmbr1
/
eth3
This works fine and as expected now i want to have a vlan using the
bonding and using a bridge.
I the past i had this:
eth2
\
-- bond1 -- vmbr1
/ \
eth3 \ vmbr1.3000
\ ---- tap114i1
This was working fine until 3.9.X since 3.10. Right now using 3.10 i
need to put eth2 and eth3 into promisc mode to get it working ;-( this
is bad!
I also tried this one without success:
eth2
\
-- bond1 -- vmbr1
/ \
eth3 ----- bond1.3000 --- vmbr1v3000
\ ---- tap114i1
Greets,
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 13:58 how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10 Stefan Priebe - Profihost AG
@ 2013-11-13 14:12 ` Veaceslav Falico
2013-11-13 14:20 ` Stefan Priebe - Profihost AG
0 siblings, 1 reply; 28+ messages in thread
From: Veaceslav Falico @ 2013-11-13 14:12 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG wrote:
>Hello,
>
>while my vlans, bridging and bonding stuff was working until 3.9 i never
>thought about how it is right. So maybe i was always wrong.
>
>I've this:
>
>eth2
> \
> -- bond1 -- vmbr1
> /
>eth3
>
>This works fine and as expected now i want to have a vlan using the
>bonding and using a bridge.
>
>I the past i had this:
>eth2
> \
> -- bond1 -- vmbr1
> / \
>eth3 \ vmbr1.3000
> \ ---- tap114i1
>
>This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>need to put eth2 and eth3 into promisc mode to get it working ;-( this
>is bad!
As a guess - do you use arp monitoring for bonding? Try using miimon -
there were some issues with it in 3.10, which were fixed by some huge
patchsets that will never hit 3.10 stable.
Also, the bonding configuration would be welcome.
>
>I also tried this one without success:
>eth2
> \
> -- bond1 -- vmbr1
> / \
>eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
>
>
>
>Greets,
>Stefan
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 14:12 ` Veaceslav Falico
@ 2013-11-13 14:20 ` Stefan Priebe - Profihost AG
2013-11-13 14:34 ` Veaceslav Falico
2013-11-13 15:05 ` Vlad Yasevich
0 siblings, 2 replies; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:20 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
Hi Falico,
Am 13.11.2013 15:12, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>> thought about how it is right. So maybe i was always wrong.
>>
>> I've this:
>>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> /
>> eth3
>>
>> This works fine and as expected now i want to have a vlan using the
>> bonding and using a bridge.
>>
>> I the past i had this:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>>
>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>> is bad!
>
> As a guess - do you use arp monitoring for bonding? Try using miimon -
> there were some issues with it in 3.10, which were fixed by some huge
> patchsets that will never hit 3.10 stable.
> Also, the bonding configuration would be welcome.
Debian Bonding konfiguration looks like this:
auto bond1
iface bond1 inet manual
slaves eth2 eth3
bond-mode 802.3ad
bond_miimon 100
bond_updelay 200
bond_downdelay 0
This should be miimon using lacp and not arp isn't it?
Anything more needed?
One thing i forgot the one with vmbr1.3000 does not work at all eben not
with promisc mode. The one below works fine if i set eth2 and eth3 into
promisc mode.
Stefan
>> I also tried this one without success:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>>
>>
>>
>> Greets,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 14:20 ` Stefan Priebe - Profihost AG
@ 2013-11-13 14:34 ` Veaceslav Falico
2013-11-13 14:43 ` Stefan Priebe - Profihost AG
2013-11-13 15:05 ` Vlad Yasevich
1 sibling, 1 reply; 28+ messages in thread
From: Veaceslav Falico @ 2013-11-13 14:34 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG wrote:
>Hi Falico,
>Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
>Debian Bonding konfiguration looks like this:
>auto bond1
>iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
>This should be miimon using lacp and not arp isn't it?
>Anything more needed?
Yeah, it's miimon, so nothing here...
I'll try to set up a reproducer in the nearest future, a bit burdened now.
Are you using 3.10.X stable? Which version exactly? And at what version did
it work - 3.9.?
Thank you!
>
>One thing i forgot the one with vmbr1.3000 does not work at all eben not
>with promisc mode. The one below works fine if i set eth2 and eth3 into
>promisc mode.
>
>Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 14:34 ` Veaceslav Falico
@ 2013-11-13 14:43 ` Stefan Priebe - Profihost AG
0 siblings, 0 replies; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 14:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Linux Netdev List
Am 13.11.2013 15:34, schrieb Veaceslav Falico:
> On Wed, Nov 13, 2013 at 03:20:56PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>
> Yeah, it's miimon, so nothing here...
>
> I'll try to set up a reproducer in the nearest future, a bit burdened now.
>
> Are you using 3.10.X stable? Which version exactly? And at what version did
> it work - 3.9.?
I'm using 3.10.19 + this patchset from v3.12 (commit
b8bde1c4f94908ce8e3c0434fb369a00e9217497
Merge: 4b6c787 dfb5fa3
Author: David S. Miller <davem@davemloft.net>
Date: Fri Oct 18 16:03:03 2013 -0400
Merge branch 'bridge_pvid'
)
The problem is simply that the network cards and also the bonds do not
seem to know about the bridge on top so they just drop the vlan tagged
packages.
> Thank you!
>
>>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 14:20 ` Stefan Priebe - Profihost AG
2013-11-13 14:34 ` Veaceslav Falico
@ 2013-11-13 15:05 ` Vlad Yasevich
2013-11-13 15:17 ` Stefan Priebe - Profihost AG
1 sibling, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-13 15:05 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico; +Cc: Linux Netdev List
On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
> Hi Falico,
> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hello,
>>>
>>> while my vlans, bridging and bonding stuff was working until 3.9 i never
>>> thought about how it is right. So maybe i was always wrong.
>>>
>>> I've this:
>>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> /
>>> eth3
>>>
>>> This works fine and as expected now i want to have a vlan using the
>>> bonding and using a bridge.
>>>
>>> I the past i had this:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>>
>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>> is bad!
>>
>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>> there were some issues with it in 3.10, which were fixed by some huge
>> patchsets that will never hit 3.10 stable.
>> Also, the bonding configuration would be welcome.
>
> Debian Bonding konfiguration looks like this:
> auto bond1
> iface bond1 inet manual
> slaves eth2 eth3
> bond-mode 802.3ad
> bond_miimon 100
> bond_updelay 200
> bond_downdelay 0
>
> This should be miimon using lacp and not arp isn't it?
> Anything more needed?
>
Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
bond should place all of its ports into promiscuous mode. Do you see
the the kernel messages that say that?
-vlad
> One thing i forgot the one with vmbr1.3000 does not work at all eben not
> with promisc mode. The one below works fine if i set eth2 and eth3 into
> promisc mode.
>
> Stefan
>
>>> I also tried this one without success:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>>
>>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 15:05 ` Vlad Yasevich
@ 2013-11-13 15:17 ` Stefan Priebe - Profihost AG
2013-11-13 16:21 ` Veaceslav Falico
2013-11-13 16:44 ` Vlad Yasevich
0 siblings, 2 replies; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 15:17 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
Am 13.11.2013 16:05, schrieb Vlad Yasevich:
> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Falico,
>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Hello,
>>>>
>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>> never
>>>> thought about how it is right. So maybe i was always wrong.
>>>>
>>>> I've this:
>>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> /
>>>> eth3
>>>>
>>>> This works fine and as expected now i want to have a vlan using the
>>>> bonding and using a bridge.
>>>>
>>>> I the past i had this:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>>
>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>> is bad!
>>>
>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>> there were some issues with it in 3.10, which were fixed by some huge
>>> patchsets that will never hit 3.10 stable.
>>> Also, the bonding configuration would be welcome.
>>
>> Debian Bonding konfiguration looks like this:
>> auto bond1
>> iface bond1 inet manual
>> slaves eth2 eth3
>> bond-mode 802.3ad
>> bond_miimon 100
>> bond_updelay 200
>> bond_downdelay 0
>>
>> This should be miimon using lacp and not arp isn't it?
>> Anything more needed?
>>
>
> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
> bond should place all of its ports into promiscuous mode. Do you see
> the the kernel messages that say that?
No it does not - i only see:
# dmesg -c|egrep "promiscuous|forward"
[ 5.445161] device bond0 entered promiscuous mode
[ 7.670701] device bond1 entered promiscuous mode
[ 7.845472] vmbr0: port 1(bond0) entered forwarding state
[ 7.845474] vmbr0: port 1(bond0) entered forwarding state
[ 8.269769] vmbr1: port 1(bond1) entered forwarding state
[ 8.269771] vmbr1: port 1(bond1) entered forwarding state
Now adding variant 1:
# dmesg -c|egrep "promiscuous|forward"
[ 85.919382] device tap113i0 entered promiscuous mode
[ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
[ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
[ 86.263292] device tap113i1 entered promiscuous mode
[ 86.314151] device vmbr1.3000 entered promiscuous mode
[ 86.314153] device vmbr1 entered promiscuous mode
[ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
[ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
Now it looks like this:
# ip a l|grep PROMISC
13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr0 state UNKNOWN qlen 500
14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr1v3000 state UNKNOWN qlen 500
Greets,
Stefan
Main question is - is this one correct:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
<= does not work at all
or this one?:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
<= works if i manually put eth2 and eth3 into promiscous mode.
> -vlad
>
>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>> promisc mode.
>>
>> Stefan
>>
>>>> I also tried this one without success:
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>>
>>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 15:17 ` Stefan Priebe - Profihost AG
@ 2013-11-13 16:21 ` Veaceslav Falico
2013-11-13 16:43 ` Stefan Priebe - Profihost AG
2013-11-13 17:21 ` Vlad Yasevich
2013-11-13 16:44 ` Vlad Yasevich
1 sibling, 2 replies; 28+ messages in thread
From: Veaceslav Falico @ 2013-11-13 16:21 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Vlad Yasevich, Linux Netdev List
On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG wrote:
>Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi Falico,
>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>> never
>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>
>>>>> I've this:
>>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> /
>>>>> eth3
>>>>>
>>>>> This works fine and as expected now i want to have a vlan using the
>>>>> bonding and using a bridge.
>>>>>
>>>>> I the past i had this:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>>>>>
>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>> is bad!
>>>>
>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>> patchsets that will never hit 3.10 stable.
>>>> Also, the bonding configuration would be welcome.
>>>
>>> Debian Bonding konfiguration looks like this:
>>> auto bond1
>>> iface bond1 inet manual
>>> slaves eth2 eth3
>>> bond-mode 802.3ad
>>> bond_miimon 100
>>> bond_updelay 200
>>> bond_downdelay 0
>>>
>>> This should be miimon using lacp and not arp isn't it?
>>> Anything more needed?
>>>
>>
>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>> bond should place all of its ports into promiscuous mode. Do you see
>> the the kernel messages that say that?
>
>No it does not - i only see:
># dmesg -c|egrep "promiscuous|forward"
>[ 5.445161] device bond0 entered promiscuous mode
>[ 7.670701] device bond1 entered promiscuous mode
>[ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>[ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>[ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>[ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>
>Now adding variant 1:
># dmesg -c|egrep "promiscuous|forward"
>[ 85.919382] device tap113i0 entered promiscuous mode
>[ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>[ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>[ 86.263292] device tap113i1 entered promiscuous mode
>[ 86.314151] device vmbr1.3000 entered promiscuous mode
>[ 86.314153] device vmbr1 entered promiscuous mode
>[ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>[ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>[ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>[ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>[ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>
>Now it looks like this:
># ip a l|grep PROMISC
>13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>htb master vmbr0 state UNKNOWN qlen 500
>14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>htb master vmbr1v3000 state UNKNOWN qlen 500
eth* should get into forwarding mode cause bond0 is a port of the bridge
and should propagate its state towards its slaves. Something is wrong here.
Maybe we're looking at the wrong direction - and the promisc for the
ethernet drivers got broken?
What ethernet cards/driver do you use for eth*?
>
>Greets,
>Stefan
>
>
>Main question is - is this one correct:
Both are correct. Here's my setup (sorry for stretching):
+---------------+ +------------+ +-------------+ +---------+ +------+
| bond1 | | | | bridge0 | | | | |
| 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 | master | bond0 | master | eth2 |
| | --------> | | ------------ | 192.168.4.1 | --------> | | --------> | |
+---------------+ +------------+ +-------------+ +---------+ +------+
|
| master
v
+---------------+ +---------+
| dummy0 | | eth0 |
+---------------+ +---------+
(disregard that dummy0).
All 192.168.X.1 ips are pingable (via the correct vlans) on both net-next and stable 3.10.19.
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>
><= does not work at all
>
>or this one?:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>
><= works if i manually put eth2 and eth3 into promiscous mode.
>
>> -vlad
>>
>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>> promisc mode.
>>>
>>> Stefan
>>>
>>>>> I also tried this one without success:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>>>>>
>>>>>
>>>>>
>>>>> Greets,
>>>>> Stefan
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 16:21 ` Veaceslav Falico
@ 2013-11-13 16:43 ` Stefan Priebe - Profihost AG
2013-11-13 17:21 ` Vlad Yasevich
1 sibling, 0 replies; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 16:43 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Vlad Yasevich, Linux Netdev List
> Am 13.11.2013 um 17:21 schrieb Veaceslav Falico <vfalico@redhat.com>:
>
>> On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG wrote:
>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>> Hi Falico,
>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>> never
>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>
>>>>>> I've this:
>>>>>>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> /
>>>>>> eth3
>>>>>>
>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>> bonding and using a bridge.
>>>>>>
>>>>>> I the past i had this:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>>> is bad!
>>>>>
>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>> patchsets that will never hit 3.10 stable.
>>>>> Also, the bonding configuration would be welcome.
>>>>
>>>> Debian Bonding konfiguration looks like this:
>>>> auto bond1
>>>> iface bond1 inet manual
>>>> slaves eth2 eth3
>>>> bond-mode 802.3ad
>>>> bond_miimon 100
>>>> bond_updelay 200
>>>> bond_downdelay 0
>>>>
>>>> This should be miimon using lacp and not arp isn't it?
>>>> Anything more needed?
>>>
>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>> bond should place all of its ports into promiscuous mode. Do you see
>>> the the kernel messages that say that?
>>
>> No it does not - i only see:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 5.445161] device bond0 entered promiscuous mode
>> [ 7.670701] device bond1 entered promiscuous mode
>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>
>> Now adding variant 1:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 85.919382] device tap113i0 entered promiscuous mode
>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 86.263292] device tap113i1 entered promiscuous mode
>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>> [ 86.314153] device vmbr1 entered promiscuous mode
>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>
>> Now it looks like this:
>> # ip a l|grep PROMISC
>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr0 state UNKNOWN qlen 500
>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr1v3000 state UNKNOWN qlen 500
>
> eth* should get into forwarding mode cause bond0 is a port of the bridge
> and should propagate its state towards its slaves. Something is wrong here.
>
> Maybe we're looking at the wrong direction - and the promisc for the
> ethernet drivers got broken?
>
> What ethernet cards/driver do you use for eth*?
intel igb
>
>>
>> Greets,
>> Stefan
>>
>>
>> Main question is - is this one correct:
>
> Both are correct. Here's my setup (sorry for stretching):
>
> +---------------+ +------------+ +-------------+ +---------+ +------+
> | bond1 | | | | bridge0 | | | | |
> | 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 | master | bond0 | master | eth2 |
> | | --------> | | ------------ | 192.168.4.1 | --------> | | --------> | |
> +---------------+ +------------+ +-------------+ +---------+ +------+
> |
> | master
> v
> +---------------+ +---------+
> | dummy0 | | eth0 |
> +---------------+ +---------+
>
> (disregard that dummy0).
>
> All 192.168.X.1 ips are pingable (via the correct vlans) on both net-next and stable 3.10.19.
>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>
>> <= does not work at all
>>
>> or this one?:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>
>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>
>>> -vlad
>>>
>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>> promisc mode.
>>>>
>>>> Stefan
>>>>
>>>>>> I also tried this one without success:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Greets,
>>>>>> Stefan
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 15:17 ` Stefan Priebe - Profihost AG
2013-11-13 16:21 ` Veaceslav Falico
@ 2013-11-13 16:44 ` Vlad Yasevich
2013-11-13 17:22 ` Stefan Priebe - Profihost AG
1 sibling, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-13 16:44 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico; +Cc: Linux Netdev List
On 11/13/2013 10:17 AM, Stefan Priebe - Profihost AG wrote:
> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>> Hi Falico,
>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>> wrote:
>>>>> Hello,
>>>>>
>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>> never
>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>
>>>>> I've this:
>>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> /
>>>>> eth3
>>>>>
>>>>> This works fine and as expected now i want to have a vlan using the
>>>>> bonding and using a bridge.
>>>>>
>>>>> I the past i had this:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>>>>>
>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>> is bad!
>>>>
>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>> patchsets that will never hit 3.10 stable.
>>>> Also, the bonding configuration would be welcome.
>>>
>>> Debian Bonding konfiguration looks like this:
>>> auto bond1
>>> iface bond1 inet manual
>>> slaves eth2 eth3
>>> bond-mode 802.3ad
>>> bond_miimon 100
>>> bond_updelay 200
>>> bond_downdelay 0
>>>
>>> This should be miimon using lacp and not arp isn't it?
>>> Anything more needed?
>>>
>>
>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>> bond should place all of its ports into promiscuous mode. Do you see
>> the the kernel messages that say that?
>
> No it does not - i only see:
> # dmesg -c|egrep "promiscuous|forward"
> [ 5.445161] device bond0 entered promiscuous mode
> [ 7.670701] device bond1 entered promiscuous mode
> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>
So this can happen if bond interfaces are down at the time of joining
the bridge. The promisc flag propagation to lower interfaces only
happens when those interfaces are up. So if for whatever reason,
the lower interfaces happen to be down during the crating of this
hierarchy, the promiscuity flag may not get set on the lower level port
device an we may end up in this situation.
-vlad
> Now adding variant 1:
> # dmesg -c|egrep "promiscuous|forward"
> [ 85.919382] device tap113i0 entered promiscuous mode
> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
> [ 86.263292] device tap113i1 entered promiscuous mode
> [ 86.314151] device vmbr1.3000 entered promiscuous mode
> [ 86.314153] device vmbr1 entered promiscuous mode
> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>
> Now it looks like this:
> # ip a l|grep PROMISC
> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr0 state UNKNOWN qlen 500
> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr1v3000 state UNKNOWN qlen 500
>
> Greets,
> Stefan
>
>
> Main question is - is this one correct:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>
> <= does not work at all
>
> or this one?:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>
> <= works if i manually put eth2 and eth3 into promiscous mode.
>
>> -vlad
>>
>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>> promisc mode.
>>>
>>> Stefan
>>>
>>>>> I also tried this one without success:
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>>>>>
>>>>>
>>>>>
>>>>> Greets,
>>>>> Stefan
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 16:21 ` Veaceslav Falico
2013-11-13 16:43 ` Stefan Priebe - Profihost AG
@ 2013-11-13 17:21 ` Vlad Yasevich
2013-11-13 20:09 ` Stefan Priebe
1 sibling, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-13 17:21 UTC (permalink / raw)
To: Veaceslav Falico, Stefan Priebe - Profihost AG; +Cc: Linux Netdev List
On 11/13/2013 11:21 AM, Veaceslav Falico wrote:
> On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>> Hi Falico,
>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>> never
>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>
>>>>>> I've this:
>>>>>>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> /
>>>>>> eth3
>>>>>>
>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>> bonding and using a bridge.
>>>>>>
>>>>>> I the past i had this:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-(
>>>>>> this
>>>>>> is bad!
>>>>>
>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>> patchsets that will never hit 3.10 stable.
>>>>> Also, the bonding configuration would be welcome.
>>>>
>>>> Debian Bonding konfiguration looks like this:
>>>> auto bond1
>>>> iface bond1 inet manual
>>>> slaves eth2 eth3
>>>> bond-mode 802.3ad
>>>> bond_miimon 100
>>>> bond_updelay 200
>>>> bond_downdelay 0
>>>>
>>>> This should be miimon using lacp and not arp isn't it?
>>>> Anything more needed?
>>>>
>>>
>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>> bond should place all of its ports into promiscuous mode. Do you see
>>> the the kernel messages that say that?
>>
>> No it does not - i only see:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 5.445161] device bond0 entered promiscuous mode
>> [ 7.670701] device bond1 entered promiscuous mode
>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>
>> Now adding variant 1:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 85.919382] device tap113i0 entered promiscuous mode
>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 86.263292] device tap113i1 entered promiscuous mode
>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>> [ 86.314153] device vmbr1 entered promiscuous mode
>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>
>> Now it looks like this:
>> # ip a l|grep PROMISC
>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr0 state UNKNOWN qlen 500
>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr1v3000 state UNKNOWN qlen 500
>
> eth* should get into forwarding mode cause bond0 is a port of the bridge
> and should propagate its state towards its slaves. Something is wrong here.
>
> Maybe we're looking at the wrong direction - and the promisc for the
> ethernet drivers got broken?
I was able to duplicate Stefans results only when I turn off the link to
the underlying devices when building the bridge. When the link is off,
the rx_flags do not propagate down to the lower level devices.
What about something like this (completely untested)
diff --git a/drivers/net/bonding/bond_main.c
b/drivers/net/bonding/bond_main.c
index 4dd5ee2..3051744 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -2863,6 +2863,17 @@ static int bond_slave_netdev_event(unsigned long
event,
bond_release(bond_dev, slave_dev);
break;
case NETDEV_UP:
+ /* If the bond was set to primisc, but slave has not due to
+ * slave being down when the command was issued, sync the
+ * state when the slave comes up.
+ */
+ if (bond_dev->flags & IFF_PROMISC &&
!slave_dev->promiscuity) {
+ if (!USES_PRIMARY(bond))
+ dev_set_promiscuity(slave_dev, 1);
+ else if (slave == bond->curr_active_slave)
+ dev_set_promiscuity(slave_dev, 1);
+ }
+
case NETDEV_CHANGE:
old_speed = slave->speed;
old_duplex = slave->duplex;
-vlad
>
> What ethernet cards/driver do you use for eth*?
>
>>
>> Greets,
>> Stefan
>>
>>
>> Main question is - is this one correct:
>
> Both are correct. Here's my setup (sorry for stretching):
>
> +---------------+ +------------+
> +-------------+ +---------+ +------+
> | bond1 | | | | bridge0
> | | | | |
> | 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 |
> master | bond0 | master | eth2 |
> | | --------> | | ------------ | 192.168.4.1 |
> --------> | | --------> | |
> +---------------+ +------------+
> +-------------+ +---------+ +------+
> |
> | master
> v
> +---------------+
> +---------+
> | dummy0
> | |
> eth0 |
> +---------------+
> +---------+
>
> (disregard that dummy0).
>
> All 192.168.X.1 ips are pingable (via the correct vlans) on both
> net-next and stable 3.10.19.
>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>
>> <= does not work at all
>>
>> or this one?:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>
>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>
>>> -vlad
>>>
>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben
>>>> not
>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>> promisc mode.
>>>>
>>>> Stefan
>>>>
>>>>>> I also tried this one without success:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Greets,
>>>>>> Stefan
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 16:44 ` Vlad Yasevich
@ 2013-11-13 17:22 ` Stefan Priebe - Profihost AG
2013-11-13 17:37 ` Vlad Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 17:22 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Veaceslav Falico, Linux Netdev List
> Am 13.11.2013 um 17:44 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>
>> On 11/13/2013 10:17 AM, Stefan Priebe - Profihost AG wrote:
>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>> Hi Falico,
>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>> never
>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>
>>>>>> I've this:
>>>>>>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> /
>>>>>> eth3
>>>>>>
>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>> bonding and using a bridge.
>>>>>>
>>>>>> I the past i had this:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>>> is bad!
>>>>>
>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>> patchsets that will never hit 3.10 stable.
>>>>> Also, the bonding configuration would be welcome.
>>>>
>>>> Debian Bonding konfiguration looks like this:
>>>> auto bond1
>>>> iface bond1 inet manual
>>>> slaves eth2 eth3
>>>> bond-mode 802.3ad
>>>> bond_miimon 100
>>>> bond_updelay 200
>>>> bond_downdelay 0
>>>>
>>>> This should be miimon using lacp and not arp isn't it?
>>>> Anything more needed?
>>>
>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>> bond should place all of its ports into promiscuous mode. Do you see
>>> the the kernel messages that say that?
>>
>> No it does not - i only see:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 5.445161] device bond0 entered promiscuous mode
>> [ 7.670701] device bond1 entered promiscuous mode
>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>
> So this can happen if bond interfaces are down at the time of joining
> the bridge.
About which of my tried configuration do you speak? The bond itself is always up it's the internet connection. Or do you mean the vlan bond?
> The promisc flag propagation to lower interfaces only happens when those interfaces are up. So if for whatever reason,
> the lower interfaces happen to be down during the crating of this
> hierarchy, the promiscuity flag may not get set on the lower level port
> device an we may end up in this situation.
>
> -vlad
>
>> Now adding variant 1:
>> # dmesg -c|egrep "promiscuous|forward"
>> [ 85.919382] device tap113i0 entered promiscuous mode
>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>> [ 86.263292] device tap113i1 entered promiscuous mode
>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>> [ 86.314153] device vmbr1 entered promiscuous mode
>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>
>> Now it looks like this:
>> # ip a l|grep PROMISC
>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr0 state UNKNOWN qlen 500
>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>
>> Greets,
>> Stefan
>>
>>
>> Main question is - is this one correct:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>
>> <= does not work at all
>>
>> or this one?:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>
>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>
>>> -vlad
>>>
>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>> promisc mode.
>>>>
>>>> Stefan
>>>>
>>>>>> I also tried this one without success:
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>>>>>
>>>>>>
>>>>>>
>>>>>> Greets,
>>>>>> Stefan
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 17:22 ` Stefan Priebe - Profihost AG
@ 2013-11-13 17:37 ` Vlad Yasevich
2013-11-13 17:46 ` Stefan Priebe - Profihost AG
0 siblings, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-13 17:37 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Veaceslav Falico, Linux Netdev List
On 11/13/2013 12:22 PM, Stefan Priebe - Profihost AG wrote:
>
>> Am 13.11.2013 um 17:44 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>>
>>> On 11/13/2013 10:17 AM, Stefan Priebe - Profihost AG wrote:
>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Hi Falico,
>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>> never
>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>
>>>>>>> I've this:
>>>>>>>
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> /
>>>>>>> eth3
>>>>>>>
>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>> bonding and using a bridge.
>>>>>>>
>>>>>>> I the past i had this:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 \ vmbr1.3000
>>>>>>> \ ---- tap114i1
>>>>>>>
>>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>>>> is bad!
>>>>>>
>>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>>> patchsets that will never hit 3.10 stable.
>>>>>> Also, the bonding configuration would be welcome.
>>>>>
>>>>> Debian Bonding konfiguration looks like this:
>>>>> auto bond1
>>>>> iface bond1 inet manual
>>>>> slaves eth2 eth3
>>>>> bond-mode 802.3ad
>>>>> bond_miimon 100
>>>>> bond_updelay 200
>>>>> bond_downdelay 0
>>>>>
>>>>> This should be miimon using lacp and not arp isn't it?
>>>>> Anything more needed?
>>>>
>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>> the the kernel messages that say that?
>>>
>>> No it does not - i only see:
>>> # dmesg -c|egrep "promiscuous|forward"
>>> [ 5.445161] device bond0 entered promiscuous mode
>>> [ 7.670701] device bond1 entered promiscuous mode
>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>
>> So this can happen if bond interfaces are down at the time of joining
>> the bridge.
>
> About which of my tried configuration do you speak? The bond itself is always up it's the internet connection. Or do you mean the vlan bond?
>
The issue is in the formation for vmbr0 and vmbr1. When bond0 and
bond1 enter promisc mode as part of becoming a bridge port, they should
put some subset of their ports into promisc mode as well (in 802.3ad
mode it should happen on all bond slaves).
What I see in my config is something like:
[ 2640.725700] device bond0 entered promiscuous mode
[ 2640.726623] device eth0 entered promiscuous mode
[ 2640.727655] br0: port 1(bond0) entered forwarding state
[ 2640.728718] br0: port 1(bond0) entered forwarding state
This is my quick configuration:
br0 ----> bond0 -------> eth0
I wanted to make sure in this case eth0 is properly configured in
promisc mode.
If eth0 is somehow DOWN, when bond0 is added to the bridge, then it
will never get promisc mode set (at least in my quick test).
I am not sure if this what's happening in your case, but that's
the only explanation I can come up with for the above log you provided.
-vlad
>
>> The promisc flag propagation to lower interfaces only happens when those interfaces are up. So if for whatever reason,
>> the lower interfaces happen to be down during the crating of this
>> hierarchy, the promiscuity flag may not get set on the lower level port
>> device an we may end up in this situation.
>>
>> -vlad
>>
>>> Now adding variant 1:
>>> # dmesg -c|egrep "promiscuous|forward"
>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>
>>> Now it looks like this:
>>> # ip a l|grep PROMISC
>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>> htb master vmbr0 state UNKNOWN qlen 500
>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>>
>>> Greets,
>>> Stefan
>>>
>>>
>>> Main question is - is this one correct:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 \ vmbr1.3000
>>>>>>> \ ---- tap114i1
>>>
>>> <= does not work at all
>>>
>>> or this one?:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>> \ ---- tap114i1
>>>
>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>
>>>> -vlad
>>>>
>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>>> promisc mode.
>>>>>
>>>>> Stefan
>>>>>
>>>>>>> I also tried this one without success:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>> \ ---- tap114i1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Greets,
>>>>>>> Stefan
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 17:37 ` Vlad Yasevich
@ 2013-11-13 17:46 ` Stefan Priebe - Profihost AG
2013-11-13 17:49 ` Vlad Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-13 17:46 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Veaceslav Falico, Linux Netdev List
> Am 13.11.2013 um 18:37 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>
>> On 11/13/2013 12:22 PM, Stefan Priebe - Profihost AG wrote:
>>
>>>> Am 13.11.2013 um 17:44 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>>>>
>>>> On 11/13/2013 10:17 AM, Stefan Priebe - Profihost AG wrote:
>>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>>> Hi Falico,
>>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>>> never
>>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>>
>>>>>>>> I've this:
>>>>>>>>
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> /
>>>>>>>> eth3
>>>>>>>>
>>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>>> bonding and using a bridge.
>>>>>>>>
>>>>>>>> I the past i had this:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>>>>> is bad!
>>>>>>>
>>>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>>>> patchsets that will never hit 3.10 stable.
>>>>>>> Also, the bonding configuration would be welcome.
>>>>>>
>>>>>> Debian Bonding konfiguration looks like this:
>>>>>> auto bond1
>>>>>> iface bond1 inet manual
>>>>>> slaves eth2 eth3
>>>>>> bond-mode 802.3ad
>>>>>> bond_miimon 100
>>>>>> bond_updelay 200
>>>>>> bond_downdelay 0
>>>>>>
>>>>>> This should be miimon using lacp and not arp isn't it?
>>>>>> Anything more needed?
>>>>>
>>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>>> the the kernel messages that say that?
>>>>
>>>> No it does not - i only see:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 5.445161] device bond0 entered promiscuous mode
>>>> [ 7.670701] device bond1 entered promiscuous mode
>>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>>
>>> So this can happen if bond interfaces are down at the time of joining
>>> the bridge.
>>
>> About which of my tried configuration do you speak? The bond itself is always up it's the internet connection. Or do you mean the vlan bond?
>
> The issue is in the formation for vmbr0 and vmbr1. When bond0 and
> bond1 enter promisc mode as part of becoming a bridge port, they should
> put some subset of their ports into promisc mode as well (in 802.3ad
> mode it should happen on all bond slaves).
>
> What I see in my config is something like:
>
> [ 2640.725700] device bond0 entered promiscuous mode
> [ 2640.726623] device eth0 entered promiscuous mode
> [ 2640.727655] br0: port 1(bond0) entered forwarding state
> [ 2640.728718] br0: port 1(bond0) entered forwarding state
>
> This is my quick configuration:
>
> br0 ----> bond0 -------> eth0
>
> I wanted to make sure in this case eth0 is properly configured in
> promisc mode.
>
> If eth0 is somehow DOWN, when bond0 is added to the bridge, then it
> will never get promisc mode set (at least in my quick test).
> I am not sure if this what's happening in your case, but that's
> the only explanation I can come up with for the above log you provided.
But this one works fine it only does not work with vlans.
Is there an easy way to check where those packages get dropped.
Stefan
>
>
> -vlad
>
>>
>>> The promisc flag propagation to lower interfaces only happens when those interfaces are up. So if for whatever reason,
>>> the lower interfaces happen to be down during the crating of this
>>> hierarchy, the promiscuity flag may not get set on the lower level port
>>> device an we may end up in this situation.
>>>
>>> -vlad
>>>
>>>> Now adding variant 1:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>
>>>> Now it looks like this:
>>>> # ip a l|grep PROMISC
>>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr0 state UNKNOWN qlen 500
>>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>>>
>>>> Greets,
>>>> Stefan
>>>>
>>>>
>>>> Main question is - is this one correct:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= does not work at all
>>>>
>>>> or this one?:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>>
>>>>> -vlad
>>>>>
>>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>>>> promisc mode.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>>>> I also tried this one without success:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Greets,
>>>>>>>> Stefan
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 17:46 ` Stefan Priebe - Profihost AG
@ 2013-11-13 17:49 ` Vlad Yasevich
0 siblings, 0 replies; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-13 17:49 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: Veaceslav Falico, Linux Netdev List
On 11/13/2013 12:46 PM, Stefan Priebe - Profihost AG wrote:
>
>> Am 13.11.2013 um 18:37 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>>
>>> On 11/13/2013 12:22 PM, Stefan Priebe - Profihost AG wrote:
>>>
>>>>> Am 13.11.2013 um 17:44 schrieb Vlad Yasevich <vyasevich@gmail.com>:
>>>>>
>>>>> On 11/13/2013 10:17 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>>>> Hi Falico,
>>>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe - Profihost AG
>>>>>>>> wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>>>> never
>>>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>>>
>>>>>>>>> I've this:
>>>>>>>>>
>>>>>>>>> eth2
>>>>>>>>> \
>>>>>>>>> -- bond1 -- vmbr1
>>>>>>>>> /
>>>>>>>>> eth3
>>>>>>>>>
>>>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>>>> bonding and using a bridge.
>>>>>>>>>
>>>>>>>>> I the past i had this:
>>>>>>>>> eth2
>>>>>>>>> \
>>>>>>>>> -- bond1 -- vmbr1
>>>>>>>>> / \
>>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>>> \ ---- tap114i1
>>>>>>>>>
>>>>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-( this
>>>>>>>>> is bad!
>>>>>>>>
>>>>>>>> As a guess - do you use arp monitoring for bonding? Try using miimon -
>>>>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>>>>> patchsets that will never hit 3.10 stable.
>>>>>>>> Also, the bonding configuration would be welcome.
>>>>>>>
>>>>>>> Debian Bonding konfiguration looks like this:
>>>>>>> auto bond1
>>>>>>> iface bond1 inet manual
>>>>>>> slaves eth2 eth3
>>>>>>> bond-mode 802.3ad
>>>>>>> bond_miimon 100
>>>>>>> bond_updelay 200
>>>>>>> bond_downdelay 0
>>>>>>>
>>>>>>> This should be miimon using lacp and not arp isn't it?
>>>>>>> Anything more needed?
>>>>>>
>>>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>>>> the the kernel messages that say that?
>>>>>
>>>>> No it does not - i only see:
>>>>> # dmesg -c|egrep "promiscuous|forward"
>>>>> [ 5.445161] device bond0 entered promiscuous mode
>>>>> [ 7.670701] device bond1 entered promiscuous mode
>>>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>>>
>>>> So this can happen if bond interfaces are down at the time of joining
>>>> the bridge.
>>>
>>> About which of my tried configuration do you speak? The bond itself is always up it's the internet connection. Or do you mean the vlan bond?
>>
>> The issue is in the formation for vmbr0 and vmbr1. When bond0 and
>> bond1 enter promisc mode as part of becoming a bridge port, they should
>> put some subset of their ports into promisc mode as well (in 802.3ad
>> mode it should happen on all bond slaves).
>>
>> What I see in my config is something like:
>>
>> [ 2640.725700] device bond0 entered promiscuous mode
>> [ 2640.726623] device eth0 entered promiscuous mode
>> [ 2640.727655] br0: port 1(bond0) entered forwarding state
>> [ 2640.728718] br0: port 1(bond0) entered forwarding state
>>
>> This is my quick configuration:
>>
>> br0 ----> bond0 -------> eth0
>>
>> I wanted to make sure in this case eth0 is properly configured in
>> promisc mode.
>>
>> If eth0 is somehow DOWN, when bond0 is added to the bridge, then it
>> will never get promisc mode set (at least in my quick test).
>> I am not sure if this what's happening in your case, but that's
>> the only explanation I can come up with for the above log you provided.
>
> But this one works fine it only does not work with vlans.
>
The fact that it does not make lower level devices enter promisc mode
indicates that it may not be working correctly.
> Is there an easy way to check where those packages get dropped.
>
dropwatch should be able to help.
-vlad
> Stefan
>
>>
>>
>> -vlad
>>
>>>
>>>> The promisc flag propagation to lower interfaces only happens when those interfaces are up. So if for whatever reason,
>>>> the lower interfaces happen to be down during the crating of this
>>>> hierarchy, the promiscuity flag may not get set on the lower level port
>>>> device an we may end up in this situation.
>>>>
>>>> -vlad
>>>>
>>>>> Now adding variant 1:
>>>>> # dmesg -c|egrep "promiscuous|forward"
>>>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>>
>>>>> Now it looks like this:
>>>>> # ip a l|grep PROMISC
>>>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>>> htb master vmbr0 state UNKNOWN qlen 500
>>>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>>>>
>>>>> Greets,
>>>>> Stefan
>>>>>
>>>>>
>>>>> Main question is - is this one correct:
>>>>>>>>> eth2
>>>>>>>>> \
>>>>>>>>> -- bond1 -- vmbr1
>>>>>>>>> / \
>>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>>> \ ---- tap114i1
>>>>>
>>>>> <= does not work at all
>>>>>
>>>>> or this one?:
>>>>>>>>> eth2
>>>>>>>>> \
>>>>>>>>> -- bond1 -- vmbr1
>>>>>>>>> / \
>>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>>> \ ---- tap114i1
>>>>>
>>>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>>>
>>>>>> -vlad
>>>>>>
>>>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben not
>>>>>>> with promisc mode. The one below works fine if i set eth2 and eth3 into
>>>>>>> promisc mode.
>>>>>>>
>>>>>>> Stefan
>>>>>>>
>>>>>>>>> I also tried this one without success:
>>>>>>>>> eth2
>>>>>>>>> \
>>>>>>>>> -- bond1 -- vmbr1
>>>>>>>>> / \
>>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>>> \ ---- tap114i1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Greets,
>>>>>>>>> Stefan
>>>>>>>>> --
>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 17:21 ` Vlad Yasevich
@ 2013-11-13 20:09 ` Stefan Priebe
2013-11-14 3:09 ` Vlad Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe @ 2013-11-13 20:09 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
Am 13.11.2013 18:21, schrieb Vlad Yasevich:
> On 11/13/2013 11:21 AM, Veaceslav Falico wrote:
>> On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>> Hi Falico,
>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe -
>>>>>> Profihost AG
>>>>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>> never
>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>
>>>>>>> I've this:
>>>>>>>
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> /
>>>>>>> eth3
>>>>>>>
>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>> bonding and using a bridge.
>>>>>>>
>>>>>>> I the past i had this:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 \ vmbr1.3000
>>>>>>> \ ---- tap114i1
>>>>>>>
>>>>>>> This was working fine until 3.9.X since 3.10. Right now using 3.10 i
>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-(
>>>>>>> this
>>>>>>> is bad!
>>>>>>
>>>>>> As a guess - do you use arp monitoring for bonding? Try using
>>>>>> miimon -
>>>>>> there were some issues with it in 3.10, which were fixed by some huge
>>>>>> patchsets that will never hit 3.10 stable.
>>>>>> Also, the bonding configuration would be welcome.
>>>>>
>>>>> Debian Bonding konfiguration looks like this:
>>>>> auto bond1
>>>>> iface bond1 inet manual
>>>>> slaves eth2 eth3
>>>>> bond-mode 802.3ad
>>>>> bond_miimon 100
>>>>> bond_updelay 200
>>>>> bond_downdelay 0
>>>>>
>>>>> This should be miimon using lacp and not arp isn't it?
>>>>> Anything more needed?
>>>>>
>>>>
>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>> the the kernel messages that say that?
>>>
>>> No it does not - i only see:
>>> # dmesg -c|egrep "promiscuous|forward"
>>> [ 5.445161] device bond0 entered promiscuous mode
>>> [ 7.670701] device bond1 entered promiscuous mode
>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>>
>>> Now adding variant 1:
>>> # dmesg -c|egrep "promiscuous|forward"
>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>
>>> Now it looks like this:
>>> # ip a l|grep PROMISC
>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>> htb master vmbr0 state UNKNOWN qlen 500
>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>
>> eth* should get into forwarding mode cause bond0 is a port of the bridge
>> and should propagate its state towards its slaves. Something is wrong
>> here.
>>
>> Maybe we're looking at the wrong direction - and the promisc for the
>> ethernet drivers got broken?
>
> I was able to duplicate Stefans results only when I turn off the link to
> the underlying devices when building the bridge. When the link is off,
> the rx_flags do not propagate down to the lower level devices.
>
> What about something like this (completely untested)
>
> diff --git a/drivers/net/bonding/bond_main.c
> b/drivers/net/bonding/bond_main.c
> index 4dd5ee2..3051744 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2863,6 +2863,17 @@ static int bond_slave_netdev_event(unsigned long
> event,
> bond_release(bond_dev, slave_dev);
> break;
> case NETDEV_UP:
> + /* If the bond was set to primisc, but slave has not due to
> + * slave being down when the command was issued, sync the
> + * state when the slave comes up.
> + */
> + if (bond_dev->flags & IFF_PROMISC &&
> !slave_dev->promiscuity) {
> + if (!USES_PRIMARY(bond))
> + dev_set_promiscuity(slave_dev, 1);
> + else if (slave == bond->curr_active_slave)
> + dev_set_promiscuity(slave_dev, 1);
> + }
> +
> case NETDEV_CHANGE:
> old_speed = slave->speed;
> old_duplex = slave->duplex;
>
> -vlad
>>
I tried that one but it still looks like this:
[ 173.266915] device tap113i1 entered promiscuous mode
[ 173.305617] 8021q: adding VLAN 3000 to HW filter on device bond1.3000
[ 173.315881] device bond1.3000 entered promiscuous mode
[ 173.315926] vmbr1v3000: port 1(bond1.3000) entered forwarding state
[ 173.315929] vmbr1v3000: port 1(bond1.3000) entered forwarding state
[ 173.319844] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 173.319847] vmbr1v3000: port 2(tap113i1) entered forwarding state
[ 188.344076] vmbr1v3000: port 1(bond1.3000) entered forwarding state
# ip a l|grep PROMISC
13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr0 state UNKNOWN qlen 500
14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
htb master vmbr1v3000 state UNKNOWN qlen 500
>> What ethernet cards/driver do you use for eth*?
>>
>>>
>>> Greets,
>>> Stefan
>>>
>>>
>>> Main question is - is this one correct:
>>
>> Both are correct. Here's my setup (sorry for stretching):
>>
>> +---------------+ +------------+
>> +-------------+ +---------+ +------+
>> | bond1 | | | | bridge0
>> | | | | |
>> | 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 |
>> master | bond0 | master | eth2 |
>> | | --------> | | ------------ | 192.168.4.1 |
>> --------> | | --------> | |
>> +---------------+ +------------+
>> +-------------+ +---------+ +------+
>>
>> |
>>
>> | master
>>
>> v
>> +---------------+
>> +---------+
>> | dummy0
>> | |
>> eth0 |
>> +---------------+
>> +---------+
>>
>> (disregard that dummy0).
>>
>> All 192.168.X.1 ips are pingable (via the correct vlans) on both
>> net-next and stable 3.10.19.
>>
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 \ vmbr1.3000
>>>>>>> \ ---- tap114i1
>>>
>>> <= does not work at all
>>>
>>> or this one?:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>> \ ---- tap114i1
>>>
>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>
>>>> -vlad
>>>>
>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben
>>>>> not
>>>>> with promisc mode. The one below works fine if i set eth2 and eth3
>>>>> into
>>>>> promisc mode.
>>>>>
>>>>> Stefan
>>>>>
>>>>>>> I also tried this one without success:
>>>>>>> eth2
>>>>>>> \
>>>>>>> -- bond1 -- vmbr1
>>>>>>> / \
>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>> \ ---- tap114i1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Greets,
>>>>>>> Stefan
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>
>>>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-13 20:09 ` Stefan Priebe
@ 2013-11-14 3:09 ` Vlad Yasevich
2013-11-14 7:47 ` Stefan Priebe - Profihost AG
2013-11-14 11:54 ` Veaceslav Falico
0 siblings, 2 replies; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-14 3:09 UTC (permalink / raw)
To: Stefan Priebe, Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 8365 bytes --]
On 11/13/2013 03:09 PM, Stefan Priebe wrote:
> Am 13.11.2013 18:21, schrieb Vlad Yasevich:
>> On 11/13/2013 11:21 AM, Veaceslav Falico wrote:
>>> On Wed, Nov 13, 2013 at 04:17:33PM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>> Am 13.11.2013 16:05, schrieb Vlad Yasevich:
>>>>> On 11/13/2013 09:20 AM, Stefan Priebe - Profihost AG wrote:
>>>>>> Hi Falico,
>>>>>> Am 13.11.2013 15:12, schrieb Veaceslav Falico:
>>>>>>> On Wed, Nov 13, 2013 at 02:58:40PM +0100, Stefan Priebe -
>>>>>>> Profihost AG
>>>>>>> wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> while my vlans, bridging and bonding stuff was working until 3.9 i
>>>>>>>> never
>>>>>>>> thought about how it is right. So maybe i was always wrong.
>>>>>>>>
>>>>>>>> I've this:
>>>>>>>>
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> /
>>>>>>>> eth3
>>>>>>>>
>>>>>>>> This works fine and as expected now i want to have a vlan using the
>>>>>>>> bonding and using a bridge.
>>>>>>>>
>>>>>>>> I the past i had this:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>> This was working fine until 3.9.X since 3.10. Right now using
>>>>>>>> 3.10 i
>>>>>>>> need to put eth2 and eth3 into promisc mode to get it working ;-(
>>>>>>>> this
>>>>>>>> is bad!
>>>>>>>
>>>>>>> As a guess - do you use arp monitoring for bonding? Try using
>>>>>>> miimon -
>>>>>>> there were some issues with it in 3.10, which were fixed by some
>>>>>>> huge
>>>>>>> patchsets that will never hit 3.10 stable.
>>>>>>> Also, the bonding configuration would be welcome.
>>>>>>
>>>>>> Debian Bonding konfiguration looks like this:
>>>>>> auto bond1
>>>>>> iface bond1 inet manual
>>>>>> slaves eth2 eth3
>>>>>> bond-mode 802.3ad
>>>>>> bond_miimon 100
>>>>>> bond_updelay 200
>>>>>> bond_downdelay 0
>>>>>>
>>>>>> This should be miimon using lacp and not arp isn't it?
>>>>>> Anything more needed?
>>>>>>
>>>>>
>>>>> Hmm.. With 802.3ad mode, when the bond is a port on the bridge, the
>>>>> bond should place all of its ports into promiscuous mode. Do you see
>>>>> the the kernel messages that say that?
>>>>
>>>> No it does not - i only see:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 5.445161] device bond0 entered promiscuous mode
>>>> [ 7.670701] device bond1 entered promiscuous mode
>>>> [ 7.845472] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 7.845474] vmbr0: port 1(bond0) entered forwarding state
>>>> [ 8.269769] vmbr1: port 1(bond1) entered forwarding state
>>>> [ 8.269771] vmbr1: port 1(bond1) entered forwarding state
>>>>
>>>> Now adding variant 1:
>>>> # dmesg -c|egrep "promiscuous|forward"
>>>> [ 85.919382] device tap113i0 entered promiscuous mode
>>>> [ 85.965018] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 85.965023] vmbr0: port 2(tap113i0) entered forwarding state
>>>> [ 86.263292] device tap113i1 entered promiscuous mode
>>>> [ 86.314151] device vmbr1.3000 entered promiscuous mode
>>>> [ 86.314153] device vmbr1 entered promiscuous mode
>>>> [ 86.314192] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.314196] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>> [ 86.318116] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 86.318120] vmbr1v3000: port 2(tap113i1) entered forwarding state
>>>> [ 101.382129] vmbr1v3000: port 1(vmbr1.3000) entered forwarding state
>>>>
>>>> Now it looks like this:
>>>> # ip a l|grep PROMISC
>>>> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr0 state UNKNOWN qlen 500
>>>> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
>>>> htb master vmbr1v3000 state UNKNOWN qlen 500
>>>
>>> eth* should get into forwarding mode cause bond0 is a port of the bridge
>>> and should propagate its state towards its slaves. Something is wrong
>>> here.
>>>
>>> Maybe we're looking at the wrong direction - and the promisc for the
>>> ethernet drivers got broken?
>>
>> I was able to duplicate Stefans results only when I turn off the link to
>> the underlying devices when building the bridge. When the link is off,
>> the rx_flags do not propagate down to the lower level devices.
>>
>> What about something like this (completely untested)
>>
[snip old patch]
>>
>> -vlad
>>>
>
> I tried that one but it still looks like this:
>
> [ 173.266915] device tap113i1 entered promiscuous mode
> [ 173.305617] 8021q: adding VLAN 3000 to HW filter on device bond1.3000
> [ 173.315881] device bond1.3000 entered promiscuous mode
> [ 173.315926] vmbr1v3000: port 1(bond1.3000) entered forwarding state
> [ 173.315929] vmbr1v3000: port 1(bond1.3000) entered forwarding state
> [ 173.319844] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 173.319847] vmbr1v3000: port 2(tap113i1) entered forwarding state
> [ 188.344076] vmbr1v3000: port 1(bond1.3000) entered forwarding state
>
> # ip a l|grep PROMISC
> 13: tap113i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr0 state UNKNOWN qlen 500
> 14: tap113i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc
> htb master vmbr1v3000 state UNKNOWN qlen 500
>
Stefan
Can you try out attached patch please. I ran it in my environment and
always get promisc link when attaching devices to the bridge.
Thanks
-vlad
>>> What ethernet cards/driver do you use for eth*?
>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>>
>>>>
>>>> Main question is - is this one correct:
>>>
>>> Both are correct. Here's my setup (sorry for stretching):
>>>
>>> +---------------+ +------------+
>>> +-------------+ +---------+ +------+
>>> | bond1 | | | | bridge0
>>> | | | | |
>>> | 192.168.2.1 | master | bridge0.15 | neighbour | 192.168.3.1 |
>>> master | bond0 | master | eth2 |
>>> | | --------> | | ------------ | 192.168.4.1 |
>>> --------> | | --------> | |
>>> +---------------+ +------------+
>>> +-------------+ +---------+ +------+
>>>
>>> |
>>>
>>> | master
>>>
>>> v
>>> +---------------+
>>> +---------+
>>> | dummy0
>>> | |
>>> eth0 |
>>> +---------------+
>>> +---------+
>>>
>>> (disregard that dummy0).
>>>
>>> All 192.168.X.1 ips are pingable (via the correct vlans) on both
>>> net-next and stable 3.10.19.
>>>
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 \ vmbr1.3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= does not work at all
>>>>
>>>> or this one?:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>
>>>> <= works if i manually put eth2 and eth3 into promiscous mode.
>>>>
>>>>> -vlad
>>>>>
>>>>>> One thing i forgot the one with vmbr1.3000 does not work at all eben
>>>>>> not
>>>>>> with promisc mode. The one below works fine if i set eth2 and eth3
>>>>>> into
>>>>>> promisc mode.
>>>>>>
>>>>>> Stefan
>>>>>>
>>>>>>>> I also tried this one without success:
>>>>>>>> eth2
>>>>>>>> \
>>>>>>>> -- bond1 -- vmbr1
>>>>>>>> / \
>>>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>>>> \ ---- tap114i1
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Greets,
>>>>>>>> Stefan
>>>>>>>> --
>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>> netdev" in
>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>>>
>>>>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: 0001-core-Propagate-rx_flags-changes-to-slave-master-devi.patch --]
[-- Type: text/x-patch, Size: 1080 bytes --]
>From 964cbe4596d002871fa0dea7526536769bef4b69 Mon Sep 17 00:00:00 2001
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 13 Nov 2013 13:18:59 -0500
Subject: [PATCH] core: Propagate rx_flags changes to slave|master devices even
if down.
If the device is a master or slave device, propagate rx_flag
changes to them even if they are down. This makes sure that
when complex stacked configuration are set up, the flags
are properly set on all devices.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
net/core/dev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index fc913f4..016857b 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4525,7 +4525,9 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
{
const struct net_device_ops *ops = dev->netdev_ops;
- if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
+ if (((dev->flags & IFF_UP) ||
+ (dev->flags & (IFF_MASTER | IFF_SLAVE)))
+ && ops->ndo_change_rx_flags)
ops->ndo_change_rx_flags(dev, flags);
}
--
1.8.4.2
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 3:09 ` Vlad Yasevich
@ 2013-11-14 7:47 ` Stefan Priebe - Profihost AG
2013-11-14 12:29 ` Veaceslav Falico
2013-11-14 11:54 ` Veaceslav Falico
1 sibling, 1 reply; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-14 7:47 UTC (permalink / raw)
To: vyasevic, Vlad Yasevich, Veaceslav Falico; +Cc: Linux Netdev List
Hi,
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
thos one works fine now.
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 \ vmbr1.3000
> \ ---- tap114i1
this one does not. Another note to this one. It also never worked on
RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
3.10. But it was the only one where gvrp on vlans had worked.
Greets,
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 3:09 ` Vlad Yasevich
2013-11-14 7:47 ` Stefan Priebe - Profihost AG
@ 2013-11-14 11:54 ` Veaceslav Falico
2013-11-14 14:27 ` Vlad Yasevich
1 sibling, 1 reply; 28+ messages in thread
From: Veaceslav Falico @ 2013-11-14 11:54 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Stefan Priebe, Vlad Yasevich, Linux Netdev List
On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>Can you try out attached patch please. I ran it in my environment and
>always get promisc link when attaching devices to the bridge.
It's interesting, actually, why do we need to check for IFF_UP at all when
changing flags.
The addition of IFF_UP goes up to:
commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
Author: Patrick McHardy <kaber@trash.net>
Date: Tue Oct 7 15:26:48 2008 -0700
net: only invoke dev->change_rx_flags when device is UP
Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
device down that is in promiscous mode:
When the VLAN device is set down, the promiscous count on the real
device is decremented by one by vlan_dev_stop(). When removing the
promiscous flag from the VLAN device afterwards, the promiscous
count on the real device is decremented a second time by the
vlan_change_rx_flags() callback.
... snip ...
However, I'm not sure that this is still needed, cause:
commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
Author: Matthijs Kooijman <matthijs@stdin.nl>
Date: Mon Oct 31 04:53:13 2011 +0000
vlan: Don't propagate flag changes on down interfaces.
When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
flags are cleared or set on the underlying interface. So, if these flags
are changed on a vlan interface that is not up, the flags underlying
interface might be set or cleared twice.
Only propagating flag changes when a device is up makes sure this does
not happen. It also makes sure that an underlying device is not set to
promiscuous or allmulti mode for a vlan device that is down.
... snip ...
which fixed completely the initial issue with vlans.
Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
let the drivers using it handle its own logic, as vlan does?
Something like this:
diff --git a/net/core/dev.c b/net/core/dev.c
index 8ffc52e..9615cd7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
{
const struct net_device_ops *ops = dev->netdev_ops;
- if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
+ if (ops->ndo_change_rx_flags)
ops->ndo_change_rx_flags(dev, flags);
}
>
>Thanks
>-vlad
^ permalink raw reply related [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 7:47 ` Stefan Priebe - Profihost AG
@ 2013-11-14 12:29 ` Veaceslav Falico
2013-11-14 21:13 ` Vlad Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Veaceslav Falico @ 2013-11-14 12:29 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG; +Cc: vyasevic, Vlad Yasevich, Linux Netdev List
On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG wrote:
>Hi,
>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>
>thos one works fine now.
>
>
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>
>this one does not. Another note to this one. It also never worked on
>RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>3.10. But it was the only one where gvrp on vlans had worked.
bridge device in this config is neither master nor slave, if I read it
correctly.
You might want to try my patch to see if it works (my previous email).
>
>Greets,
>Stefan
>--
>To unsubscribe from this list: send the line "unsubscribe netdev" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 11:54 ` Veaceslav Falico
@ 2013-11-14 14:27 ` Vlad Yasevich
2013-11-14 14:29 ` Stefan Priebe - Profihost AG
0 siblings, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-14 14:27 UTC (permalink / raw)
To: Veaceslav Falico, Vlad Yasevich; +Cc: Stefan Priebe, Linux Netdev List
On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>> Can you try out attached patch please. I ran it in my environment and
>> always get promisc link when attaching devices to the bridge.
>
> It's interesting, actually, why do we need to check for IFF_UP at all when
> changing flags.
>
> The addition of IFF_UP goes up to:
>
> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
> Author: Patrick McHardy <kaber@trash.net>
> Date: Tue Oct 7 15:26:48 2008 -0700
>
> net: only invoke dev->change_rx_flags when device is UP
>
> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
> VLAN
> device down that is in promiscous mode:
>
> When the VLAN device is set down, the promiscous count on the real
> device is decremented by one by vlan_dev_stop(). When removing the
> promiscous flag from the VLAN device afterwards, the promiscous
> count on the real device is decremented a second time by the
> vlan_change_rx_flags() callback.
>
> ... snip ...
>
This was applied in 2.6.27 timeframe.
> However, I'm not sure that this is still needed, cause:
>
> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
> Author: Matthijs Kooijman <matthijs@stdin.nl>
> Date: Mon Oct 31 04:53:13 2011 +0000
>
> vlan: Don't propagate flag changes on down interfaces.
>
> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
> IFF_PROMISC
> flags are cleared or set on the underlying interface. So, if these
> flags
> are changed on a vlan interface that is not up, the flags underlying
> interface might be set or cleared twice.
>
> Only propagating flag changes when a device is up makes sure this does
> not happen. It also makes sure that an underlying device is not set to
> promiscuous or allmulti mode for a vlan device that is down.
>
> ... snip ...
>
And this in 3.2. So how did this work for Stefan in 3.9? Unless there
is something in Ubuntu that changed how the stacked interfaces are
configured and is keeping interfaces down longer then it used to.
> which fixed completely the initial issue with vlans.
>
> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
> let the drivers using it handle its own logic, as vlan does?
>
This should work, but this might regress a few drivers. Looking through
the callers of dev_set_promiscuity at least DSA driver suffers
the same fate as VLAN.
-vlad
> Something like this:
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 8ffc52e..9615cd7 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
> *dev, int flags)
> {
> const struct net_device_ops *ops = dev->netdev_ops;
>
> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
> + if (ops->ndo_change_rx_flags)
> ops->ndo_change_rx_flags(dev, flags);
> }
>
>
>>
>> Thanks
>> -vlad
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 14:27 ` Vlad Yasevich
@ 2013-11-14 14:29 ` Stefan Priebe - Profihost AG
2013-11-14 14:41 ` Vlad Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-14 14:29 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico, Vlad Yasevich; +Cc: Linux Netdev List
Am 14.11.2013 15:27, schrieb Vlad Yasevich:
> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>> Can you try out attached patch please. I ran it in my environment and
>>> always get promisc link when attaching devices to the bridge.
>>
>> It's interesting, actually, why do we need to check for IFF_UP at all
>> when
>> changing flags.
>>
>> The addition of IFF_UP goes up to:
>>
>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>> Author: Patrick McHardy <kaber@trash.net>
>> Date: Tue Oct 7 15:26:48 2008 -0700
>>
>> net: only invoke dev->change_rx_flags when device is UP
>>
>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>> VLAN
>> device down that is in promiscous mode:
>>
>> When the VLAN device is set down, the promiscous count on the real
>> device is decremented by one by vlan_dev_stop(). When removing the
>> promiscous flag from the VLAN device afterwards, the promiscous
>> count on the real device is decremented a second time by the
>> vlan_change_rx_flags() callback.
>>
>> ... snip ...
>>
>
> This was applied in 2.6.27 timeframe.
>
>> However, I'm not sure that this is still needed, cause:
>>
>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>> Date: Mon Oct 31 04:53:13 2011 +0000
>>
>> vlan: Don't propagate flag changes on down interfaces.
>>
>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>> IFF_PROMISC
>> flags are cleared or set on the underlying interface. So, if these
>> flags
>> are changed on a vlan interface that is not up, the flags underlying
>> interface might be set or cleared twice.
>>
>> Only propagating flag changes when a device is up makes sure this
>> does
>> not happen. It also makes sure that an underlying device is not
>> set to
>> promiscuous or allmulti mode for a vlan device that is down.
>>
>> ... snip ...
>>
>
> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
> is something in Ubuntu that changed how the stacked interfaces are
> configured and is keeping interfaces down longer then it used to.
Stop here ;-) in 3.9 it was the other way round.
This one worked:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 \ vmbr1.3000
> \ ---- tap114i1
this one did not:
> eth2
> \
> -- bond1 -- vmbr1
> / \
> eth3 ----- bond1.3000 --- vmbr1v3000
> \ ---- tap114i1
Now with the patch - the 2nd one works the first one does not.
Stefan
>> which fixed completely the initial issue with vlans.
>>
>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>> and
>> let the drivers using it handle its own logic, as vlan does?
>>
>
> This should work, but this might regress a few drivers. Looking through
> the callers of dev_set_promiscuity at least DSA driver suffers
> the same fate as VLAN.
>
> -vlad
>
>> Something like this:
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 8ffc52e..9615cd7 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>> *dev, int flags)
>> {
>> const struct net_device_ops *ops = dev->netdev_ops;
>>
>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>> + if (ops->ndo_change_rx_flags)
>> ops->ndo_change_rx_flags(dev, flags);
>> }
>>
>>
>>>
>>> Thanks
>>> -vlad
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 14:29 ` Stefan Priebe - Profihost AG
@ 2013-11-14 14:41 ` Vlad Yasevich
2013-11-16 21:00 ` Stefan Priebe
0 siblings, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-14 14:41 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG, Veaceslav Falico, Vlad Yasevich
Cc: Linux Netdev List
On 11/14/2013 09:29 AM, Stefan Priebe - Profihost AG wrote:
> Am 14.11.2013 15:27, schrieb Vlad Yasevich:
>> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>>> Can you try out attached patch please. I ran it in my environment and
>>>> always get promisc link when attaching devices to the bridge.
>>>
>>> It's interesting, actually, why do we need to check for IFF_UP at all
>>> when
>>> changing flags.
>>>
>>> The addition of IFF_UP goes up to:
>>>
>>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>>> Author: Patrick McHardy <kaber@trash.net>
>>> Date: Tue Oct 7 15:26:48 2008 -0700
>>>
>>> net: only invoke dev->change_rx_flags when device is UP
>>>
>>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a
>>> VLAN
>>> device down that is in promiscous mode:
>>>
>>> When the VLAN device is set down, the promiscous count on the real
>>> device is decremented by one by vlan_dev_stop(). When removing the
>>> promiscous flag from the VLAN device afterwards, the promiscous
>>> count on the real device is decremented a second time by the
>>> vlan_change_rx_flags() callback.
>>>
>>> ... snip ...
>>>
>>
>> This was applied in 2.6.27 timeframe.
>>
>>> However, I'm not sure that this is still needed, cause:
>>>
>>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>>> Date: Mon Oct 31 04:53:13 2011 +0000
>>>
>>> vlan: Don't propagate flag changes on down interfaces.
>>>
>>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>>> IFF_PROMISC
>>> flags are cleared or set on the underlying interface. So, if these
>>> flags
>>> are changed on a vlan interface that is not up, the flags underlying
>>> interface might be set or cleared twice.
>>>
>>> Only propagating flag changes when a device is up makes sure this
>>> does
>>> not happen. It also makes sure that an underlying device is not
>>> set to
>>> promiscuous or allmulti mode for a vlan device that is down.
>>>
>>> ... snip ...
>>>
>>
>> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
>> is something in Ubuntu that changed how the stacked interfaces are
>> configured and is keeping interfaces down longer then it used to.
>
> Stop here ;-) in 3.9 it was the other way round.
>
> This one worked:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 \ vmbr1.3000
>> \ ---- tap114i1
>
How are you attaching tap to the vlan device? Or is it attached to
vmbr1?
> this one did not:
>> eth2
>> \
>> -- bond1 -- vmbr1
>> / \
>> eth3 ----- bond1.3000 --- vmbr1v3000
>> \ ---- tap114i1
>
> Now with the patch - the 2nd one works the first one does not.
Ok, in this case, you have a VLAN (bond1.3000) configured on top of
bond interface. That vlan is then attached to the bridge (vmbr1v3000).
The tap interface for your VM (tap114i1) is also attached to the same
bridge. In this case, VM will receive only traffic for VLAN 3000 and
it we receive it untagged.
I guess I'd like to understand what you are trying to achieve.
Thanks working with us on this.
-vlad
>
> Stefan
>
>>> which fixed completely the initial issue with vlans.
>>>
>>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>>> and
>>> let the drivers using it handle its own logic, as vlan does?
>>>
>>
>> This should work, but this might regress a few drivers. Looking through
>> the callers of dev_set_promiscuity at least DSA driver suffers
>> the same fate as VLAN.
>>
>> -vlad
>>
>>> Something like this:
>>>
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 8ffc52e..9615cd7 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>>> *dev, int flags)
>>> {
>>> const struct net_device_ops *ops = dev->netdev_ops;
>>>
>>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>>> + if (ops->ndo_change_rx_flags)
>>> ops->ndo_change_rx_flags(dev, flags);
>>> }
>>>
>>>
>>>>
>>>> Thanks
>>>> -vlad
>>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 12:29 ` Veaceslav Falico
@ 2013-11-14 21:13 ` Vlad Yasevich
2013-11-16 21:02 ` Stefan Priebe
0 siblings, 1 reply; 28+ messages in thread
From: Vlad Yasevich @ 2013-11-14 21:13 UTC (permalink / raw)
To: Veaceslav Falico, Stefan Priebe - Profihost AG
Cc: vyasevic, Linux Netdev List
On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
> wrote:
>> Hi,
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>
>> thos one works fine now.
>>
>>
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>
>> this one does not. Another note to this one. It also never worked on
>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>> 3.10. But it was the only one where gvrp on vlans had worked.
>
> bridge device in this config is neither master nor slave, if I read it
> correctly.
Bridge doesn't propagate rx_flags to lower-level devices. It
automatically set all lower devices to promisc mode.
So, in the second case above, eth2 and eth3 have to be in promisc, but
nothing else does. I am not sure I understand Stefans notation though
wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
elaborate?
Thanks
-vlad
>
> You might want to try my patch to see if it works (my previous email).
>
>>
>> Greets,
>> Stefan
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 14:41 ` Vlad Yasevich
@ 2013-11-16 21:00 ` Stefan Priebe
0 siblings, 0 replies; 28+ messages in thread
From: Stefan Priebe @ 2013-11-16 21:00 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico, Vlad Yasevich; +Cc: Linux Netdev List
Hi,
sorry for the long delay.
Am 14.11.2013 15:41, schrieb Vlad Yasevich:
> On 11/14/2013 09:29 AM, Stefan Priebe - Profihost AG wrote:
>> Am 14.11.2013 15:27, schrieb Vlad Yasevich:
>>> On 11/14/2013 06:54 AM, Veaceslav Falico wrote:
>>>> On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>>>>> Can you try out attached patch please. I ran it in my environment and
>>>>> always get promisc link when attaching devices to the bridge.
>>>>
>>>> It's interesting, actually, why do we need to check for IFF_UP at all
>>>> when
>>>> changing flags.
>>>>
>>>> The addition of IFF_UP goes up to:
>>>>
>>>> commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
>>>> Author: Patrick McHardy <kaber@trash.net>
>>>> Date: Tue Oct 7 15:26:48 2008 -0700
>>>>
>>>> net: only invoke dev->change_rx_flags when device is UP
>>>>
>>>> Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when
>>>> setting a
>>>> VLAN
>>>> device down that is in promiscous mode:
>>>>
>>>> When the VLAN device is set down, the promiscous count on the
>>>> real
>>>> device is decremented by one by vlan_dev_stop(). When removing
>>>> the
>>>> promiscous flag from the VLAN device afterwards, the promiscous
>>>> count on the real device is decremented a second time by the
>>>> vlan_change_rx_flags() callback.
>>>>
>>>> ... snip ...
>>>>
>>>
>>> This was applied in 2.6.27 timeframe.
>>>
>>>> However, I'm not sure that this is still needed, cause:
>>>>
>>>> commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
>>>> Author: Matthijs Kooijman <matthijs@stdin.nl>
>>>> Date: Mon Oct 31 04:53:13 2011 +0000
>>>>
>>>> vlan: Don't propagate flag changes on down interfaces.
>>>>
>>>> When (de)configuring a vlan interface, the IFF_ALLMULTI ans
>>>> IFF_PROMISC
>>>> flags are cleared or set on the underlying interface. So, if
>>>> these
>>>> flags
>>>> are changed on a vlan interface that is not up, the flags
>>>> underlying
>>>> interface might be set or cleared twice.
>>>>
>>>> Only propagating flag changes when a device is up makes sure this
>>>> does
>>>> not happen. It also makes sure that an underlying device is not
>>>> set to
>>>> promiscuous or allmulti mode for a vlan device that is down.
>>>>
>>>> ... snip ...
>>>>
>>>
>>> And this in 3.2. So how did this work for Stefan in 3.9? Unless there
>>> is something in Ubuntu that changed how the stacked interfaces are
>>> configured and is keeping interfaces down longer then it used to.
>>
>> Stop here ;-) in 3.9 it was the other way round.
>>
>> This one worked:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 \ vmbr1.3000
>>> \ ---- tap114i1
>>
>
> How are you attaching tap to the vlan device? Or is it attached to
> vmbr1?
No, to vmbr1.3000.
>> this one did not:
>>> eth2
>>> \
>>> -- bond1 -- vmbr1
>>> / \
>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>> \ ---- tap114i1
>>
>> Now with the patch - the 2nd one works the first one does not.
>
> Ok, in this case, you have a VLAN (bond1.3000) configured on top of
> bond interface. That vlan is then attached to the bridge (vmbr1v3000).
> The tap interface for your VM (tap114i1) is also attached to the same
> bridge. In this case, VM will receive only traffic for VLAN 3000 and
> it we receive it untagged.
Yes and this is also what i want to archieve.
> I guess I'd like to understand what you are trying to achieve.
>
> Thanks working with us on this.
> -vlad
>
>>
>> Stefan
>>
>>>> which fixed completely the initial issue with vlans.
>>>>
>>>> Maybe we should just remove the IFF_UP check in dev_change_rx_flags(),
>>>> and
>>>> let the drivers using it handle its own logic, as vlan does?
>>>>
>>>
>>> This should work, but this might regress a few drivers. Looking through
>>> the callers of dev_set_promiscuity at least DSA driver suffers
>>> the same fate as VLAN.
>>>
>>> -vlad
>>>
>>>> Something like this:
>>>>
>>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>>> index 8ffc52e..9615cd7 100644
>>>> --- a/net/core/dev.c
>>>> +++ b/net/core/dev.c
>>>> @@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device
>>>> *dev, int flags)
>>>> {
>>>> const struct net_device_ops *ops = dev->netdev_ops;
>>>>
>>>> - if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
>>>> + if (ops->ndo_change_rx_flags)
>>>> ops->ndo_change_rx_flags(dev, flags);
>>>> }
>>>>
>>>>
>>>>>
>>>>> Thanks
>>>>> -vlad
>>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-14 21:13 ` Vlad Yasevich
@ 2013-11-16 21:02 ` Stefan Priebe
2013-11-17 3:41 ` Vladislav Yasevich
0 siblings, 1 reply; 28+ messages in thread
From: Stefan Priebe @ 2013-11-16 21:02 UTC (permalink / raw)
To: Vlad Yasevich, Veaceslav Falico; +Cc: vyasevic, Linux Netdev List
Am 14.11.2013 22:13, schrieb Vlad Yasevich:
> On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
>> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
>> wrote:
>>> Hi,
>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>> \ ---- tap114i1
>>>
>>> thos one works fine now.
>>>
>>>
>>>> eth2
>>>> \
>>>> -- bond1 -- vmbr1
>>>> / \
>>>> eth3 \ vmbr1.3000
>>>> \ ---- tap114i1
>>>
>>> this one does not. Another note to this one. It also never worked on
>>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>>> 3.10. But it was the only one where gvrp on vlans had worked.
>>
>> bridge device in this config is neither master nor slave, if I read it
>> correctly.
>
> Bridge doesn't propagate rx_flags to lower-level devices. It
> automatically set all lower devices to promisc mode.
>
> So, in the second case above, eth2 and eth3 have to be in promisc, but
> nothing else does. I am not sure I understand Stefans notation though
> wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
> elaborate?
Sorry . means vlan - so vmbr1.3000 is just a vlan on top of vmbr1. *brX
is a bridge. Bond is a lacp bond ;-)
Stefan
>
> Thanks
> -vlad
>>
>> You might want to try my patch to see if it works (my previous email).
>>
>>>
>>> Greets,
>>> Stefan
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-16 21:02 ` Stefan Priebe
@ 2013-11-17 3:41 ` Vladislav Yasevich
2013-11-18 7:37 ` Stefan Priebe - Profihost AG
0 siblings, 1 reply; 28+ messages in thread
From: Vladislav Yasevich @ 2013-11-17 3:41 UTC (permalink / raw)
To: Stefan Priebe; +Cc: Veaceslav Falico, Vlad Yasevich, Linux Netdev List
On Sat, Nov 16, 2013 at 4:02 PM, Stefan Priebe <s.priebe@profihost.ag> wrote:
> Am 14.11.2013 22:13, schrieb Vlad Yasevich:
>
>> On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
>>>
>>> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>> \ ---- tap114i1
>>>>
>>>>
>>>> thos one works fine now.
>>>>
>>>>
>>>>> eth2
>>>>> \
>>>>> -- bond1 -- vmbr1
>>>>> / \
>>>>> eth3 \ vmbr1.3000
>>>>> \ ---- tap114i1
>>>>
>>>>
>>>> this one does not. Another note to this one. It also never worked on
>>>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>>>> 3.10. But it was the only one where gvrp on vlans had worked.
>>>
>>>
>>> bridge device in this config is neither master nor slave, if I read it
>>> correctly.
>>
>>
>> Bridge doesn't propagate rx_flags to lower-level devices. It
>> automatically set all lower devices to promisc mode.
>>
>> So, in the second case above, eth2 and eth3 have to be in promisc, but
>> nothing else does. I am not sure I understand Stefans notation though
>> wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
>> elaborate?
>
>
> Sorry . means vlan - so vmbr1.3000 is just a vlan on top of vmbr1. *brX is a
> bridge. Bond is a lacp bond ;-)
>
Ok. I got that. But where is tap attached? You are showing it
attached to the vlan,
but you can't do that unless its a macvtap. macvtaps on top of bridges is just
asking for trouble.
Thanks
-vlad
> Stefan
>
>
>>
>> Thanks
>> -vlad
>>>
>>>
>>> You might want to try my patch to see if it works (my previous email).
>>>
>>>>
>>>> Greets,
>>>> Stefan
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
2013-11-17 3:41 ` Vladislav Yasevich
@ 2013-11-18 7:37 ` Stefan Priebe - Profihost AG
0 siblings, 0 replies; 28+ messages in thread
From: Stefan Priebe - Profihost AG @ 2013-11-18 7:37 UTC (permalink / raw)
To: Vladislav Yasevich; +Cc: Veaceslav Falico, Vlad Yasevich, Linux Netdev List
Am 17.11.2013 04:41, schrieb Vladislav Yasevich:
> On Sat, Nov 16, 2013 at 4:02 PM, Stefan Priebe <s.priebe@profihost.ag> wrote:
>> Am 14.11.2013 22:13, schrieb Vlad Yasevich:
>>
>>> On 11/14/2013 07:29 AM, Veaceslav Falico wrote:
>>>>
>>>> On Thu, Nov 14, 2013 at 08:47:28AM +0100, Stefan Priebe - Profihost AG
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 ----- bond1.3000 --- vmbr1v3000
>>>>>> \ ---- tap114i1
>>>>>
>>>>>
>>>>> thos one works fine now.
>>>>>
>>>>>
>>>>>> eth2
>>>>>> \
>>>>>> -- bond1 -- vmbr1
>>>>>> / \
>>>>>> eth3 \ vmbr1.3000
>>>>>> \ ---- tap114i1
>>>>>
>>>>>
>>>>> this one does not. Another note to this one. It also never worked on
>>>>> RHEL6 - it started working with about 2.6.39 and stopped with 3.9 or
>>>>> 3.10. But it was the only one where gvrp on vlans had worked.
>>>>
>>>>
>>>> bridge device in this config is neither master nor slave, if I read it
>>>> correctly.
>>>
>>>
>>> Bridge doesn't propagate rx_flags to lower-level devices. It
>>> automatically set all lower devices to promisc mode.
>>>
>>> So, in the second case above, eth2 and eth3 have to be in promisc, but
>>> nothing else does. I am not sure I understand Stefans notation though
>>> wrt to how vmbr1.3000 and tap114i1 are configured. Stefan, can you
>>> elaborate?
>>
>>
>> Sorry . means vlan - so vmbr1.3000 is just a vlan on top of vmbr1. *brX is a
>> bridge. Bond is a lacp bond ;-)
>>
>
> Ok. I got that. But where is tap attached? You are showing it
> attached to the vlan,
> but you can't do that unless its a macvtap.
Why not? It was working until 3.9 - but with the patch in this thread
the first method adding a bridge on top of the bond works fine - so this
is OK for me too.
Greets,
Stefan
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2013-11-18 7:37 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-13 13:58 how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10 Stefan Priebe - Profihost AG
2013-11-13 14:12 ` Veaceslav Falico
2013-11-13 14:20 ` Stefan Priebe - Profihost AG
2013-11-13 14:34 ` Veaceslav Falico
2013-11-13 14:43 ` Stefan Priebe - Profihost AG
2013-11-13 15:05 ` Vlad Yasevich
2013-11-13 15:17 ` Stefan Priebe - Profihost AG
2013-11-13 16:21 ` Veaceslav Falico
2013-11-13 16:43 ` Stefan Priebe - Profihost AG
2013-11-13 17:21 ` Vlad Yasevich
2013-11-13 20:09 ` Stefan Priebe
2013-11-14 3:09 ` Vlad Yasevich
2013-11-14 7:47 ` Stefan Priebe - Profihost AG
2013-11-14 12:29 ` Veaceslav Falico
2013-11-14 21:13 ` Vlad Yasevich
2013-11-16 21:02 ` Stefan Priebe
2013-11-17 3:41 ` Vladislav Yasevich
2013-11-18 7:37 ` Stefan Priebe - Profihost AG
2013-11-14 11:54 ` Veaceslav Falico
2013-11-14 14:27 ` Vlad Yasevich
2013-11-14 14:29 ` Stefan Priebe - Profihost AG
2013-11-14 14:41 ` Vlad Yasevich
2013-11-16 21:00 ` Stefan Priebe
2013-11-13 16:44 ` Vlad Yasevich
2013-11-13 17:22 ` Stefan Priebe - Profihost AG
2013-11-13 17:37 ` Vlad Yasevich
2013-11-13 17:46 ` Stefan Priebe - Profihost AG
2013-11-13 17:49 ` Vlad Yasevich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.