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 Original line Diff line number Diff line
@@ -270,16 +270,15 @@ arp_ip_target 
arp_validate

arp_validate





	Specifies whether or not ARP probes and replies should be

	Specifies whether or not ARP probes and replies should be

	validated in any mode that supports arp monitoring.  This causes

	validated in any mode that supports arp monitoring, or whether

	the ARP monitor to examine the incoming ARP requests and replies,

	non-ARP traffic should be filtered (disregarded) for link

	and only consider a slave to be up if it is receiving the

	monitoring purposes.

	appropriate ARP traffic.





	Possible values are:

	Possible values are:





	none or 0

	none or 0





		No validation is performed.  This is the default.

		No validation or filtering is performed.





	active or 1

	active or 1
@@ -293,31 +292,68 @@ arp_validate 




		Validation is performed for all slaves.

		Validation is performed for all slaves.





	For the active slave, the validation checks ARP replies to

	filter or 4

	confirm that they were generated by an arp_ip_target.  Since



	backup slaves do not typically receive these replies, the

		Filtering is applied to all slaves. No validation is

	validation performed for backup slaves is on the ARP request

		performed.

	sent out via the active slave.  It is possible that some



	switch or network configurations may result in situations

	filter_active or 5

	wherein the backup slaves do not receive the ARP requests; in



	such a situation, validation of backup slaves must be

		Filtering is applied to all slaves, validation is performed

	disabled.

		only for the active slave.





	The validation of ARP requests on backup slaves is mainly

	filter_backup or 6

	helping bonding to decide which slaves are more likely to



	work in case of the active slave failure, it doesn't really

		Filtering is applied to all slaves, validation is performed

	guarantee that the backup slave will work if it's selected

		only for backup slaves.

	as the next active slave.





	Validation:

	This option is useful in network configurations in which



	multiple bonding hosts are concurrently issuing ARPs to one or

	Enabling validation causes the ARP monitor to examine the incoming

	more targets beyond a common switch.  Should the link between

	ARP requests and replies, and only consider a slave to be up if it

	the switch and target fail (but not the switch itself), the

	is receiving the appropriate ARP traffic.

	probe traffic generated by the multiple bonding instances will



	fool the standard ARP monitor into considering the links as

	For an active slave, the validation checks ARP replies to confirm

	still up.  Use of the arp_validate option can resolve this, as

	that they were generated by an arp_ip_target.  Since backup slaves

	the ARP monitor will only consider ARP requests and replies

	do not typically receive these replies, the validation performed

	associated with its own instance of bonding.

	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.

	This option was added in bonding version 3.1.0.