netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>>>>>
>>>>
>

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