lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 13 Nov 2013 18:46:24 +0100
From:	Stefan Priebe - Profihost AG <s.priebe@...fihost.ag>
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	Veaceslav Falico <vfalico@...hat.com>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10


> Am 13.11.2013 um 18:37 schrieb Vlad Yasevich <vyasevich@...il.com>:
> 
>> On 11/13/2013 12:22 PM, Stefan Priebe - Profihost AG wrote:
>> 
>>>> Am 13.11.2013 um 17:44 schrieb Vlad Yasevich <vyasevich@...il.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@...r.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@...r.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