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: 7+ 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 14:01 ` Jiri Pirko
2011-03-26 15:42 ` Michał Mirosław
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 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).