[Bug 889423] Re: 802.3ad bonding not configured correctly

Tue Feb 19 13:22:26 UTC 2013

Hello,

After an upgrade from 10.04 to 12.04, our interfaces files stopped working for the 802.3ad interfaces. After converting the interfaces file to the new "format", the configuration seems to be correct, but I seem to be running into a timing issue or race condition again. I implemented most hints on this page, and the ones on https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/1015199 , but if the system starts up, the bond interfaces don't get their slaves (I've seen them come up with 0, 1 or 2 slave interfaces).
I'm trying to create bond1 and bond0, both with 2 physical interfaces. As suggested, the phyiscal interfaces are at the top, the bonds itself are defined at the bottom of the file.

It's a Dell PowerEdge R610, configured with 12 network interfaces, 4x
broadcom bnx2  onboard, 2x4x igb Intel on quad nic boards. The used
physical interfaces (eth0 through eth3) are mapped to the first 2
interfaces on both of the quad boards.  I've tried playing with the pre-
up sleep option as mentioned on comment 33
(https://bugs.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/889423/comments/33),
but to no avail. Could it be another timing issue, maybe due to the
large amount of physical interfaces? If I run an "ifdown -a; ifup -a"
from rc.local, all the interfaces come up just fine. The machine isn't
in production yet, so I might be able to test or provide more logging if
necessary.

auto lo
iface lo inet loopback
auto eth0
iface eth0  inet manual
    bond-master bond1
auto eth2
iface eth2  inet manual
    bond-master bond1
auto eth1
iface eth1  inet manual
    bond-master bond0
auto eth3
iface eth3  inet manual
    bond-master bond0

auto bond0
iface bond0 inet static
    address REDACTED
    netmask 255.255.255.224
    bond_mode 802.3ad # LACP
    bond_miimon 100
    bond_lacp_rate 1
    #xmit_hash_policy layer2+3
    bond_slaves none
iface bond0 inet6 static
    address REDACTED
    netmask 64
    #gateway REDACTED

auto bond1
iface bond1 inet static
    address REDACTED
    netmask 255.255.255.248
    gateway REDACTED
    bond_mode 802.3ad # LACP
    bond_miimon 100
    bond_lacp_rate 1
    #xmit_hash_policy layer2+3
    bond_slaves none

iface bond1 inet6 static
    address REDACTED
    netmask 64
    gateway REDACTED

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to bridge-utils in Ubuntu.
https://bugs.launchpad.net/bugs/889423

Title:
  802.3ad bonding not configured correctly

Status in “bridge-utils” package in Ubuntu:
  Fix Released
Status in “ifenslave-2.6” package in Ubuntu:
  Fix Released
Status in “vlan” package in Ubuntu:
  Fix Released
Status in “bridge-utils” source package in Oneiric:
  Fix Released
Status in “ifenslave-2.6” source package in Oneiric:
  Fix Released
Status in “vlan” source package in Oneiric:
  Fix Released

Bug description:
  SRU instructions (from comment 41 and 46):
  === bridge-utils ===
  So there are two things to test with that new bridge-utils:
   1) Bridge interface with bridge-ports set instead of bridge_ports works too
   2) Bridging a non-existing vlan interface will now create it

  These two are in the udev hooks, so need to be tested by creating a
  network interface, like a tap device (using uml-utilities to create
  it).

  Test for 1)
   - Make sure uml-utilities and bridge-utils are both installed
   - Add the following entry to /etc/network/interfaces:
  auto br0
  iface br0 inet static
      address 192.168.1.1
      netmask 255.255.255.0
      bridge-ports eth9
   - Create the tap device: tunctl -t eth9
   - Check that the bridge has been created and the interface added to it (bridge shouldn't have an IP configuration at this point):
  root at castiana:~# brctl show br0
  bridge name bridge id STP enabled interfaces
  br0 8000.1a6bffdb2551 no eth9

  The previous release wouldn't do anything unless you were using
  bridge_ports.

  Test for 2)
   - Make sure uml-utilities, bridge-utils and vlan are all intalled
   - Add the following entry to /etc/network/interfaces:
  auto br0
  iface br0 inet static
      address 192.168.1.1
      netmask 255.255.255.0
      bridge-ports eth9.1010
   - Create the tap device: tunctl -t eth9
   - Check that the bridge has been created and the interface added to it (bridge shouldn't have an IP configuration at this point):
  root at castiana:~# brctl show br0
  bridge name bridge id STP enabled interfaces
  br0 8000.06c2192d61ab no eth9.1010

  The previous release would create the bridge but not add the port to
  it as the tag interface wouldn't exist.

  Between each test, cleanup with:
   - tunctl -d eth9
   - ifconfig br0 down
   - brctl delbr br0

  The use of eth9 instead of tap0 is done on purpose as the vlan script
  explicitly checks for interfaces with eth, bond or wlan in their name.

  === vlan ===
  Here's a quick example of how to test the new vlan package:

   - Make sure uml-utilities and vlan are installed
   - Add the following entry to /etc/network/interfaces:
  auto eth9.1010
  iface eth9.1010 inet static
      address 192.168.1.1
      netmask 255.255.255.0
   - Create the tap device: tunctl -t eth9
   - Check that the vlan interface has been created and configured correctly: ifconfig eth9.1010
  eth9.1010 Link encap:Ethernet HWaddr ce:51:62:98:16:78
            inet addr:192.168.1.1 Bcast:0.0.0.0 Mask:255.255.255.0
            UP BROADCAST MULTICAST MTU:1500 Metric:1
            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
            collisions:0 txqueuelen:0
            RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

  Prior to this update, vlan interface creation would be racy as it'd
  depend on the catch all networking.conf job to initialise eth9.1010
  with the race being that this job would be triggered before eth9
  actually exists.

  === ifenslave-2.6 ===
  TODO: Using setup from original description before/after should work but I'll comment with a simplified testcase when I have a minute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bridge-utils/+bug/889423/+subscriptions