Merge branch 'linux-2.6'

[linux-2.6] / Documentation / networking / bonding.txt

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index de809e58092fa070caa7fac46c6cc9bbac12aed4..6cc30e0d5795ce8e598190fb32edf1624a58a203 100644 (file)
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -281,6 +281,39 @@ downdelay
        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
@@ -521,6 +554,30 @@ xmit_hash_policy
 
                This algorithm is 802.3ad compliant.
 
+       layer2+3
+
+               This policy uses a combination of layer2 and layer3
+               protocol information to generate the hash.
+
+               Uses XOR of hardware MAC addresses and IP addresses to
+               generate the hash.  The formula is
+
+               (((source IP XOR dest IP) AND 0xffff) XOR
+                       ( source MAC XOR destination MAC ))
+                               modulo slave count
+
+               This algorithm will place all traffic to a particular
+               network peer on the same slave.  For non-IP traffic,
+               the formula is the same as for the layer2 transmit
+               hash policy.
+
+               This policy is intended to provide a more balanced
+               distribution of traffic than layer2 alone, especially
+               in environments where a layer3 gateway device is
+               required to reach most destinations.
+
+               This algorithm is 802.3ad complient.
+
        layer3+4
 
                This policy uses upper layer protocol information,
@@ -556,8 +613,9 @@ xmit_hash_policy
                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.
+       version 2.6.3.  In earlier versions of bonding, this parameter
+       does not exist, and the layer2 policy is the only policy.  The
+       layer2+3 value was added for bonding version 3.2.2.
 
 
 3. Configuring Bonding Devices
@@ -920,40 +978,9 @@ 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
-current versions of the sysconfig network initialization scripts
-handle this automatically; if your distro uses these scripts, no
-special action is needed.  See the section Configuring Bonding
-Devices, above, if you're not sure about your network initialization
-scripts.
-
-       To load multiple instances of the module, it is necessary to
-specify a different name for each instance (the module loading system
-requires that every loaded module, even multiple instances of the same
-module, have a unique name).  This is accomplished by supplying
-multiple sets of bonding options in /etc/modprobe.conf, for example:
-       
-alias bond0 bonding
-options bond0 -o bond0 mode=balance-rr miimon=100
-
-alias bond1 bonding
-options bond1 -o bond1 mode=balance-alb miimon=50
-
-       will load the bonding module two times.  The first instance is
-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 bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
-       mode=balance-alb miimon=50
+is necessary to use bonding parameters exported by sysfs, documented
+in the section below.
 
-       This may be repeated any number of times, specifying a new and
-unique name in place of bond1 for each subsequent instance.
 
 3.4 Configuring Bonding Manually via Sysfs
 ------------------------------------------