Mailinglist Archive: opensuse (4237 mails)

< Previous Next >
SuSE 9.0 Channel Bonding Quirk, ifenslave bad compile? Working mini-howto!
  • From: Randy Rue <rrue@xxxxxxxxx>
  • Date: Fri, 27 Aug 2004 11:40:58 -0700
  • Message-id: <412F803A.5010000@xxxxxxxxx>
Hello All,

After testing it appears that Channel Bonding in SuSE 9.0 is not reliable. The NIC team appears to load normally but does not consistently fail over when a cable is disconnected. More specifically, the team fails over without a hitch but whichever slave interface was added to the team last will not function normally, and the team won't function until the first NIC is reconnected AND the second NIC disconnected (forcing the team to pick the first NIC back up). This was confirmed by reversing the order of the bonded slave interfaces attached in the "ifenslave" command: changing the command from 'ifenslave bond0 eth0 eth1' to ifenslave bond0 eth1 eth0' made the problem reverse itself.

It appears that the default compile of ifenslave included with SuSE 9.0 ignores the instructions in /usr/src/linux-2.4.21-226/Documentation/networking/bonding.txt and compiles using the header file if_bonding.h found in /usr/include/linux instead of the proper one in the kernel source directory /usr/src/linux/include. Recompiling and replacing the executable makes it work. A running ping session stutters briefly when the active NIC is disconnected, but only a few packets are dropped (about 1 ping out of 50). After about 30 seconds, the connection pings reliably (I have let it run for as many as 1000 pings without dropping any packets).

The good news is that the proper version of ifenslave now supports mode 6 (adaptive load balancing), providing both fault-tolerance and aggregated throughput.

I have attached a mini-howto.

I encourage you all to test and experiment with this,

Randy Rue

Randall Rue
System Administrator, Postmaster
IT, Server Operations
Fred Hutchinson Cancer Research Center
Seattle, WA
USA



*NETWORK INTERFACE TEAMING USING KERNEL-BASED CHANNEL BONDING IN SuSE 9.0*

* *

*Version 2.0 **August 27, 2004***

1. Use yast to configure both Ethernet interfaces as DHCP clients.

2. Recompile the executable /sbin/ifenslave (SuSE’s default compile
of this command uses the wrong header files, and will appear to
load normally, but does not function properly):

/a. //Find the file ‘ifenslave.c” using ‘locate ifenslave.c” and cd to its directory./

/b. //gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave/

/c. //mv /sbin/ifenslave /sbin/ifenslave.orig/

/d. //mv ifenslave /sbin/ifenslave/

3. Add the following two lines to /etc/modules.conf.local:

/alias bond0 bonding/

/options bonding miimon=100 mode=6/

/ /

4. Edit /etc/sysconfig/network/ifcfg-ethX for each of the interfaces
eth0 and eth1 (or whatever physical interfaces are to be bonded):
1. Retain the “/Unique=’xxxyyyzzz’/” defined by yast
2. Otherwise modify the files as shown:

/DEVICE='ethX'/

/USERCTL='no'/

/ONBOOT='yes'/

/STARTMODE='onboot'/

/MASTER='bond0'/

/SLAVE='yes'/

/BOOTPROTO='none'/

/UNIQUE=’xxxyyyzzz’/

/ /

5. Create a file /etc/sysconfig/network/ifcfg-bond0 with the same
permissions as the other ifcfg-xxx files:

/DEVICE='bond0'/

/IPADDR='www.xxx.yyy.zzz'/

/NETMASK='255.255.25y.0'/

/NETWORK='www.xxx.yyy.0'/

/BROADCAST='www.xxx.yyy.255'/

/STARTMODE='onboot'/

/BOOTPROTO='static'/

/USERCTL='no'/

/BONDING_MASTER='yes'/

/BONDING_SLAVE0='eth0'/

/BONDING_SLAVE1='eth1'/

/ /

6. Edit /etc/init.d/network: to the end of the “start” case statement
(approximately line 200), add the following two lines as shown.

*Before:*

/ esac/

/ rc_reset/

/ done/

/ [ ! -z "$WAIT_FOR_INTERFACES" ] && sleep $WAIT_FOR_INTERFACES/

*After:*

/ esac/

/ rc_reset/

/ done/

*/ ## Added to start NIC bonding when starting network ##/*

*/ /sbin/ifenslave bond0 eth0 eth1/*

/ [ ! -z "$WAIT_FOR_INTERFACES" ] && sleep $WAIT_FOR_INTERFACES/

7. Restart the network interfaces ( “rcnetwork restart”) and test for
proper configuration using ping, ifconfig and “cat
/proc/net/bond0/info”

8. Reboot the machine and test again for proper configuration.

9. Start a ping (i.e. /ping yahoo.com/) and test that the process
recovers and continues when either interface is disconnected.


< Previous Next >
Follow Ups