Re: [ovs-discuss] Static CAM table

[Ben Pfaff]

OVS can't really influence whether a VM sends a reply.

On Tue, Oct 18, 2016 at 12:02:16PM -0700, Tom Gajewski wrote:
> 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
>  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  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

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

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

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

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
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Ben Pfaff]

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

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

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.

Everything works fine if: 1) port 13 is no-flood 2) mac-table has a
current entry for mac to port 13 mapping 3) absence of this flow:
dl_dst=so:me:ma:cc actions=output:13

I could add this flow to make sure
arp,dl_dst=ff:ff:ff:ff:ff:ff,actions=output:all -- in fact just did,
made no difference, just saw a flood of arp requests come in which
defeats my goal anyway and still didn't help. But yea, I'm missing
something for the returnnot sure what it can be as yes the VM
inside port 13 already knows the MAC of the request so can't be arp...

On Tue, Oct 18, 2016 at 10:12 AM, Justin Pettit  wrote:
>
>> On Oct 18, 2016, at 2:38 AM, Tom Gajewski  
>> wrote:
>>
>> Ben, you had asked about my flow table. I've tried this with a
>> completely clear table and not -- same behavior. There has to be some
>> logic I'm missing here. Back story is that I'm trying to compensate
>> for the inability to populate local mac-table with this flow as I want
>> to run ports in 'no-flood' mode. I just tried with a clear flow table
>> and even flood enabled but once I set this:
>>
>> cookie=0x0, duration=260.750s, table=0, n_packets=81, n_bytes=8054,
>> idle_age=0, dl_dst=so:me:ma:cc actions=output:13
>>
>> The weird thing is I actually see this flow working in tcpdump.
>> Meaning, without the above a flow and without a mac-table entry for
>> so:me:ma:cc the vif/port is dead silent. Once I add the above flow
>> tcpdump looks correct -- heck, I even see the incoming ICMP packet
>> inside the VM but the ping never completes, it never makes its way
>> back all I see is one way ICMP echo requests. So am I being stupid
>> here do I need another flow to facilitate the return? (mac-table still
>> doesn't have an entry when I observe ICMP request within VM).
>
> It sounds like you have a flow table that allows traffic toward port 13, but, 
> if you've flushed all the other flows, are you allowing the return traffic?  
> Also, if you've flushed the flow table, you may need to handle broadcast mac 
> addresses for things like ARP requests.
>
> --Justin
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Justin Pettit]

