Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 52f65ef3 authored by Veaceslav Falico's avatar Veaceslav Falico Committed by David S. Miller
Browse files

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: default avatarVeaceslav Falico <vfalico@redhat.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 896149ff

Documentation/networking/bonding.txt

+66 −30
Original line number Diff line number Diff line
@@ -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.