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>

diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 96b4ad89cf25269ee4d8a68b9f163d7fcf25969d..a383c00392d03f2e316f7fe7dd954c7d8b71f274 100644 (file)
--- 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.