diff options
| author | Veaceslav Falico <vfalico@redhat.com> | 2014-02-18 07:48:37 +0100 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2014-02-18 16:47:14 -0500 |
| commit | 13ac34a8866e31b31db6237c73aa558aff84d765 (patch) | |
| tree | 2967b6c7eb63b168b3b33c4c57bcbcd5f709e70c /Documentation/networking | |
| parent | 3b7d636b50fb38e4e0f1113ba7bff8dcd19d140f (diff) | |
| download | lwn-13ac34a8866e31b31db6237c73aa558aff84d765.tar.gz lwn-13ac34a8866e31b31db6237c73aa558aff84d765.zip | |
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.txt | 6 |
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: |