On Thu, Oct 29, 2015 at 11:36:48AM -0700, Keith Holleman wrote: > I saw and followed the fairly recent discussion on the dev alias about > flooding and patch ports here: > > http://openvswitch.org/pipermail/dev/2015-September/060118.html > > But I have a slightly different question. In one setup, I have two patch > ports connecting the same two bridges. One bridge, is a "secure" bridge. > While not actually managed by a controller, it effectively is as all rules > are manually added in a very specific and controlled manner. The other is > a standard stock "learning" bridge with only a normal action. To borrow > and enhance the topology from the previous thread: > > port_A --- br1 --- port_B (patch) ........ port_C (patch) --- br2 --- port_D > > --- port_E (patch) ........ port_F (patch) --- > > > > The unexpected behavior that I'm seeing is that a broadcast packet > (say ARP) that arrives in br2 on patch port_C is not being flooded to > patch port_F. That packet is however proper flooded to port_D and > any other ports (real or internal) in br2. An ARP packet that arrives > on port_D is properly flooded to both port_C and port_F. The rules in > BR1 do allow such a packet to arrive on port_A, leave on port_E, and > if it returns on port_B to to have a different set of rules applied > and may be resent out of port_A (or other ports in br1) after > modifications. > > > Other things learned from experiments: > > > 1) a unicast frame that arrives on port_C destined for a MAC learned > in br2 on port_F is properly forwarded out of port_F. From this I > assume there is not a complete failure in sending from one patch port > to another between two bridges. > > 2) if I attach a new patch-port to br2 to another bridge (say br3), > the arp packet that arrives on patch port_C is flooded on the new > patch port to the new bridge. From this I assume that you can flood > across patch ports just fine. > > > But there seems to be something or some check that is preventing a > broadcast packet arriving on port_C to be flooded out of port_F? Is > there anything specific someone knows of that would prevent this or > any specific output or debug that could shed light on it?
This is really unusual. It's not related to disabled flooding on port_F, since some packets do get flooded to port_F. It's probably not related to MAC learning, since it's a broadcast packet (though you might want to check the MAC learning table just to be sure). Have you tried running "ovs-appctl ofproto/trace" on an appropriate packet to see the details of how OVS is processing this packet? _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
