netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Stefan Priebe - Profihost AG <s.priebe@profihost.ag>,
	Veaceslav Falico <vfalico@redhat.com>
Cc: Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
Date: Wed, 13 Nov 2013 11:44:54 -0500	[thread overview]
Message-ID: <5283AC86.9060601@gmail.com> (raw)
In-Reply-To: <5283980D.7020508@profihost.ag>

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
>>>
>>

  parent reply	other threads:[~2013-11-13 16:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5283AC86.9060601@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=s.priebe@profihost.ag \
    --cc=vfalico@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).