> On Oct 18, 2016, at 2:38 AM, Tom Gajewski  wrote:
> 
> Ben, you had asked about my flow table. I've tried this with a
> completely clear table and not -- same behavior. There has to be some
> logic I'm missing here. Back story is that I'm trying to compensate
> for the inability to populate local mac-table with this flow as I want
> to run ports in 'no-flood' mode. I just tried with a clear flow table
> and even flood enabled but once I set this:
> 
> cookie=0x0, duration=260.750s, table=0, n_packets=81, n_bytes=8054,
> idle_age=0, dl_dst=so:me:ma:cc actions=output:13
> 
> The weird thing is I actually see this flow working in tcpdump.
> Meaning, without the above a flow and without a mac-table entry for
> so:me:ma:cc the vif/port is dead silent. Once I add the above flow
> tcpdump looks correct -- heck, I even see the incoming ICMP packet
> inside the VM but the ping never completes, it never makes its way
> back all I see is one way ICMP echo requests. So am I being stupid
> here do I need another flow to facilitate the return? (mac-table still
> doesn't have an entry when I observe ICMP request within VM).

It sounds like you have a flow table that allows traffic toward port 13, but, 
if you've flushed all the other flows, are you allowing the return traffic?  
Also, if you've flushed the flow table, you may need to handle broadcast mac 
addresses for things like ARP requests.

--Justin


___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

Ben, you had asked about my flow table. I've tried this with a
completely clear table and not -- same behavior. There has to be some
logic I'm missing here. Back story is that I'm trying to compensate
for the inability to populate local mac-table with this flow as I want
to run ports in 'no-flood' mode. I just tried with a clear flow table
and even flood enabled but once I set this:

 cookie=0x0, duration=260.750s, table=0, n_packets=81, n_bytes=8054,
idle_age=0, dl_dst=so:me:ma:cc actions=output:13

The weird thing is I actually see this flow working in tcpdump.
Meaning, without the above a flow and without a mac-table entry for
so:me:ma:cc the vif/port is dead silent. Once I add the above flow
tcpdump looks correct -- heck, I even see the incoming ICMP packet
inside the VM but the ping never completes, it never makes its way
back all I see is one way ICMP echo requests. So am I being stupid
here do I need another flow to facilitate the return? (mac-table still
doesn't have an entry when I observe ICMP request within VM).

On Mon, Oct 17, 2016 at 11:50 AM, Tom Gajewski
 wrote:
> There has to be something inherently wrong with that flow since once I
> enter it, the machine behind port 13 cannot get out anywhere -- and no
> traffic can reach it, even once there is an actual entry in the
> mac-table. So I'm effectively breaking all traffic to port 13 and MAC
> so:me:ma:cc. Can someone point me at a properly constructed flow to
> accomplish this?
>
> On Mon, Oct 17, 2016 at 11:01 AM, Ben Pfaff  wrote:
>> I would generally expect that to work.
>>
>> Maybe you should show us more of your flow table.
>>
>> On Mon, Oct 17, 2016 at 10:14:16AM -0700, Tom Gajewski wrote:
>>> My bad, that was obviously suppose to include the MAC in question. So
>>> one more time, in an attempt to set a static MAC table entry:
>>>
>>> Table entry:
>>>
>>> 13   744  so:me:ma:cc
>>>
>>> Flow:
>>>
>>> ovs-ofctl add-flow mybridge dl_dst=so:me:ma:cc,actions=output:13
>>>
>>> I guess what I'm asking is, what should a static flow that says "MAC
>>> so:me:ma:cc lives on port 13" look like? Again, goal is to have a
>>> static table entry like behavior accomplished with this flow.
>>>
>>> Cheers,
>>>
>>> --Tom
>>>
>>> On Mon, Oct 17, 2016 at 9:12 AM, Ben Pfaff  wrote:
>>> > On Mon, Oct 17, 2016 at 02:45:06AM -0700, Tom Gajewski wrote:
>>> >> Hi all,
>>> >>
>>> >> It is my understanding that one cannot modify the cam (well I guess in
>>> >> openvswitch land the mac table ;] ) directly. As I'm trying to set up
>>> >> static entries. Do I need to use flows to accomplish this, is there no
>>> >> other way to just modify this table??
>>> >>
>>> >> As for flows, I did try to add some copying an outdated entry from the
>>> >> mac table that read
>>> >>
>>> >> 13   744  so:me:ma:cc
>>> >>
>>> >> like this -->
>>> >>
>>> >> ovs-ofctl add-flow mybridge dl_dst=,actions=output:13
>>> >>
>>> >> but that just seemed to do nothing, in fact in breaks connectivity to
>>> >> that destination completely even if that MAC is in the table. So if I
>>> >> do have to use flows to do this could someone tell me where I'm being
>>> >> stupid?
>>> >
>>> > There's no direct way to modify the MAC-learning table.
>>> >
>>> > I don't know a reason why the flow that you've showed us would cause
>>> > such big problems.  The command does omit the MAC address, but that
>>> > would only cause an error from ovs-ofctl, so I guess that the actual
>>> > command included the MAC.
>>> >
>>> > Maybe you should show us more of your flow table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

There has to be something inherently wrong with that flow since once I
enter it, the machine behind port 13 cannot get out anywhere -- and no
traffic can reach it, even once there is an actual entry in the
mac-table. So I'm effectively breaking all traffic to port 13 and MAC
so:me:ma:cc. Can someone point me at a properly constructed flow to
accomplish this?

On Mon, Oct 17, 2016 at 11:01 AM, Ben Pfaff  wrote:
> I would generally expect that to work.
>
> Maybe you should show us more of your flow table.
>
> On Mon, Oct 17, 2016 at 10:14:16AM -0700, Tom Gajewski wrote:
>> My bad, that was obviously suppose to include the MAC in question. So
>> one more time, in an attempt to set a static MAC table entry:
>>
>> Table entry:
>>
>> 13   744  so:me:ma:cc
>>
>> Flow:
>>
>> ovs-ofctl add-flow mybridge dl_dst=so:me:ma:cc,actions=output:13
>>
>> I guess what I'm asking is, what should a static flow that says "MAC
>> so:me:ma:cc lives on port 13" look like? Again, goal is to have a
>> static table entry like behavior accomplished with this flow.
>>
>> Cheers,
>>
>> --Tom
>>
>> On Mon, Oct 17, 2016 at 9:12 AM, Ben Pfaff  wrote:
>> > On Mon, Oct 17, 2016 at 02:45:06AM -0700, Tom Gajewski wrote:
>> >> Hi all,
>> >>
>> >> It is my understanding that one cannot modify the cam (well I guess in
>> >> openvswitch land the mac table ;] ) directly. As I'm trying to set up
>> >> static entries. Do I need to use flows to accomplish this, is there no
>> >> other way to just modify this table??
>> >>
>> >> As for flows, I did try to add some copying an outdated entry from the
>> >> mac table that read
>> >>
>> >> 13   744  so:me:ma:cc
>> >>
>> >> like this -->
>> >>
>> >> ovs-ofctl add-flow mybridge dl_dst=,actions=output:13
>> >>
>> >> but that just seemed to do nothing, in fact in breaks connectivity to
>> >> that destination completely even if that MAC is in the table. So if I
>> >> do have to use flows to do this could someone tell me where I'm being
>> >> stupid?
>> >
>> > There's no direct way to modify the MAC-learning table.
>> >
>> > I don't know a reason why the flow that you've showed us would cause
>> > such big problems.  The command does omit the MAC address, but that
>> > would only cause an error from ovs-ofctl, so I guess that the actual
>> > command included the MAC.
>> >
>> > Maybe you should show us more of your flow table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Ben Pfaff]

I would generally expect that to work.

Maybe you should show us more of your flow table.

On Mon, Oct 17, 2016 at 10:14:16AM -0700, Tom Gajewski wrote:
> My bad, that was obviously suppose to include the MAC in question. So
> one more time, in an attempt to set a static MAC table entry:
> 
> Table entry:
> 
> 13   744  so:me:ma:cc
> 
> Flow:
> 
> ovs-ofctl add-flow mybridge dl_dst=so:me:ma:cc,actions=output:13
> 
> I guess what I'm asking is, what should a static flow that says "MAC
> so:me:ma:cc lives on port 13" look like? Again, goal is to have a
> static table entry like behavior accomplished with this flow.
> 
> Cheers,
> 
> --Tom
> 
> On Mon, Oct 17, 2016 at 9:12 AM, Ben Pfaff  wrote:
> > On Mon, Oct 17, 2016 at 02:45:06AM -0700, Tom Gajewski wrote:
> >> Hi all,
> >>
> >> It is my understanding that one cannot modify the cam (well I guess in
> >> openvswitch land the mac table ;] ) directly. As I'm trying to set up
> >> static entries. Do I need to use flows to accomplish this, is there no
> >> other way to just modify this table??
> >>
> >> As for flows, I did try to add some copying an outdated entry from the
> >> mac table that read
> >>
> >> 13   744  so:me:ma:cc
> >>
> >> like this -->
> >>
> >> ovs-ofctl add-flow mybridge dl_dst=,actions=output:13
> >>
> >> but that just seemed to do nothing, in fact in breaks connectivity to
> >> that destination completely even if that MAC is in the table. So if I
> >> do have to use flows to do this could someone tell me where I'm being
> >> stupid?
> >
> > There's no direct way to modify the MAC-learning table.
> >
> > I don't know a reason why the flow that you've showed us would cause
> > such big problems.  The command does omit the MAC address, but that
> > would only cause an error from ovs-ofctl, so I guess that the actual
> > command included the MAC.
> >
> > Maybe you should show us more of your flow table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Tom Gajewski]

