Bonding configuration change in Precise provides no automatic upgrade path

Bug #974218 reported by marcelo
36
This bug affects 7 people
Affects Status Importance Assigned to Milestone
ifenslave-2.6 (Ubuntu)
Won't Fix
Wishlist
Unassigned

Bug Description

Hi,

I use ubuntu in my server, i have two interfaces bonds connected,
bond0 -> eth2 and eth3
bond1 -> eth3 and eth4

In old versions the package ifenslave, my interface bound, works without problems

But in latest version the package ( 1.1.0-19ubuntu5 ) , the interface up but not ping.

Now i use version ifenslave-2.6 (1.1.0-19ubuntu1) and my interfaces works without problems.

My archive :
/etc/init.d/network/interfaces :

auto bond0
iface bond0 inet static
   pre-up ip link set eth2 up
   pre-up ip link set eth3 up
   address 192.168.0.2
   broadcast 192.168.0.255
   post-up ifconfig bond0 mtu 9000
   netmask 255.255.255.0
   slaves eth2 eth3
   bond_mode broadcast
   bond_miimon 100
   bond_updelay 200
   bond_downdelay 500
   bond_usecarrier 1
auto bond1
iface bond1 inet static
   broadcast 192.168.1.255
   address 192.168.2.2
   pre-up ip link set eth4 up
   pre-up ip link set eth5 up
   netmask 255.255.255.0
   post-up ifconfig bond1 mtu 9000
   slaves eth4 eth5
   bond_mode broadcast
   bond_miimon 100
   bond_updelay 200
   bond_downdelay 500
   bond_usecarrier 1

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ifenslave-2.6 (Ubuntu):
status: New → Confirmed
Revision history for this message
Robie Basak (racb) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better.

The format of /etc/network/interfaces for bonding interfaces appears to have changed in order to avoid a race condition. I think you might be falling on the wrong side of the race. Please see /usr/share/doc/ifenslave-2.6/README.Debian.gz, or online at:

http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ifenslave-2.6/precise/view/head:/debian/README.Debian (line 39).

I think the real bug here is that there is no automatic upgrade path regarding this change, or documentation in a place that users can spot before upgrading.

Unfortunately I think it's too risky to try and add an automatic upgrade path this close to release as it would not receive sufficient testing. The workaround is to fix up /etc/network/interfaces to the latest syntax by hand.

Revision history for this message
marcelo (mensagens) wrote :

Dear,

Thanks, for attention and response my question .

From what I understand in documentation my configuration archive, should look like this:
Am I correct?

auto eth2
iface eth2 inet manual
 bond-master bond0
 bond-primary eth2 eth3

auto eth3
iface eth3 inet manual
 bond-master bond0
 bond-primary eth2 eth3

I will test here .

Best Reguards,
Marcelo Frota

Revision history for this message
Tyler Wagner (tyler) wrote :

From my reading of it, the correct configuration should be:

iface bond0 inet static
   address 192.168.0.1
   netmask 255.255.255.0
   bond_slaves none
   bond_mode broadcast
   bond_miimon 100
   bond_updelay 200
   bond_downdelay 500
   bond_usecarrier 1

auto eth2
iface eth2 inet manual
   bond-master bond0
   bond-primary eth2 eth3
   bond_mode broadcast
   bond_miimon 100
   bond_updelay 200
   bond_downdelay 500
   bond_usecarrier 1

auto eth3
iface eth3 inet manual
   bond-master bond0
   bond-primary eth2 eth3
   bond_mode broadcast
   bond_miimon 100
   bond_updelay 200
   bond_downdelay 500
   bond_usecarrier 1

Note that the bond doesn't come up automatically (no auto statement), and it doesn't list the slaves directly. Instead the physical interfaces come up, and they in turn bring bond0 up. Because of that, the bonding options must be specified on all interfaces.

Have you tested? If so, please report here.

Revision history for this message
simonnix (simon-huet) wrote :

I was unable to make it work as it should.

My setup is as follow :

I have to NIC to bond using the 802.3ad mode. That bond is to be used with VLAN. When started the bond0 interface and my two NICs should have the same MAC address but they do not.

From my reading I should have :
===
auto eth0
iface eth0 inet manual
        bond-master bond0

auto eth1
iface eth1 inet manual
        bond-master bond0

auto bond0
iface bond0 inet manual
        bond-slaves none
        bond-mode 802.3ad
        bond-miimon 100
        bond-updelay 200
        bond-downdelay 500

