[PATCH] bonding: Validate probe replies in ARP monitor

	Add logic to check ARP request / reply packets used for ARP
monitor link integrity checking.

	The current method simply examines the slave device to see if it
has sent and received traffic; this can be fooled by extraneous traffic.
For example, if multiple hosts running bonding are behind a common
switch, the probe traffic from the multiple instances of bonding will
update the tx/rx times on each other's slave devices.

Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>

1 files changed, 59 insertions, 0 deletions

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index afac780445cd..dc942eaf490f 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -192,6 +192,17 @@ or, for backwards compatibility, the option value.  E.g.,
 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
@@ -213,6 +224,54 @@ arp_ip_target
         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