[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87y5fl0y1v.fsf@lant.ki.iif.hu>
Date: Tue, 22 Jan 2013 21:20:44 +0100
From: Ferenc Wagner <wferi@...f.hu>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: netdev <netdev@...r.kernel.org>, Bastian Blank <waldi@...ian.org>,
697357@...s.debian.org, Peter Palfrader <weasel@...ian.org>,
Stephen Hemminger <shemminger@...tta.com>,
Jay Vosburgh <fubar@...ibm.com>,
Andy Gospodarek <andy@...yhouse.net>, wferi@...f.hu
Subject: Re: Bug#697357: bridging broken over bond interfaces
Ben Hutchings <ben@...adent.org.uk> 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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists