packet would be duplicated, once for every bond slave, because the
physical switch attached to the bond will flood those packets.
-Bonding also drops some multicast packets received on the active
-slave: those for the vswitch has learned that the packet's MAC is on a
-port other than the bond port itself. This is because it is likely
-that the vswitch itself sent the multicast packet out the bond port,
-on a slave other than the active slave, and is now receiving the
-packet back on the active slave. However, the vswitch makes an
+Bonding also drops received packets when the vswitch has learned that
+the packet's MAC is on a port other than the bond port itself. This is
+because it is likely that the vswitch itself sent the packet out the
+bond port on a different slave and is now receiving the packet back.
+This occurs when the packet is multicast or the physical switch has not
+yet learned the MAC and is flooding it. However, the vswitch makes an
exception to this rule for broadcast ARP replies, which indicate that
the MAC has moved to another switch, probably due to VM migration.
(ARP replies are normally unicast, so this exception does not match
------------------
When a packet is sent out a bond port, the bond slave actually used is
-selected based on the packet's source MAC (see choose_output_iface()).
-In particular, the source MAC is hashed into one of 256 values, and
-that value is looked up in a hash table (the "bond hash") kept in the
-"bond_hash" member of struct port. The hash table entry identifies a
-bond slave. If no bond slave has yet been chosen for that hash table
-entry, vswitchd chooses one arbitrarily.
+selected based on the packet's source MAC and VLAN tag (see
+choose_output_iface()). In particular, the source MAC and VLAN tag
+are hashed into one of 256 values, and that value is looked up in a
+hash table (the "bond hash") kept in the "bond_hash" member of struct
+port. The hash table entry identifies a bond slave. If no bond slave
+has yet been chosen for that hash table entry, vswitchd chooses one
+arbitrarily.
Every 10 seconds, vswitchd rebalances the bond slaves (see
bond_rebalance_port()). To rebalance, vswitchd examines the
slaves in order from most-loaded to least-loaded. If highly loaded
slave H is significantly more heavily loaded than the least-loaded
slave L, and slave H carries at least two hashes, then vswitchd shifts
-one of H's hashes to L. However, vswitchd will not shift a hash from
-H to L if that will cause L's load to exceed H's load.
+one of H's hashes to L. However, vswitchd will only shift a hash from
+H to L if it will decrease the ratio of the load between H and L by at
+least 0.1.
Currently, "significantly more loaded" means that H must carry at
least 1 Mbps more traffic, and that traffic must be at least 3%
greater than L's.
+
+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.
+
+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.
git://git.onelab.eu / sliver-openvswitch.git / blobdiff