Yep, we stumbled into that and it worked like a charm. We couldn't quite tell from the document if in-band is enabled or disabled by default when you install and bring up a bridge for the first time. Do you happen to know?
We have machines of our own at Clemson and Utah and in CloudLab and GENI. We're running different experiments with different controllers and the topologies are disjoint. I don't quite understand what would have caused all the OVS's to get into this state. In any event, thanks for you insight and help! I've learned a lot more about OVS today :-) Ryan Izard PhD Candidate, Research/Teaching Assistant ECE Department, Clemson University riz...@g.clemson.edu --------------------------------------------------- Big Switch Networks ryan.iz...@bigswitch.com On Wed, Apr 6, 2016 at 6:15 PM, Nicholas Bastin <nick.bas...@gmail.com> wrote: > On Wed, Apr 6, 2016 at 6:09 PM, Ryan Izard <riz...@g.clemson.edu> wrote: > >> One of these ARP flows is matching our ARP requests directed into br0 >> (LOCAL) and forwarding them as a learning switch (NORMAL). This looks like >> it's the issue. Now to figure out how this happened everywhere and how to >> disable it. >> > > ovs-vsctl set bridge br0 other-config:disable-in-band=true > > I still doubt this is what changed in your topology, so there's probably > something else that changed that put these rules into play when they were > not previously. > > -- > Nick >
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
