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 <> 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

Reply via email to