bonding.txt

linux 内核源代码

		Linux Ethernet Bonding Driver HOWTO

		Latest update: 24 April 2006

Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
  - Willy Tarreau <willy at meta-x.org>
  - Constantine Gavrilov <const-g at xpert.com>
  - Chad N. Tindel <ctindel at ieee dot org>
  - Janice Girouard <girouard at us dot ibm dot com>
  - Jay Vosburgh <fubar at us dot ibm dot com>

Reorganized and updated Feb 2005 by Jay Vosburgh
Added Sysfs information: 2006/04/24
  - Mitch Williams <mitch.a.williams at intel.com>

Introduction
============

	The Linux bonding driver provides a method for aggregating
multiple network interfaces into a single logical "bonded" interface.
The behavior of the bonded interfaces depends upon the mode; generally
speaking, modes provide either hot standby or load balancing services.
Additionally, link integrity monitoring may be performed.
	
	The bonding driver originally came from Donald Becker's
beowulf patches for kernel 2.0. It has changed quite a bit since, and
the original tools from extreme-linux and beowulf sites will not work
with this version of the driver.

	For new versions of the driver, updated userspace tools, and
who to ask for help, please follow the links at the end of this file.

Table of Contents
=================

1. Bonding Driver Installation

2. Bonding Driver Options

3. Configuring Bonding Devices
3.1	Configuration with Sysconfig Support
3.1.1		Using DHCP with Sysconfig
3.1.2		Configuring Multiple Bonds with Sysconfig
3.2	Configuration with Initscripts Support
3.2.1		Using DHCP with Initscripts
3.2.2		Configuring Multiple Bonds with Initscripts
3.3	Configuring Bonding Manually with Ifenslave
3.3.1		Configuring Multiple Bonds Manually
3.4	Configuring Bonding Manually via Sysfs

4. Querying Bonding Configuration
4.1	Bonding Configuration
4.2	Network Configuration

5. Switch Configuration

6. 802.1q VLAN Support

7. Link Monitoring
7.1	ARP Monitor Operation
7.2	Configuring Multiple ARP Targets
7.3	MII Monitor Operation

8. Potential Trouble Sources
8.1	Adventures in Routing
8.2	Ethernet Device Renaming
8.3	Painfully Slow Or No Failed Link Detection By Miimon

9. SNMP agents

10. Promiscuous mode

11. Configuring Bonding for High Availability
11.1	High Availability in a Single Switch Topology
11.2	High Availability in a Multiple Switch Topology
11.2.1		HA Bonding Mode Selection for Multiple Switch Topology
11.2.2		HA Link Monitoring for Multiple Switch Topology

12. Configuring Bonding for Maximum Throughput
12.1	Maximum Throughput in a Single Switch Topology
12.1.1		MT Bonding Mode Selection for Single Switch Topology
12.1.2		MT Link Monitoring for Single Switch Topology
12.2	Maximum Throughput in a Multiple Switch Topology
12.2.1		MT Bonding Mode Selection for Multiple Switch Topology
12.2.2		MT Link Monitoring for Multiple Switch Topology

13. Switch Behavior Issues
13.1	Link Establishment and Failover Delays
13.2	Duplicated Incoming Packets

14. Hardware Specific Considerations
14.1	IBM BladeCenter

15. Frequently Asked Questions

16. Resources and Links


1. Bonding Driver Installation
==============================

	Most popular distro kernels ship with the bonding driver
already available as a module and the ifenslave user level control
program installed and ready for use. If your distro does not, or you
have need to compile bonding from source (e.g., configuring and
installing a mainline kernel from kernel.org), you'll need to perform
the following steps:

1.1 Configure and build the kernel with bonding
-----------------------------------------------

	The current version of the bonding driver is available in the
drivers/net/bonding subdirectory of the most recent kernel source
(which is available on http://kernel.org).  Most users "rolling their
own" will want to use the most recent kernel from kernel.org.

	Configure kernel with "make menuconfig" (or "make xconfig" or
"make config"), then select "Bonding driver support" in the "Network
device support" section.  It is recommended that you configure the
driver as module since it is currently the only way to pass parameters
to the driver or configure more than one bonding device.

	Build and install the new kernel and modules, then continue
below to install ifenslave.

1.2 Install ifenslave Control Utility
-------------------------------------

	The ifenslave user level control program is included in the
kernel source tree, in the file Documentation/networking/ifenslave.c.
It is generally recommended that you use the ifenslave that
corresponds to the kernel that you are using (either from the same
source tree or supplied with the distro), however, ifenslave
executables from older kernels should function (but features newer
than the ifenslave release are not supported).  Running an ifenslave
that is newer than the kernel is not supported, and may or may not
work.

	To install ifenslave, do the following:

# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
# cp ifenslave /sbin/ifenslave

	If your kernel source is not in "/usr/src/linux," then replace
"/usr/src/linux/include" in the above with the location of your kernel
source include directory.

	You may wish to back up any existing /sbin/ifenslave, or, for
testing or informal use, tag the ifenslave to the kernel version
(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).

IMPORTANT NOTE:

	If you omit the "-I" or specify an incorrect directory, you
may end up with an ifenslave that is incompatible with the kernel
you're trying to build it for.  Some distros (e.g., Red Hat from 7.1
onwards) do not have /usr/include/linux symbolically linked to the
default kernel source include directory.

SECOND IMPORTANT NOTE:
	If you plan to configure bonding using sysfs, you do not need
