Merge head 'upstream-fixes' of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
Merge commit. Changes below are compared with the first parent: e0b98c79.
Changes
7 files changed · +807 −459
| File | Status | Add | Del | Content |
|---|---|---|---|---|
| Documentation/networking/bonding.txt | modified | +677 | −301 | View file |
| drivers/net/hamradio/Kconfig | modified | +1 | −1 | View file |
| drivers/net/sk98lin/skgeinit.c | modified | +1 | −1 | View file |
| drivers/net/sk98lin/skxmac2.c | modified | +4 | −4 | View file |
| drivers/net/skge.c | modified | +108 | −125 | View file |
| drivers/net/skge.h | modified | +15 | −26 | View file |
| drivers/net/smc91x.h | modified | +1 | −1 | View file |
Only the first 600 diff lines are shown. Download the complete patch.
Documentation/networking/bonding.txt
View filediff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 0bc2ed1..24d0294 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -1,5 +1,7 @@
- Linux Ethernet Bonding Driver HOWTO
+ Linux Ethernet Bonding Driver HOWTO
+
+ Latest update: 21 June 2005
Initial release : Thomas Davis <tadavis at lbl.gov>
Corrections, HA extensions : 2000/10/03-15 :
@@ -11,15 +13,22 @@ Corrections, HA extensions : 2000/10/03-15 :
Reorganized and updated Feb 2005 by Jay Vosburgh
-Note :
-------
+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.
+ 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, patches for older kernels and the updated
-userspace tools, please follow the links at the end of this file.
+ 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
=================
@@ -30,9 +39,13 @@ Table of Contents
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
-3.4 Configuring Multiple Bonds
+3.3.1 Configuring Multiple Bonds Manually
5. Querying Bonding Configuration
5.1 Bonding Configuration
@@ -56,21 +69,30 @@ Table of Contents
11. Promiscuous mode
-12. High Availability Information
+12. Configuring Bonding for High Availability
12.1 High Availability in a Single Switch Topology
-12.1.1 Bonding Mode Selection for Single Switch Topology
-12.1.2 Link Monitoring for Single Switch Topology
12.2 High Availability in a Multiple Switch Topology
-12.2.1 Bonding Mode Selection for Multiple Switch Topology
-12.2.2 Link Monitoring for Multiple Switch Topology
-12.3 Switch Behavior Issues for High Availability
+12.2.1 HA Bonding Mode Selection for Multiple Switch Topology
+12.2.2 HA Link Monitoring for Multiple Switch Topology
+
+13. Configuring Bonding for Maximum Throughput
+13.1 Maximum Throughput in a Single Switch Topology
+13.1.1 MT Bonding Mode Selection for Single Switch Topology
+13.1.2 MT Link Monitoring for Single Switch Topology
+13.2 Maximum Throughput in a Multiple Switch Topology
+13.2.1 MT Bonding Mode Selection for Multiple Switch Topology
+13.2.2 MT Link Monitoring for Multiple Switch Topology
-13. Hardware Specific Considerations
-13.1 IBM BladeCenter
+14. Switch Behavior Issues
+14.1 Link Establishment and Failover Delays
+14.2 Duplicated Incoming Packets
-14. Frequently Asked Questions
+15. Hardware Specific Considerations
+15.1 IBM BladeCenter
-15. Resources and Links
+16. Frequently Asked Questions
+
+17. Resources and Links
1. Bonding Driver Installation
@@ -86,16 +108,10 @@ the following steps:
1.1 Configure and build the kernel with bonding
-----------------------------------------------
- The latest version of the bonding driver is available in the
+ 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).
-
- Prior to the 2.4.11 kernel, the bonding driver was maintained
-largely outside the kernel tree; patches for some earlier kernels are
-available on the bonding sourceforge site, although those patches are
-still several years out of date. Most users will want to use either
-the most recent kernel from kernel.org or whatever kernel came with
-their distro.
+(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
@@ -103,8 +119,8 @@ 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 proceed to
-step 2.
+ Build and install the new kernel and modules, then continue
+below to install ifenslave.
1.2 Install ifenslave Control Utility
-------------------------------------
@@ -147,9 +163,9 @@ default kernel source include directory.
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/modprobe.conf configuration file, or in a
-distro-specific configuration file (some of which are detailed in the
-next section).
+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
@@ -162,34 +178,34 @@ 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.
+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 monitoring frequency in milli-seconds. If
- ARP monitoring is used in a load-balancing mode (mode 0 or 2),
- the switch should be configured in a mode that evenly
- distributes packets across all links - such as round-robin. If
- the switch is configured to distribute the packets in an XOR
+ Specifies the ARP link monitoring frequency in milliseconds.
+ 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
+ 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 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 adresses must be
- seperated 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.
+ 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.
downdelay
@@ -207,11 +223,13 @@ lacp_rate
are:
slow or 0
- Request partner to transmit LACPDUs every 30 seconds (default)
+ Request partner to transmit LACPDUs every 30 seconds
fast or 1
Request partner to transmit LACPDUs every 1 second
+ The default is slow.
+
max_bonds
Specifies the number of bonding devices to create for this
@@ -221,10 +239,11 @@ max_bonds
miimon
- Specifies the frequency in milli-seconds that MII link
- monitoring will occur. A value of zero disables MII link
- monitoring. A value of 100 is a good starting point. The
- use_carrier option, below, affects how the link state is
+ Specifies the MII link monitoring frequency in milliseconds.
+ This determines how often the link state of each slave is
+ inspected for link failures. A value of zero disables MII
+ link monitoring. A value of 100 is a good starting point.
+ The use_carrier option, below, affects how the link state is
determined. See the High Availability section for additional
information. The default value is 0.
@@ -246,17 +265,31 @@ mode
active. A different slave becomes active if, and only
if, the active slave fails. The bond's MAC address is
externally visible on only one port (network adapter)
- to avoid confusing the switch. This mode provides
- fault tolerance. The primary option affects the
- behavior of this mode.
+ to avoid confusing the switch.
+
+ In bonding version 2.6.2 or later, when a failover
+ occurs in active-backup mode, bonding will issue one
+ or more gratuitous ARPs on the newly active slave.
+ One gratutious ARP is issued for the bonding master
+ interface and each VLAN interfaces configured above
+ it, provided that the interface has at least one IP
+ address configured. Gratuitous ARPs issued for VLAN
+ interfaces are tagged with the appropriate VLAN id.
+
+ This mode provides fault tolerance. The primary
+ option, documented below, affects the behavior of this
+ mode.
balance-xor or 2
- XOR policy: Transmit based on [(source MAC address
- XOR'd with destination MAC address) modulo slave
- count]. This selects the same slave for each
- destination MAC address. This mode provides load
- balancing and fault tolerance.
+ XOR policy: Transmit based on the selected transmit
+ hash policy. The default policy is a simple [(source
+ MAC address XOR'd with destination MAC address) modulo
+ slave count]. Alternate transmit policies may be
+ selected via the xmit_hash_policy option, described
+ below.
+
+ This mode provides load balancing and fault tolerance.
broadcast or 3
@@ -270,7 +303,17 @@ mode
duplex settings. Utilizes all slaves in the active
aggregator according to the 802.3ad specification.
- Pre-requisites:
+ Slave selection for outgoing traffic is done according
+ to the transmit hash policy, which may be changed from
+ the default simple XOR policy via the xmit_hash_policy
+ option, documented below. Note that not all transmit
+ policies may be 802.3ad compliant, particularly in
+ regards to the packet mis-ordering requirements of
+ section 43.2.4 of the 802.3ad standard. Differing
+ peer implementations will have varying tolerances for
+ noncompliance.
+
+ Prerequisites:
1. Ethtool support in the base drivers for retrieving
the speed and duplex of each slave.
@@ -333,7 +376,7 @@ mode
When a link is reconnected or a new slave joins the
bond the receive traffic is redistributed among all
- active slaves in the bond by intiating ARP Replies
+ active slaves in the bond by initiating ARP Replies
with the selected mac address to each of the
clients. The updelay parameter (detailed below) must
be set to a value equal or greater than the switch's
@@ -396,6 +439,60 @@ use_carrier
0 will use the deprecated MII / ETHTOOL ioctls. The default
value is 1.
+xmit_hash_policy
+
+ Selects the transmit hash policy to use for slave selection in
+ balance-xor and 802.3ad modes. Possible values are:
+
+ layer2
+
+ Uses XOR of hardware MAC addresses to generate the
+ hash. The formula is
+
+ (source MAC XOR destination MAC) modulo slave count
+
+ This algorithm will place all traffic to a particular
+ network peer on the same slave.
+
+ This algorithm is 802.3ad compliant.
+
+ layer3+4
+
+ This policy uses upper layer protocol information,
+ when available, to generate the hash. This allows for
+ traffic to a particular network peer to span multiple
+ slaves, although a single connection will not span
+ multiple slaves.
+
+ The formula for unfragmented TCP and UDP packets is
+
+ ((source port XOR dest port) XOR
+ ((source IP XOR dest IP) AND 0xffff)
+ modulo slave count
+
+ For fragmented TCP or UDP packets and all other IP
+ protocol traffic, the source and destination port
+ information is omitted. For non-IP traffic, the
+ formula is the same as for the layer2 transmit hash
+ policy.
+
+ This policy is intended to mimic the behavior of
+ certain switches, notably Cisco switches with PFC2 as
+ well as some Foundry and IBM products.
+
+ This algorithm is not fully 802.3ad compliant. A
+ single TCP or UDP conversation containing both
+ fragmented and unfragmented packets will see packets
+ striped across two interfaces. This may result in out
+ of order delivery. Most traffic types will not meet
+ this criteria, as TCP rarely fragments traffic, and
+ most UDP traffic is not involved in extended
+ conversations. Other implementations of 802.3ad may
+ or may not tolerate this noncompliance.
+
+ The default value is layer2. This option was added in bonding
+version 2.6.3. In earlier versions of bonding, this parameter does
+not exist, and the layer2 policy is the only policy.
3. Configuring Bonding Devices
@@ -448,8 +545,9 @@ Bonding devices can be managed by hand, however, as follows.
slave devices. On SLES 9, this is most easily done by running the
yast2 sysconfig configuration utility. The goal is for to create an
ifcfg-id file for each slave device. The simplest way to accomplish
-this is to configure the devices for DHCP. The name of the
-configuration file for each device will be of the form:
+this is to configure the devices for DHCP (this is only to get the
+file ifcfg-id file created; see below for some issues with DHCP). The
+name of the configuration file for each device will be of the form:
ifcfg-id-xx:xx:xx:xx:xx:xx
@@ -459,7 +557,7 @@ the device's permanent MAC address.
Once the set of ifcfg-id-xx:xx:xx:xx:xx:xx files has been
created, it is necessary to edit the configuration files for the slave
devices (the MAC addresses correspond to those of the slave devices).
-Before editing, the file will contain muliple lines, and will look
+Before editing, the file will contain multiple lines, and will look
something like this:
BOOTPROTO='dhcp'
@@ -496,16 +594,11 @@ STARTMODE="onboot"
BONDING_MASTER="yes"
BONDING_MODULE_OPTS="mode=active-backup miimon=100"
BONDING_SLAVE0="eth0"
-BONDING_SLAVE1="eth1"
+BONDING_SLAVE1="bus-pci-0000:06:08.1"
Replace the sample BROADCAST, IPADDR, NETMASK and NETWORK
values with the appropriate values for your network.
- Note that configuring the bonding device with BOOTPROTO='dhcp'
-does not work; the scripts attempt to obtain the device address from
-DHCP prior to adding any of the slave devices. Without active slaves,
-the DHCP requests are not sent to the network.
-
The STARTMODE specifies when the device is brought online.
The possible values are:
@@ -531,9 +624,17 @@ for the bonding mode, link monitoring, and so on here. Do not include
the max_bonds bonding parameter; this will confuse the configuration
system if you have multiple bonding devices.
- Finally, supply one BONDING_SLAVEn="ethX" for each slave,
-where "n" is an increasing value, one for each slave, and "ethX" is
-the name of the slave device (eth0, eth1, etc).
+ Finally, supply one BONDING_SLAVEn="slave device" for each
+slave. where "n" is an increasing value, one for each slave. The
+"slave device" is either an interface name, e.g., "eth0", or a device
+specifier for the network device. The interface name is easier to
+find, but the ethN names are subject to change at boot time if, e.g.,
+a device early in the sequence has failed. The device specifiers
+(bus-pci-0000:06:08.1 in the example above) specify the physical
+network device, and will not change unless the device's bus location
+changes (for example, it is moved from one PCI slot to another). The
+example above uses one of each type for demonstration purposes; most
+configurations will choose one or the other for all slave devices.
When all configuration files have been modified or created,
networking must be restarted for the configuration changes to take
@@ -544,7 +645,7 @@ effect. This can be accomplished via the following:
Note that the network control script (/sbin/ifdown) will
remove the bonding module as part of the network shutdown processing,
so it is not necessary to remove the module by hand if, e.g., the
-module paramters have changed.
+module parameters have changed.
Also, at this writing, YaST/YaST2 will not manage bonding
devices (they do not show bonding interfaces on its list of network
@@ -559,12 +660,37 @@ format can be found in an example ifcfg template file:
Note that the template does not document the various BONDING_
settings described above, but does describe many of the other options.
+3.1.1 Using DHCP with sysconfig
+-------------------------------
+
+ Under sysconfig, configuring a device with BOOTPROTO='dhcp'
+will cause it to query DHCP for its IP address information. At this
+writing, this does not function for bonding devices; the scripts
+attempt to obtain the device address from DHCP prior to adding any of
+the slave devices. Without active slaves, the DHCP requests are not
+sent to the network.
+
+3.1.2 Configuring Multiple Bonds with sysconfig
+-----------------------------------------------
+
+ The sysconfig network initialization system is capable of
+handling multiple bonding devices. All that is necessary is for each
+bonding instance to have an appropriately configured ifcfg-bondX file
+(as described above). Do not specify the "max_bonds" parameter to any
+instance of bonding, as this will confuse sysconfig. If you require
+multiple bonding devices with identical parameters, create multiple
+ifcfg-bondX files.
+
+ Because the sysconfig scripts supply the bonding module
+options in the ifcfg-bondX file, it is not necessary to add them to
+the system /etc/modules.conf or /etc/modprobe.conf configuration file.
+
3.2 Configuration with initscripts support
------------------------------------------
This section applies to distros using a version of initscripts
with bonding support, for example, Red Hat Linux 9 or Red Hat
-Enterprise Linux version 3. On these systems, the network
+Enterprise Linux version 3 or 4. On these systems, the network
initialization scripts have some knowledge of bonding, and can be
configured to control bonding devices.
@@ -614,10 +740,11 @@ USERCTL=no
Be sure to change the networking specific lines (IPADDR,
NETMASK, NETWORK and BROADCAST) to match your network configuration.
- Finally, it is necessary to edit /etc/modules.conf to load the
-bonding module when the bond0 interface is brought up. The following
-sample lines in /etc/modules.conf will load the bonding module, and
-select its options:
+ Finally, it is necessary to edit /etc/modules.conf (or
+/etc/modprobe.conf, depending upon your distro) to load the bonding
+module with your desired options when the bond0 interface is brought
+up. The following lines in /etc/modules.conf (or modprobe.conf) will
+load the bonding module, and select its options:
alias bond0 bonding
options bond0 mode=balance-alb miimon=100
@@ -629,6 +756,33 @@ options for your configuration.
will restart the networking subsystem and your bond link should be now
up and running.
+3.2.1 Using DHCP with initscripts
+---------------------------------
+
+ Recent versions of initscripts (the version supplied with
+Fedora Core 3 and Red Hat Enterprise Linux 4 is reported to work) do
+have support for assigning IP information to bonding devices via DHCP.
+
+ To configure bonding for DHCP, configure it as described
+above, except replace the line "BOOTPROTO=none" with "BOOTPROTO=dhcp"
+and add a line consisting of "TYPE=Bonding". Note that the TYPE value
+is case sensitive.
+
+3.2.2 Configuring Multiple Bonds with initscripts
+-------------------------------------------------
+
+ At this writing, the initscripts package does not directly
+support loading the bonding driver multiple times, so the process for
+doing so is the same as described in the "Configuring Multiple Bonds
+Manually" section, below.
+
+ NOTE: It has been observed that some Red Hat supplied kernels
+are apparently unable to rename modules at load time (the "-obonding1"
+part). Attempts to pass that option to modprobe will produce an
+"Operation not permitted" error. This has been reported on some
+Fedora Core kernels, and has been seen on RHEL 4 as well. On kernels
+exhibiting this problem, it will be impossible to configure multiple
+bonds with differing parameters.
3.3 Configuring Bonding Manually
--------------------------------
@@ -638,10 +792,11 @@ scripts (the sysconfig or initscripts package) do not have specific
knowledge of bonding. One such distro is SuSE Linux Enterprise Server
version 8.
- The general methodology for these systems is to place the
-bonding module parameters into /etc/modprobe.conf, then add modprobe
-and/or ifenslave commands to the system's global init script. The
-name of the global init script differs; for sysconfig, it is
+ The general method for these systems is to place the bonding
+module parameters into /etc/modules.conf or /etc/modprobe.conf (as
+appropriate for the installed distro), then add modprobe and/or
+ifenslave commands to the system's global init script. The name of
+the global init script differs; for sysconfig, it is
/etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
For example, if you wanted to make a simple bond of two e100
@@ -649,7 +804,7 @@ devices (presumed to be eth0 and eth1), and have it persist across
reboots, edit the appropriate file (/etc/init.d/boot.local or
/etc/rc.d/rc.local), and add the following:
-modprobe bonding -obond0 mode=balance-alb miimon=100
+modprobe bonding mode=balance-alb miimon=100
modprobe e100
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
ifenslave bond0 eth0
@@ -657,11 +812,7 @@ ifenslave bond0 eth1
Replace the example bonding module parameters and bond0
network configuration (IP address, netmask, etc) with the appropriate
-values for your configuration. The above example loads the bonding
-module with the name "bond0," this simplifies the naming if multiple
-bonding modules are loaded (each successive instance of the module is
-given a different name, and the module instance names match the
-bonding interface names).
+values for your configuration.
Unfortunately, this method will not provide support for the
ifup and ifdown scripts on the bond devices. To reload the bonding
@@ -684,20 +835,23 @@ appropriate device driver modules. For our example above, you can do
the following:
# ifconfig bond0 down
-# rmmod bond0
+# rmmod bonding
# rmmod e100
Again, for convenience, it may be desirable to create a script
with these commands.
-3.4 Configuring Multiple Bonds
-------------------------------
+3.3.1 Configuring Multiple Bonds Manually
+-----------------------------------------
This section contains information on configuring multiple
-bonding devices with differing options. If you require multiple
-bonding devices, but all with the same options, see the "max_bonds"
-module paramter, documented above.
+bonding devices with differing options for those systems whose network
+initialization scripts lack support for configuring multiple bonds.
+
+ If you require multiple bonding devices, but all with the same
+options, you may wish to use the "max_bonds" module parameter,
+documented above.
To create multiple bonding devices with differing options, it
is necessary to load the bonding driver multiple times. Note that
@@ -724,11 +878,16 @@ named "bond0" and creates the bond0 device in balance-rr mode with an
miimon of 100. The second instance is named "bond1" and creates the
bond1 device in balance-alb mode with an miimon of 50.
+ In some circumstances (typically with older distributions),
+the above does not work, and the second bonding instance never sees
+its options. In that case, the second options line can be substituted
+as follows:
+
+install bonding1 /sbin/modprobe bonding -obond1 mode=balance-alb miimon=50
+
This may be repeated any number of times, specifying a new and
-unique name in place of bond0 or bond1 for each instance.
+unique name in place of bond1 for each subsequent instance.
- When the appropriate module paramters are in place, then
-configure bonding according to the instructions for your distro.
5. Querying Bonding Configuration
This diff is incomplete. Download the complete patch.
drivers/net/hamradio/Kconfig
View fileThis diff is incomplete. Download the complete patch.
drivers/net/sk98lin/skgeinit.c
View fileThis diff is incomplete. Download the complete patch.
drivers/net/sk98lin/skxmac2.c
View fileThis diff is incomplete. Download the complete patch.
drivers/net/skge.c
View fileThis diff is incomplete. Download the complete patch.
drivers/net/skge.h
View fileThis diff is incomplete. Download the complete patch.
drivers/net/smc91x.h
View fileThis diff is incomplete. Download the complete patch.