+
+Bond Balance Modes
+------------------
+
+Each bond balancing mode has different considerations, described
+below.
+
+LACP Bonding
+------------
+
+LACP bonding requires the remote switch to implement LACP, but it 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
+-----------
+
+SLB bonding allows a limited form of load balancing without the remote
+switch's knowledge or cooperation. The basics of SLB are simple. SLB
+assigns each source MAC+VLAN pair to a link and transmits all packets
+from that MAC+VLAN through that link. Learning in the remote switch
+causes it to send packets to that MAC+VLAN through the same link.
+
+SLB bonding has the following complications:
+
+ 0. When the remote switch has not learned the MAC for the
+ destination of a unicast packet and hence floods the packet to
+ all of the links on the SLB bond, Open vSwitch will forward
+ duplicate packets, one per link, to each other switch port.
+
+ Open vSwitch does not solve this problem.
+
+ 1. When the remote switch receives a multicast or broadcast packet
+ from a port not on the SLB bond, it will forward it to all of
+ the links in the SLB bond. This would cause packet duplication
+ if not handled specially.
+
+ Open vSwitch avoids packet duplication by accepting multicast
+ and broadcast packets on only the active slave, and dropping
+ multicast and broadcast packets on all other slaves.
+
+ 2. When Open vSwitch forwards a multicast or broadcast packet to a
+ link in the SLB bond other than the active slave, the remote
+ switch will forward it to all of the other links in the SLB
+ bond, including the active slave. Without special handling,
+ this would mean that Open vSwitch would forward a second copy of
+ the packet to each switch port (other than the bond), including
+ the port that originated the packet.
+
+ Open vSwitch deals with this case by dropping packets received
+ on any SLB bonded link that have a source MAC+VLAN that has been
+ learned on any other port. (This means that SLB as implemented
+ in Open vSwitch relies critically on MAC learning. Notably, SLB
+ is incompatible with the "flood_vlans" feature.)
+
+ 3. Suppose that a MAC+VLAN moves to an SLB bond from another port
+ (e.g. when a VM is migrated from this hypervisor to a different
+ one). Without additional special handling, Open vSwitch will
+ not notice until the MAC learning entry expires, up to 60
+ seconds later as a consequence of rule #2.
+
+ Open vSwitch avoids a 60-second delay by listening for
+ gratuitous ARPs, which VMs commonly emit upon migration. As an
+ exception to rule #2, a gratuitous ARP received on an SLB bond
+ is not dropped and updates the MAC learning table in the usual
+ way. (If a move does not trigger a gratuitous ARP, or if the
+ gratuitous ARP is lost in the network, then a 60-second delay
+ still occurs.)
+
+ 4. Suppose that a MAC+VLAN moves from an SLB bond to another port
+ (e.g. when a VM is migrated from a different hypervisor to this
+ one), that the MAC+VLAN emits a gratuitous ARP, and that Open
+ vSwitch forwards that gratuitous ARP to a link in the SLB bond
+ other than the active slave. The remote switch will forward the
+ gratuitous ARP to all of the other links in the SLB bond,
+ including the active slave. Without additional special
+ handling, this would mean that Open vSwitch would learn that the
+ MAC+VLAN was located on the SLB bond, as a consequence of rule
+ #3.
+
+ Open vSwitch avoids this problem by "locking" the MAC learning
+ table entry for a MAC+VLAN from which a gratuitous ARP was
+ received from a non-SLB bond port. For 5 seconds, a locked MAC
+ learning table entry will not be updated based on a gratuitous
+ ARP received on a SLB bond.