All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas de Pesloüan" <nicolas.2p.debian@free.fr>
To: Leonardo Borda <leonardo.borda@canonical.com>
Cc: Bridge <bridge@lists.linux-foundation.org>,
	bonding-devel@lists.sourceforge.net
Subject: Re: [Bridge] [Bonding-devel] bonding inside a bridge does not work when using arp monitoring
Date: Wed, 16 Mar 2011 21:47:43 +0100	[thread overview]
Message-ID: <4D8121EF.3030200@free.fr> (raw)
In-Reply-To: <1300302933.1462.5.camel@bordalnx>

Le 16/03/2011 20:15, Leonardo Borda a écrit :
> Hi Guys,
>
> In case you're interested or you guys have some hints to add to this
> thread, I've opened a bug in Ubuntu Launchpad regarding Bonding + Bridge
> issues.
>
> https://bugs.launchpad.net/bugs/736226
>
> Please let me know your thoughts about it.
>

Hi Leonardo,

I'm afraid I don't understand your setup.

See my comments below.

 > auto bond0
 > iface bond0 inet manual
 >     post-up ifconfig $IFACE up
 >     pre-down ifconfig $IFACE down
 >     bond-slaves none
 >     bond-mode active-backup
 >     bond_arp_ip_target 10.153.107.1
 >     bond_arp_interval 100

 > auto eth0
 > allow-bond0 eth0
 > iface eth0 inet manual
 >     bond-master bond0

 > auto eth1
 > allow-bond0 eth1
 > iface eth1 inet manual
 >     bond-master bond0

eth0----+
         |
         +----bond0
         |
eth1----+

'sounds good up to this point.

 > auto bond0.100
 > iface bond0.100 inet manual
 >     post-up ifconfig $IFACE up
 >     pre-down ifconfig $IFACE down
 >     vlan-raw-device bond0

 > auto bond0.200
 > iface bond0.200 inet manual
 >     post-up ifconfig $IFACE up
 >     pre-down ifconfig $IFACE down
 >     vlan-raw-device bond0

eth0----+             +----bond0.100
         |             |
         +----bond0----+
         |             |
eth1----+             +----bond0.200

So you split based on the VLAN ID.

 > auto br0
 > iface br0 inet static
 >     address 10.153.107.110
 >     netmask 255.255.255.0
 >     gateway 10.153.107.1
 >     bridge_ports bond0
 >     bridge_stp off
 >     bridge_fd 0
 >     bridge_maxwait 0

eth0----+             +----bond0.100
         |             |
         +----bond0----+----br0
         |             |
eth1----+             +----bond0.200

br0 clearly is built on bond0. Starting from this point, I'm not sure I understand your setup.

Because bond0.100, bond0.200 and br0 are all built on bond0, I can imagine bonding will take the 
frame before bridge have a chance to see it (because bonding handling happens before bridge handling 
in __netif_receive_skb(), in the kernel version you use).

 > auto br0-100
 > iface br0-100 inet manual
 >     post-up ifconfig $IFACE up
 >     pre-down ifconfig $IFACE down
 >     bridge_ports bond0.100
 >     bridge_stp off
 >     bridge_fd 0
 >     bridge_maxwait 0

 > auto br0-200
 > iface br0-200 inet manual
 >     post-up ifconfig $IFACE up
 >     pre-down ifconfig $IFACE down
 >     bridge_ports bond0.200
 >     bridge_stp off
 >     bridge_fd 0
 >     bridge_maxwait 0

eth0----+             +----bond0.100----br0-100
         |             |
         +----bond0----+----br0
         |             |
eth1----+             +----bond0.200----br0-200

br0-100 is built on bond0.100 and br0-200 is built on bond0.200.

So you end up with 3 bridges, all having a single port... this sounds useless, from my point of view.

Can you do some sort of ascii art to describe your expected setup?

The only reason I can imagine to stack a bridge on top of bonding is the following:

eth0----+
         |
         +----bond0----+
         |             |
eth1----+             |
                       +----br0
eth2----+             |
         |             |
         +----bond1----+
         |
eth3----+

That way, the bridge becomes 802.3ad capable, thanks to bonding.

And if you want to do vlan on top of that:

eth0----+
         |
         +----bond0----+
         |             |           +----br0.100
eth1----+             |           |
                       +----br0----+
eth2----+             |           |
         |             |           +----br0.200
         +----bond1----+
         |
eth3----+

The following (untested) setup should provide this configuration:

auto bond0
iface bond0 inet manual
     bond-slaves none
     bond-mode active-backup
     bond_arp_ip_target 10.153.107.1
     bond_arp_interval 100

auto eth0
allow-bond0 eth0
iface eth0 inet manual
     bond-master bond0

auto eth1
allow-bond0 eth1
iface eth1 inet manual
     bond-master bond0

auto eth2
allow-bond1 eth2
iface eth0 inet manual
     bond-master bond1

auto eth3
allow-bond1 eth3
iface eth1 inet manual
     bond-master bond1

auto br0
iface br0 inet static
     bridge_ports bond0 bond1
     bridge_stp off
     bridge_fd 0
     bridge_maxwait 0

auto br0.100
iface br0.100 inet manual
     vlan-raw-device br0
     address 10.153.107.110
     netmask 255.255.255.0
     gateway 10.153.107.1

auto br0.200
iface br0.200 inet manual
     vlan-raw-device br0

	Nicolas.

  reply	other threads:[~2011-03-16 20:47 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-16 19:15 [Bridge] bonding inside a bridge does not work when using arp monitoring Leonardo Borda
2011-03-16 20:47 ` Nicolas de Pesloüan [this message]
2011-03-23 21:13   ` [Bridge] [Bonding-devel] " Leonardo Borda
2011-03-26 12:20     ` Nicolas de Pesloüan
2011-03-26 12:20       ` Nicolas de Pesloüan
2011-03-26 14:01       ` [Bridge] " Jiri Pirko
2011-03-26 14:01         ` Jiri Pirko
2011-03-26 15:42         ` [Bridge] " Michał Mirosław
2011-03-26 15:42           ` Michał Mirosław
2011-03-26 20:32           ` [Bridge] " Nicolas de Pesloüan
2011-03-26 20:32             ` Nicolas de Pesloüan

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=4D8121EF.3030200@free.fr \
    --to=nicolas.2p.debian@free.fr \
    --cc=bonding-devel@lists.sourceforge.net \
    --cc=bridge@lists.linux-foundation.org \
    --cc=leonardo.borda@canonical.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.