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? Thanks for any help.
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
