summaryrefslogtreecommitdiff
path: root/Documentation/networking
diff options
context:
space:
mode:
authorVeaceslav Falico <vfalico@redhat.com>2014-02-18 07:48:37 +0100
committerDavid S. Miller <davem@davemloft.net>2014-02-18 16:47:14 -0500
commit13ac34a8866e31b31db6237c73aa558aff84d765 (patch)
tree2967b6c7eb63b168b3b33c4c57bcbcd5f709e70c /Documentation/networking
parent3b7d636b50fb38e4e0f1113ba7bff8dcd19d140f (diff)
bonding: permit using arp_validate with non-ab modes
Currently it's disabled because it's sometimes hard, in typical configs, to make it work - because of the nature how the loadbalance modes work - as it's hard to deliver valid arp replies to correct slaves by the switch. However we still can use arp_validation in loadbalance with several other configs, per example with arp_validate == 2 for backup with one broadcast domain, without the switch(es) doing any balancing - this way we'd be (a bit more) sure that the slave is up. So, enable it to let users decide which one works/suits them best. Also correct the mode limitation from BOND_OPT_ARP_VALIDATE. CC: Nikolay Aleksandrov <nikolay@redhat.com> CC: Jay Vosburgh <fubar@us.ibm.com> CC: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Veaceslav Falico <vfalico@redhat.com> Acked-by: Nikolay Aleksandrov <nikolay@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'Documentation/networking')
-rw-r--r--Documentation/networking/bonding.txt6
1 files changed, 3 insertions, 3 deletions
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 5cdb22971d19..96b4ad89cf25 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -270,9 +270,9 @@ arp_ip_target
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
+ 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.
Possible values are: