none of the special features of bonded ports described in this section
apply.
-There are many forms of bonding, but ovs-vswitchd currently implements
-only a single kind, called "source load balancing" or SLB bonding.
-SLB bonding divides traffic among the slaves based on the Ethernet
-source address. This is useful only if the traffic over the bond has
-multiple Ethernet source addresses, for example if network traffic
-from multiple VMs are multiplexed over the bond.
+There are many forms of bonding of which ovs-vswitchd implements only
+a few. The most complex bond ovs-vswitchd implements is called
+"source load balancing" or SLB bonding. SLB bonding divides traffic
+among the slaves based on the Ethernet source address. This is useful
+only if the traffic over the bond has multiple Ethernet source
+addresses, for example if network traffic from multiple VMs are
+multiplexed over the bond.
Enabling and Disabling Slaves
-----------------------------
When a slave becomes disabled, the vswitch immediately chooses a new
output port for traffic that was destined for that slave (see
-bond_enable_slave()). It also sends a "gratuitous learning packet" on
-the bond port (on the newly chosen slave) for each MAC address that
-the vswitch has learned on a port other than the bond (see
-bond_send_learning_packets()), to teach the physical switch that the
-new slave should be used in place of the one that is now disabled.
-(This behavior probably makes sense only for a vswitch that has only
-one port (the bond) connected to a physical switch; vswitchd should
-probably provide a way to disable or configure it in other scenarios.)
+bond_enable_slave()). It also sends a "gratuitous learning packet",
+specifically a RARP, on the bond port (on the newly chosen slave) for
+each MAC address that the vswitch has learned on a port other than the
+bond (see bond_send_learning_packets()), to teach the physical switch
+that the new slave should be used in place of the one that is now
+disabled. (This behavior probably makes sense only for a vswitch that
+has only one port (the bond) connected to a physical switch; vswitchd
+should probably provide a way to disable or configure it in other
+scenarios.)
Bond Packet Input
-----------------
-Bond packet input processing takes place in process_flow().
-
Bonding accepts unicast packets on any bond slave. This can
occasionally cause packet duplication for the first few packets sent
to a given MAC, if the physical switch attached to the bond is
otherwise very simple in that, after LACP negotiation is complete,
there is no need for special handling of received packets.
+Several of the physical switches that support LACP block all traffic
+for ports that are configured to use LACP, until LACP is negotiated with
+the host. When configuring a LACP bond on a OVS host (eg: XenServer),
+this means that there will be an interruption of the network connectivity
+between the time the ports on the physical switch and the bond on the OVS
+host are configured. The interruption may be relatively long, if different
+people are responsible for managing the switches and the OVS host.
+
+Such network connectivity failure can be avoided if LACP can be configured
+on the OVS host before configuring the physical switch, and having
+the OVS host fall back to a bond mode (active-backup) till the physical
+switch LACP configuration is complete. An option "lacp-fallback-ab" exists to
+provide such behavior on openvswitch.
+
+Active Backup Bonding
+---------------------
+
+Active Backup bonds send all traffic out one "active" slave until that
+slave becomes unavailable. Since they are significantly less
+complicated than SLB bonds, they are preferred when LACP is not an
+option. Additionally, they are the only bond mode which supports
+attaching each slave to a different upstream switch.
+
SLB Bonding
-----------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff