aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/networking
diff options
context:
space:
mode:
authorJay Vosburgh <fubar@us.ibm.com>2008-05-18 00:10:14 -0400
committerJeff Garzik <jgarzik@redhat.com>2008-05-22 06:34:29 -0400
commit3915c1e8634a321d9680e5cd80a53053b642dc0c (patch)
tree430b2168edbc7f6c4ba3698d261b8573b422658a /Documentation/networking
parentb2220cad583c9b63e085476df448fa2aff5ea906 (diff)
bonding: Add "follow" option to fail_over_mac
Add a "follow" selection for fail_over_mac. This option causes the MAC address to move from slave to slave as the active slave changes. This is in addition to the existing fail_over_mac option that causes the bond's MAC address to change during failover. This new option is useful for devices that cannot tolerate multiple ports using the same MAC address simultaneously, either because it confuses them or incurs a performance penalty (as is the case with some LPAR-aware multiport devices). Because the MAC of the bond itself does not change, the "follow" option is slightly more reliable during failover and doesn't change the MAC of the bond during operation. This patch requires a previous ARP monitor change to properly handle RTNL during failovers. Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Diffstat (limited to 'Documentation/networking')
-rw-r--r--Documentation/networking/bonding.txt96
1 files changed, 67 insertions, 29 deletions
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index a0cda062bc33..8e6b8d3c7410 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -289,35 +289,73 @@ downdelay
289fail_over_mac 289fail_over_mac
290 290
291 Specifies whether active-backup mode should set all slaves to 291 Specifies whether active-backup mode should set all slaves to
292 the same MAC address (the traditional behavior), or, when 292 the same MAC address at enslavement (the traditional
293 enabled, change the bond's MAC address when changing the 293 behavior), or, when enabled, perform special handling of the
294 active interface (i.e., fail over the MAC address itself). 294 bond's MAC address in accordance with the selected policy.
295 295
296 Fail over MAC is useful for devices that cannot ever alter 296 Possible values are:
297 their MAC address, or for devices that refuse incoming 297
298 broadcasts with their own source MAC (which interferes with 298 none or 0
299 the ARP monitor). 299
300 300 This setting disables fail_over_mac, and causes
301 The down side of fail over MAC is that every device on the 301 bonding to set all slaves of an active-backup bond to
302 network must be updated via gratuitous ARP, vs. just updating 302 the same MAC address at enslavement time. This is the
303 a switch or set of switches (which often takes place for any 303 default.
304 traffic, not just ARP traffic, if the switch snoops incoming 304
305 traffic to update its tables) for the traditional method. If 305 active or 1
306 the gratuitous ARP is lost, communication may be disrupted. 306
307 307 The "active" fail_over_mac policy indicates that the
308 When fail over MAC is used in conjuction with the mii monitor, 308 MAC address of the bond should always be the MAC
309 devices which assert link up prior to being able to actually 309 address of the currently active slave. The MAC
310 transmit and receive are particularly susecptible to loss of 310 address of the slaves is not changed; instead, the MAC
311 the gratuitous ARP, and an appropriate updelay setting may be 311 address of the bond changes during a failover.
312 required. 312
313 313 This policy is useful for devices that cannot ever
314 A value of 0 disables fail over MAC, and is the default. A 314 alter their MAC address, or for devices that refuse
315 value of 1 enables fail over MAC. This option is enabled 315 incoming broadcasts with their own source MAC (which
316 automatically if the first slave added cannot change its MAC 316 interferes with the ARP monitor).
317 address. This option may be modified via sysfs only when no 317
318 slaves are present in the bond. 318 The down side of this policy is that every device on
319 319 the network must be updated via gratuitous ARP,
320 This option was added in bonding version 3.2.0. 320 vs. just updating a switch or set of switches (which
321 often takes place for any traffic, not just ARP
322 traffic, if the switch snoops incoming traffic to
323 update its tables) for the traditional method. If the
324 gratuitous ARP is lost, communication may be
325 disrupted.
326
327 When this policy is used in conjuction with the mii
328 monitor, devices which assert link up prior to being
329 able to actually transmit and receive are particularly
330 susecptible to loss of the gratuitous ARP, and an
331 appropriate updelay setting may be required.
332
333 follow or 2
334
335 The "follow" fail_over_mac policy causes the MAC
336 address of the bond to be selected normally (normally
337 the MAC address of the first slave added to the bond).
338 However, the second and subsequent slaves are not set
339 to this MAC address while they are in a backup role; a
340 slave is programmed with the bond's MAC address at
341 failover time (and the formerly active slave receives
342 the newly active slave's MAC address).
343
344 This policy is useful for multiport devices that
345 either become confused or incur a performance penalty
346 when multiple ports are programmed with the same MAC
347 address.
348
349
350 The default policy is none, unless the first slave cannot
351 change its MAC address, in which case the active policy is
352 selected by default.
353
354 This option may be modified via sysfs only when no slaves are
355 present in the bond.
356
357 This option was added in bonding version 3.2.0. The "follow"
358 policy was added in bonding version 3.3.0.
321 359
322lacp_rate 360lacp_rate
323 361