bonding: document the new _arp options for arp_validate

CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 66 insertions, 30 deletions

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 96b4ad89cf25..a383c00392d0 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -270,16 +270,15 @@ arp_ip_target
 arp_validate
 
         Specifies whether or not ARP probes and replies should be
-        validated in any mode that supports arp monitoring.  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.
+        validated in any mode that supports arp monitoring, or whether
+        non-ARP traffic should be filtered (disregarded) for link
+        monitoring purposes.
 
         Possible values are:
 
         none or 0
 
-                No validation is performed.  This is the default.
+                No validation or filtering is performed.
 
         active or 1
 
@@ -293,31 +292,68 @@ arp_validate
 
                 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.
-
-        The validation of ARP requests on backup slaves is mainly
-        helping bonding to decide which slaves are more likely to
-        work in case of the active slave failure, it doesn't really
-        guarantee that the backup slave will work if it's selected
-        as the next active slave.
-
-        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.
+        filter or 4
+
+                Filtering is applied to all slaves. No validation is
+                performed.
+
+        filter_active or 5
+
+                Filtering is applied to all slaves, validation is performed
+                only for the active slave.
+
+        filter_backup or 6
+
+                Filtering is applied to all slaves, validation is performed
+                only for backup slaves.
+
+        Validation:
+
+        Enabling validation 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.
+
+        For an 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 broadcast 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.
+
+        The validation of ARP requests on backup slaves is mainly helping
+        bonding to decide which slaves are more likely to work in case of
+        the active slave failure, it doesn't really guarantee that the
+        backup slave will work if it's selected as the next active slave.
+
+        Validation 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
+        validation can resolve this, as the ARP monitor will only consider
+        ARP requests and replies associated with its own instance of
+        bonding.
+
+        Filtering:
+
+        Enabling filtering causes the ARP monitor to only use incoming ARP
+        packets for link availability purposes.  Arriving packets that are
+        not ARPs are delivered normally, but do not count when determining
+        if a slave is available.
+
+        Filtering operates by only considering the reception of ARP
+        packets (any ARP packet, regardless of source or destination) when
+        determining if a slave has received traffic for link availability
+        purposes.
+
+        Filtering is useful in network configurations in which significant
+        levels of third party broadcast traffic would fool the standard
+        ARP monitor into considering the links as still up.  Use of
+        filtering can resolve this, as only ARP traffic is considered for
+        link availability purposes.
 
         This option was added in bonding version 3.1.0.