From: Stefan Priebe <s.priebe@profihost.ag>
To: Vlad Yasevich <vyasevich@gmail.com>,
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 21:09:53 +0100 [thread overview]
Message-ID: <5283DC91.1010402@profihost.ag> (raw)
In-Reply-To: <5283B500.9040408@gmail.com>
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
>>>>>
>>>>
>
next prev parent reply other threads:[~2013-11-13 20:09 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 [this message]
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
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=5283DC91.1010402@profihost.ag \
--to=s.priebe@profihost.ag \
--cc=netdev@vger.kernel.org \
--cc=vfalico@redhat.com \
--cc=vyasevich@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.