Thank you for taking a look! It's reassuring to hear that I figured out the rationales correctly.
On Mon, Jul 25, 2011 at 10:42:26AM +0100, Ian Campbell wrote: > FWIW with my "implemented the Linux Bridge version of much of this mess" > hat on this looks good to me. > > Acked-by: Ian Campbell <[email protected]> > > 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 > _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
