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.
next prev parent 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.