auto xenbr0
iface xenbr0 inet static
        address 192.168.0.100
        netmask 255.255.255.0
        gateway 192.168.0.1
        bridge_maxwait 10
        bridge_stp on
        bridge_ports bond0.10
===

When doing that setup the bond0 interface comes up but the MAC address does not match.

The only way I had it to work as expected is not to "auto" eth0 and eth1 and use the "up" stanzas to bring those interface inside the bond :

===
iface eth0 inet manual
        bond-master bond0

iface eth1 inet manual
        bond-master bond0

auto bond0
iface bond0 inet manual
        up ifup eth0
        up ifup eth1
        bond-slaves none
        bond-mode 802.3ad
        bond-miimon 100
        bond-updelay 200
        bond-downdelay 500

auto xenbr0
iface xenbr0 inet static
        address 192.168.0.100
        netmask 255.255.255.0
        gateway 192.168.0.1
        bridge_maxwait 10
        bridge_stp on
        bridge_ports bond0.10
===

I tried the "allow-bond0 ethX" stanzas instead of "auto ethX" but it does not seem to work at all.

I tried to reproduce the bond0 configuration parameters inside each NIC but it does not work either.

Now the interface bond0 start with a 60 seconds waiting time at boot (which I reduced in the scripts to 10 seconds).

===

So the event based startup of the bond is broken. Could we have it working once and for all?

Revision history for this message
piontec (piontec-gmail) wrote :

This bus is here for years now. Bonding did work without a porblem some time ago, than something was "fixed" and is not working anymore since then.
I can only confirm that bonding did not start on my ubuntu-server after the upgrade to precise and that the following silly patch helped (see attachment).

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "a patched based on old ifenslave script" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Robie Basak (racb) wrote : Re: Ifenslave-2.6 problem in ubuntu 12;04 precise

@simonnix

You have missing bond-primary directives and auto against bond0 instead of eth0 and eth1. Please re-read Tyler's comment - I think he has it right - and double check against the documentation.

In Precise, the method of specifying bonding has changed, since it changed in Debian. This is because bonding has to be defined from the point of view of each interface instead of the other way round in order to avoid a race condition. This is documented: see http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/ifenslave-2.6/precise/view/head:/debian/README.Debian

Consider the original reporter. He had not changed his configuration to the new form, so bonding did not work for him. So this bug (if any) is that an upgrade does not fix your configuration file for you. Thus I'm happy to leave this bug open on this basis, and if anybody can post a patch that reliably provides an automatic upgrade path, then please do so.

If you are having other problems with bonding not related to the configuration change or upgrade path, then please check carefully against the current documentation and file a new bug.

Changed in ifenslave-2.6 (Ubuntu):
importance: Undecided → Wishlist
status: Confirmed → Triaged
tags: removed: patch
summary: - Ifenslave-2.6 problem in ubuntu 12;04 precise
+ Bonding configuration change in Precise provides no automatic upgrade
+ path
Revision history for this message
piontec (piontec-gmail) wrote :

OK,
Indeed, after configuring /etc/network/interfaces according to the link above, bonding starts with system without a problem! Just for reference, my config looks now like this:
===
#bond
auto bond0
iface bond0 inet manual
 bond_slaves none
        bond_mode 4
        bond_miimon 100
        bond_downdelay 200
        bond_updelay 200
        bond_lacp_rate fast

auto eth0
iface eth0 inet manual
 bond-master bond0
        bond_mode 4
        bond_miimon 100
        bond_downdelay 200
        bond_updelay 200
        bond_lacp_rate fast

auto eth1
iface eth1 inet manual
 bond-master bond0
        bond_mode 4
        bond_miimon 100
        bond_downdelay 200
        bond_updelay 200
        bond_lacp_rate fast
===

@Robie, thanks for your help

Revision history for this message
Stéphane Graber (stgraber) wrote :

I'm not planning on offering any automated conversion, mostly because the actual configuration syntax hasn't changed, the ordering change is there only to make "ifup -a" work and nothing else.

As such any system that was properly configured based on the ifenslave documentation in past releases will work just as well on 12.04, the change is that ifenslave now requires you to configure your bond properly (matching the documentation) or it'll end up waiting for minutes for things to happen (that never will).

These changes were mentioned in the release notes, blogged about and referenced everywhere relevant, so I don't think it's worth spending any extra time dealing with broken configs.

Changed in ifenslave-2.6 (Ubuntu):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.