Re: Bug#697357: bridging broken over bond interfaces

Forwarding this to netdev since the bug is still present in Linux 3.7.1.
For those joining us, this thread is archive at
<http://bugs.debian.org/697357>.

On Fri, 2013-01-04 at 13:40 +0100, Peter Palfrader wrote:

On Fri, 04 Jan 2013, Bastian Blank wrote:

quoted

On Fri, Jan 04, 2013 at 12:17:12PM +0100, Peter Palfrader wrote:

quoted

I tried to set up a new KVM host in the usual way:
  - have a bond0 interface over all physcial eth* interfaces
  - create a br0 over that bond0 and any vnet* interfaces for the
    guests.

Also, arp works through the bridge, forgot to mention that.

quoted

quoted

*   Manually switching the eth* to promiscious mode makes stuff work.

Okay, so a workaround is available.

When did it last work? Does it work with the kernel from experimental?

It works nicely on stable, e.g. pasquini.debian.org:

| weasel@pasquini:~$ sudo brctl show
| bridge name     bridge id               STP enabled     interfaces
| br0             8000.e83935a9ec10       no              bond0
|                                                         tap0
|                                                         tap1
|                                                         tap2
| br1             8000.e83935a9ec10       no              bond0.221
| br2             8000.da1343affe92       no              bond0.3301
|                                                         tap3

And there the bond interface is promisc automatically:
weasel@pasquini:~$ ip a | grep -i bond
| 2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
| 3: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP qlen 1000
| 4: bond0: <BROADCAST,MULTICAST,PROMISC,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
| 7: bond0.221@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
| 9: bond0.3301@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 

Likewise it works as expected when one does br directly on eth0, without any
bonding.

It's also broken with linux-image-3.7-trunk-amd64_3.7.1-1~experimental.1_amd64.deb.

-- 
Ben Hutchings
If you seem to know what you are doing, you'll be given more to do.

Ben Hutchings [off-list ref] writes:

Forwarding this to netdev since the bug is still present in Linux 3.7.1.
For those joining us, this thread is archive at
<http://bugs.debian.org/697357>.

Please forgive me for eliding the previous discussion; I think I hit the
same or a very similar problem in the same setup, but without the KVM or
guest parts (but I could reproduce this in a pretty bare KVM guest with
a virtio network device).  My interface configuration (hopefully
comprehensible without familiarity with Debian):

# this is a bare bond interface named after the native VLAN (no .1q!)
auto vlan894
iface vlan894 inet manual
	bond_mode	active-backup
	bond_slaves	eth0
	bond_miimon	100
	bond_updelay	4000

# this bridge has a static IPv4 address and contains the above bond
auto br894
iface br894 inet static
	bridge_ports	vlan894
	bridge_stp	off
	bridge_fd	0
	address		x.y.z.w
	netmask		255.255.255.0
	gateway		x.y.z.g

Actually, I want ARP monitoring for the bond, but if I leave out either
the miimon *or* the updelay configuration, the machine stops responding
to solicited-node multicast packages (neighbor solicitations) thus
becoming unreachable via its autoconfigured global IPv6 address.  That
is, until I put eth0 into promiscuous mode!  And really, with the above
(working) config dmesg says:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: Setting up delay to 4000.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: enslaving eth0 as a backup interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
IPv6: ADDRCONF(NETDEV_UP): vlan894: link is not ready
bonding: vlan894: link status definitely up for interface eth0, 4294967295 Mbps full duplex.
bonding: vlan894: making interface eth0 the new active one.
device eth0 entered promiscuous mode
bonding: vlan894: first active interface up!
IPv6: ADDRCONF(NETDEV_CHANGE): vlan894: link becomes ready
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

(although ip link does not list any promiscuous interfaces).  On the
other hand, if I don't configure eg. bond_updelay:

bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: vlan894 is being created...
bonding: vlan894: Setting MII monitoring interval to 100.
bonding: vlan894: setting mode to active-backup (1).
bonding: vlan894: Adding slave eth0.
bonding: vlan894: making interface eth0 the new active one.
bonding: vlan894: first active interface up!
bonding: vlan894: enslaving eth0 as an active interface with an up link.
Bridge firewalling registered
device vlan894 entered promiscuous mode
br894: port 1(vlan894) entered forwarding state
br894: port 1(vlan894) entered forwarding state

ie. promiscuous mode isn't propageted to eth0 and the global IPv6
address of the machine does not respond to ping6 until tcpdump -i eth0
or ip link set eth0 promisc on.  Meanwhile in all cases:

# ip maddr show dev br894
5:	br894
	link  33:33:00:00:00:01
	link  01:00:5e:00:00:01
	link  33:33:ff:02:00:07
	inet  224.0.0.1
	inet6 ff02::1:ff02:7 users 2
	inet6 ff02::1

This happens with the current 3.7.3-1~experimental.1 amd64 kernel under
Debian wheezy (besides the current 3.2 wheezy kernel).
-- 
Thanks for your time,
Feri.