More strangeness: when pinging from within VM behind port 13 I observe even the reply coming back into VM yet ping reports no reply 100% loss. This is with dl_dst:so:me:ma:cc flow. Why would that flow cause that, how is that even possible if I'm seeing ICMP replies inside VM? Again, all works fine without that static flow mapping, it just becomes impossible to reach VM after mac-table ages out -- because of the no-flood on the port, but as long as mac-table is populated all is good...
On Tue, Oct 18, 2016 at 11:41 AM, Tom Gajewski <tom.gajew...@paperspace.com> wrote: > That's the requirement, that's why I started this topic. I've > demonstrated that port 13 works perfectly fine with no-flood as long > as the mac-table of openvswitch is populated with its MAC, I still > don't understand why we can't adding a static entry here, seems silly. > But I've pretty much accomplished that with the dl_dst flow however > not all the way.... The goal is static mac-table and static arp. I > have it working to the point where I see ICMP echo request make it to > the VM behind port 13 just not back. > > On Tue, Oct 18, 2016 at 11:29 AM, Ben Pfaff <b...@ovn.org> wrote: >> On Tue, Oct 18, 2016 at 10:51:33AM -0700, Tom Gajewski wrote: >>> Yes of course I've opened up the switch again after flushing ;] >>> Basically I have: >>> >>> cookie=0x0, duration=61132.153s, table=0, n_packets=112313104, >>> n_bytes=18199375313, idle_age=0, priority=0 actions=NORMAL >>> cookie=0x0, duration=61107.945s, table=0, n_packets=7122, >>> n_bytes=467057, idle_age=1576, dl_dst=so:me:ma:cc actions=output:13 >>> >>> That's all, port 13 is set to no-flood of course. The above breaks >>> return traffic out of port 13 -- even if there is an entry for >>> so:me:ma:cc in the mac-table -- but the flow is working since I see >>> ICMP requests coming in to the VM behind port 13 so this isn't an arp >>> issue -- VM inside port 13 even knows the MAC of the ICMP requester, I >>> checked. >> >> Why is port 13 no-flood? Then broadcast and multicast packets won't go >> to it. _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
