* 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 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 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 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 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 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
* 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 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 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-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: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
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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).