to use ifenslave.

2. Bonding Driver Options
=========================

	Options for the bonding driver are supplied as parameters to
the bonding module at load time.  They may be given as command line
arguments to the insmod or modprobe command, but are usually specified
in either the /etc/modules.conf or /etc/modprobe.conf configuration
file, or in a distro-specific configuration file (some of which are
detailed in the next section).

	The available bonding driver parameters are listed below. If a
parameter is not specified the default value is used.  When initially
configuring a bond, it is recommended "tail -f /var/log/messages" be
run in a separate window to watch for bonding driver error messages.

	It is critical that either the miimon or arp_interval and
arp_ip_target parameters be specified, otherwise serious network
degradation will occur during link failures.  Very few devices do not
support at least miimon, so there is really no reason not to use it.

	Options with textual values will accept either the text name
or, for backwards compatibility, the option value.  E.g.,
"mode=802.3ad" and "mode=4" set the same mode.

	The parameters are as follows:

arp_interval

	Specifies the ARP link monitoring frequency in milliseconds.

	The ARP monitor works by periodically checking the slave
	devices to determine whether they have sent or received
	traffic recently (the precise criteria depends upon the
	bonding mode, and the state of the slave).  Regular traffic is
	generated via ARP probes issued for the addresses specified by
	the arp_ip_target option.

	This behavior can be modified by the arp_validate option,
	below.

	If ARP monitoring is used in an etherchannel compatible mode
	(modes 0 and 2), the switch should be configured in a mode
	that evenly distributes packets across all links. If the
	switch is configured to distribute the packets in an XOR
	fashion, all replies from the ARP targets will be received on
	the same link which could cause the other team members to
	fail.  ARP monitoring should not be used in conjunction with
	miimon.  A value of 0 disables ARP monitoring.  The default
	value is 0.

arp_ip_target

	Specifies the IP addresses to use as ARP monitoring peers when
	arp_interval is > 0.  These are the targets of the ARP request
	sent to determine the health of the link to the targets.
	Specify these values in ddd.ddd.ddd.ddd format.  Multiple IP
	addresses must be separated by a comma.  At least one IP
	address must be given for ARP monitoring to function.  The
	maximum number of targets that can be specified is 16.  The
	default value is no IP addresses.

arp_validate

	Specifies whether or not ARP probes and replies should be
	validated in the active-backup mode.  This causes the ARP
	monitor to examine the incoming ARP requests and replies, and
	only consider a slave to be up if it is receiving the
	appropriate ARP traffic.

	Possible values are:

	none or 0

		No validation is performed.  This is the default.

	active or 1

		Validation is performed only for the active slave.

	backup or 2

		Validation is performed only for backup slaves.

	all or 3

		Validation is performed for all slaves.

	For the active slave, the validation checks ARP replies to
	confirm that they were generated by an arp_ip_target.  Since
	backup slaves do not typically receive these replies, the
	validation performed for backup slaves is on the ARP request
	sent out via the active slave.  It is possible that some
	switch or network configurations may result in situations
	wherein the backup slaves do not receive the ARP requests; in
	such a situation, validation of backup slaves must be
	disabled.

	This option is useful in network configurations in which
	multiple bonding hosts are concurrently issuing ARPs to one or
	more targets beyond a common switch.  Should the link between
	the switch and target fail (but not the switch itself), the
	probe traffic generated by the multiple bonding instances will
	fool the standard ARP monitor into considering the links as
	still up.  Use of the arp_validate option can resolve this, as
	the ARP monitor will only consider ARP requests and replies
	associated with its own instance of bonding.

	This option was added in bonding version 3.1.0.

downdelay

	Specifies the time, in milliseconds, to wait before disabling
	a slave after a link failure has been detected.  This option
	is only valid for the miimon link monitor.  The downdelay
	value should be a multiple of the miimon value; if not, it
	will be rounded down to the nearest multiple.  The default
	value is 0.

fail_over_mac

	Specifies whether active-backup mode should set all slaves to
	the same MAC address (the traditional behavior), or, when
	enabled, change the bond's MAC address when changing the
	active interface (i.e., fail over the MAC address itself).

	Fail over MAC is useful for devices that cannot ever alter
	their MAC address, or for devices that refuse incoming
	broadcasts with their own source MAC (which interferes with
	the ARP monitor).

	The down side of fail over MAC is that every device on the
	network must be updated via gratuitous ARP, vs. just updating
	a switch or set of switches (which often takes place for any
	traffic, not just ARP traffic, if the switch snoops incoming
	traffic to update its tables) for the traditional method.  If
	the gratuitous ARP is lost, communication may be disrupted.

	When fail over MAC is used in conjuction with the mii monitor,
	devices which assert link up prior to being able to actually
	transmit and receive are particularly susecptible to loss of
	the gratuitous ARP, and an appropriate updelay setting may be
	required.

	A value of 0 disables fail over MAC, and is the default.  A
	value of 1 enables fail over MAC.  This option is enabled
	automatically if the first slave added cannot change its MAC
	address.  This option may be modified via sysfs only when no
	slaves are present in the bond.

	This option was added in bonding version 3.2.0.

lacp_rate

	Option specifying the rate in which we'll ask our link partner
	to transmit LACPDU packets in 802.3ad mode.  Possible values
	are:

	slow or 0
		Request partner to transmit LACPDUs every 30 seconds

	fast or 1
		Request partner to transmit LACPDUs every 1 second