Assume two switches are connected to OVS SLB bond with two slave ports. In case the two non-OVS switch are not directly connected. The hosts behind one of the switches can not reach hosts behind OVS via multicast or broadcast, since only one of the bond slave port will be considered active slave. When rebalancing happens, the switched away traffic will update the FIB entry of the new switch, but not that of the old switch.
In case the two non-OVS switches are directly connected. Incoming multicast or broadcast won't be a problem any more. However, depends on traffic pattern, the new traffic may not actually pass through the old switch via the directly connected link. When this happens, The stale FIB entries in the old switch now points to the bond slave that just got rebalanced away. Causing incoming traffic flow through the old switch to be dropped by OVS. I am not sure this is actually a big problem in real life. SLB bond with single switch avoids both problems. It is possible there are better examples that I am not aware of. But those two examples are what I have in mind. On Wed, Sep 9, 2015 at 5:11 PM, Ben Pfaff <b...@nicira.com> wrote: > On Wed, Sep 09, 2015 at 04:28:07PM -0700, Andy Zhou wrote: >> On Wed, Sep 9, 2015 at 9:09 AM, Ben Pfaff <b...@nicira.com> wrote: >> > On Fri, Aug 21, 2015 at 07:14:33PM +0000, Jason Burns wrote: >> >> Can the balance-slb bond mode in Open vSwitch be used for a bond >> >> connected to two separate upstream switches? >> >> >> >> When I read the documentation [1] it states that only active-backup >> >> can be used to connect to two separate upstream switches, but no >> >> explanation is provided. >> > >> > I don't recall the exact reason, but I remember that this caused >> > problems, and that's why we documented it. >> > >> > I hope that someone else can speak up with the reason. >> >> Bond traffic rebalancing or link flapping may mass up the mac learning >> table of those separate upstream switches. > > If you have a specific example in mind, then I think we'd all find it > enlightening. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
