aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking/bonding.txt
diff options
context:
space:
mode:
authorJay Vosburgh <fubar@us.ibm.com>2006-09-23 00:54:53 -0400
committerJeff Garzik <jeff@garzik.org>2006-09-25 20:08:09 -0400
commitf5b2b966f032f22d3a289045a5afd4afa09f09c6 (patch)
treecb3c505d8f444438bed09353788f6c96150f68ad /Documentation/networking/bonding.txt
parent70298705bb29fb7982b85089adf17cd37b94baa7 (diff)
[PATCH] bonding: Validate probe replies in ARP monitor
Add logic to check ARP request / reply packets used for ARP monitor link integrity checking. The current method simply examines the slave device to see if it has sent and received traffic; this can be fooled by extraneous traffic. For example, if multiple hosts running bonding are behind a common switch, the probe traffic from the multiple instances of bonding will update the tx/rx times on each other's slave devices. Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jeff@garzik.org>
Diffstat (limited to 'Documentation/networking/bonding.txt')
-rw-r--r--Documentation/networking/bonding.txt59
1 files changed, 59 insertions, 0 deletions
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index afac780445c..dc942eaf490 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -192,6 +192,17 @@ or, for backwards compatibility, the option value. E.g.,
192arp_interval 192arp_interval
193 193
194 Specifies the ARP link monitoring frequency in milliseconds. 194 Specifies the ARP link monitoring frequency in milliseconds.
195
196 The ARP monitor works by periodically checking the slave
197 devices to determine whether they have sent or received
198 traffic recently (the precise criteria depends upon the
199 bonding mode, and the state of the slave). Regular traffic is
200 generated via ARP probes issued for the addresses specified by
201 the arp_ip_target option.
202
203 This behavior can be modified by the arp_validate option,
204 below.
205
195 If ARP monitoring is used in an etherchannel compatible mode 206 If ARP monitoring is used in an etherchannel compatible mode
196 (modes 0 and 2), the switch should be configured in a mode 207 (modes 0 and 2), the switch should be configured in a mode
197 that evenly distributes packets across all links. If the 208 that evenly distributes packets across all links. If the
@@ -213,6 +224,54 @@ arp_ip_target
213 maximum number of targets that can be specified is 16. The 224 maximum number of targets that can be specified is 16. The
214 default value is no IP addresses. 225 default value is no IP addresses.
215 226
227arp_validate
228
229 Specifies whether or not ARP probes and replies should be
230 validated in the active-backup mode. This causes the ARP
231 monitor to examine the incoming ARP requests and replies, and
232 only consider a slave to be up if it is receiving the
233 appropriate ARP traffic.
234
235 Possible values are:
236
237 none or 0
238
239 No validation is performed. This is the default.
240
241 active or 1
242
243 Validation is performed only for the active slave.
244
245 backup or 2
246
247 Validation is performed only for backup slaves.
248
249 all or 3
250
251 Validation is performed for all slaves.
252
253 For the active slave, the validation checks ARP replies to
254 confirm that they were generated by an arp_ip_target. Since
255 backup slaves do not typically receive these replies, the
256 validation performed for backup slaves is on the ARP request
257 sent out via the active slave. It is possible that some
258 switch or network configurations may result in situations
259 wherein the backup slaves do not receive the ARP requests; in
260 such a situation, validation of backup slaves must be
261 disabled.
262
263 This option is useful in network configurations in which
264 multiple bonding hosts are concurrently issuing ARPs to one or
265 more targets beyond a common switch. Should the link between
266 the switch and target fail (but not the switch itself), the
267 probe traffic generated by the multiple bonding instances will
268 fool the standard ARP monitor into considering the links as
269 still up. Use of the arp_validate option can resolve this, as
270 the ARP monitor will only consider ARP requests and replies
271 associated with its own instance of bonding.
272
273 This option was added in bonding version 3.1.0.
274
216downdelay 275downdelay
217 276
218 Specifies the time, in milliseconds, to wait before disabling 277 Specifies the time, in milliseconds, to wait before disabling