[ovs-dev] [PATCH] INTERNALS: Describe SLB bonding.

[Ian Campbell]

FWIW with my "implemented the Linux Bridge version of much of this mess"
hat on this looks good to me.

Acked-by: Ian Campbell <ian.campbell at citrix.com>

On Fri, 2011-07-22 at 13:57 -0700, Ben Pfaff wrote:
> ---
>  vswitchd/INTERNALS |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 files changed, 78 insertions(+), 0 deletions(-)
> 
> diff --git a/vswitchd/INTERNALS b/vswitchd/INTERNALS
> index 6c1bdc1..86db369 100644
> --- a/vswitchd/INTERNALS
> +++ b/vswitchd/INTERNALS
> @@ -129,3 +129,81 @@ 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:
> +
> +   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.

-- 
Ian Campbell

There are no answers, only cross-references.
		-- Weiner