My bad, that was obviously suppose to include the MAC in question. So
one more time, in an attempt to set a static MAC table entry:

Table entry:

13   744  so:me:ma:cc

Flow:

ovs-ofctl add-flow mybridge dl_dst=so:me:ma:cc,actions=output:13

I guess what I'm asking is, what should a static flow that says "MAC
so:me:ma:cc lives on port 13" look like? Again, goal is to have a
static table entry like behavior accomplished with this flow.

Cheers,

--Tom

On Mon, Oct 17, 2016 at 9:12 AM, Ben Pfaff  wrote:
> On Mon, Oct 17, 2016 at 02:45:06AM -0700, Tom Gajewski wrote:
>> Hi all,
>>
>> It is my understanding that one cannot modify the cam (well I guess in
>> openvswitch land the mac table ;] ) directly. As I'm trying to set up
>> static entries. Do I need to use flows to accomplish this, is there no
>> other way to just modify this table??
>>
>> As for flows, I did try to add some copying an outdated entry from the
>> mac table that read
>>
>> 13   744  so:me:ma:cc
>>
>> like this -->
>>
>> ovs-ofctl add-flow mybridge dl_dst=,actions=output:13
>>
>> but that just seemed to do nothing, in fact in breaks connectivity to
>> that destination completely even if that MAC is in the table. So if I
>> do have to use flows to do this could someone tell me where I'm being
>> stupid?
>
> There's no direct way to modify the MAC-learning table.
>
> I don't know a reason why the flow that you've showed us would cause
> such big problems.  The command does omit the MAC address, but that
> would only cause an error from ovs-ofctl, so I guess that the actual
> command included the MAC.
>
> Maybe you should show us more of your flow table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Static CAM table

[Ben Pfaff]

On Mon, Oct 17, 2016 at 02:45:06AM -0700, Tom Gajewski wrote:
> Hi all,
> 
> It is my understanding that one cannot modify the cam (well I guess in
> openvswitch land the mac table ;] ) directly. As I'm trying to set up
> static entries. Do I need to use flows to accomplish this, is there no
> other way to just modify this table??
> 
> As for flows, I did try to add some copying an outdated entry from the
> mac table that read
> 
> 13   744  so:me:ma:cc
> 
> like this -->
> 
> ovs-ofctl add-flow mybridge dl_dst=,actions=output:13
> 
> but that just seemed to do nothing, in fact in breaks connectivity to
> that destination completely even if that MAC is in the table. So if I
> do have to use flows to do this could someone tell me where I'm being
> stupid?

There's no direct way to modify the MAC-learning table.

I don't know a reason why the flow that you've showed us would cause
such big problems.  The command does omit the MAC address, but that
would only cause an error from ovs-ofctl, so I guess that the actual
command included the MAC.

Maybe you should show us more of your flow table.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Static CAM table

[Tom Gajewski]

Hi all,

It is my understanding that one cannot modify the cam (well I guess in
openvswitch land the mac table ;] ) directly. As I'm trying to set up
static entries. Do I need to use flows to accomplish this, is there no
other way to just modify this table??

As for flows, I did try to add some copying an outdated entry from the
mac table that read

13   744  so:me:ma:cc

like this -->

ovs-ofctl add-flow mybridge dl_dst=,actions=output:13

but that just seemed to do nothing, in fact in breaks connectivity to
that destination completely even if that MAC is in the table. So if I
do have to use flows to do this could someone tell me where I'm being
stupid?

Cheers all,

--Tom
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss