Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Amar Padmanabhan]

Awesome thanks Ben!
- Amar

On 3/14/18, 4:49 PM, "Ben Pfaff"  wrote:

I finally fixed this upstream in Git, and the fix will be in the next
releases on the 2.8 and 2.9 branches.

On Thu, Dec 07, 2017 at 06:06:22AM +, Amar Padmanabhan wrote:
> Yup thanks we are unblocked!
> - Amar
> 
> On 12/6/17, 12:36 PM, "Ben Pfaff"  wrote:
> 
> OK.
> 
> In the meantime, you can add "eth()" to the flows you're tracing to 
get
> the expected results.
> 
> On Wed, Dec 06, 2017 at 07:02:42PM +, Amar Padmanabhan wrote:
> > Thanks Ben for taking a look,
> > Regards,
> > - Amar
> > 
> > On 12/6/17, 10:17 AM, "Ben Pfaff"  wrote:
> > 
> > On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan 
wrote:
> > > We are debugging a setup and are seeing something that we are 
finding it hard to explain.
> > > 
> > > 1 - Here is the ovs-dpctl dump-flows output.
> > > 
recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
 packets:550, bytes:53900, used:0.364s, 
actions:userspace(pid=3276048382,slow_path(controller))
> > 
> > OK, the above datapath flow just says that packets in this flow 
have to
> > be handled in the userspace slow path because 
> > 
> > > 2 - We are now trying to trace this flow and are not seeing 
the output to controller flow getting hit in the trace.
> > > sudo ovs-appctl ofproto/trace 
"in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > > Flow: 
packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > > bridge("gtp_br0")
> > > -
> > > 0. priority 0 resubmit(,1)
> > > 1. in_port=32770, priority 10 set_field:0->metadata 
resubmit(,2)
> > > 2. priority 0 resubmit(,3)
> > > 3. No match. drop Final flow: unchanged Megaflow: 
recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
drop ---> Why isn’t the output to controller flow getting hit?
> > > 
> > > 
> > > 3 - We are also seeing the flow counts go up for the output 
to controller flow per the ofctl dump-flows output (pasting relevant flows)
> > > 
> > > NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, 
table=0, n_packets=1408, n_bytes=148464, idle_age=1, priority=0 
actions=resubmit(,1)
> > > cookie=0x0, duration=1482.244s, table=1, n_packets=1283, 
n_bytes=123662, idle_age=1, priority=10,in_port=32770 
actions=set_field:0->metadata,resubmit(,2)
> > > cookie=0x0, duration=1482.244s, table=2, n_packets=1247, 
n_bytes=122150, idle_age=1, priority=0 actions=resubmit(,3)
> > > cookie=0x0, duration=1482.245s, table=3, n_packets=1245, 
n_bytes=122010, idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
actions=CONTROLLER:65535 ---> Notice that this is getting hit as well
> > 
> > OK, I spent a few minutes to mock up your environment (thanks 
for all
> > the details!) and experiment.  It looks like the problem is 
actually a
> > mismatch between the formatting and parsing code for datapath 
flows.  If
> > I run:
> > 
> > ovs-appctl ofproto/trace 
"in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > 
> > that is, add "eth()" to the datapath flow, then I get the 
expected
> > results:
> > 
> > $ ovs-appctl ofproto/trace 
"in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > Flow: 
ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > 
> > bridge("br0")
> > -
> >  0. priority 0
> > resubmit(,1)
> >  1. in_port=32770, priority 10
> > load:0->OXM_OF_METADATA[]
> > resubmit(,2)
> >  2. priority 0
> > resubmit(,3)
> >  3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
> > CONTROLLER:65535
> > 
> > Final flow: unchanged
> > Megaflow: 
recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
> > Datapath actions: drop
> > This flow is handled by the userspace slow path because it:
> > - Sends "packet-in" messages to the OpenFlow 
controller.
> >

Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Ben Pfaff]

I finally fixed this upstream in Git, and the fix will be in the next
releases on the 2.8 and 2.9 branches.

On Thu, Dec 07, 2017 at 06:06:22AM +, Amar Padmanabhan wrote:
> Yup thanks we are unblocked!
> - Amar
> 
> On 12/6/17, 12:36 PM, "Ben Pfaff"  wrote:
> 
> OK.
> 
> In the meantime, you can add "eth()" to the flows you're tracing to get
> the expected results.
> 
> On Wed, Dec 06, 2017 at 07:02:42PM +, Amar Padmanabhan wrote:
> > Thanks Ben for taking a look,
> > Regards,
> > - Amar
> > 
> > On 12/6/17, 10:17 AM, "Ben Pfaff"  wrote:
> > 
> > On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan wrote:
> > > We are debugging a setup and are seeing something that we are 
> finding it hard to explain.
> > > 
> > > 1 - Here is the ovs-dpctl dump-flows output.
> > > 
> recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
>  packets:550, bytes:53900, used:0.364s, 
> actions:userspace(pid=3276048382,slow_path(controller))
> > 
> > OK, the above datapath flow just says that packets in this flow 
> have to
> > be handled in the userspace slow path because 
> > 
> > > 2 - We are now trying to trace this flow and are not seeing the 
> output to controller flow getting hit in the trace.
> > > sudo ovs-appctl ofproto/trace 
> "in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > > Flow: 
> packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > > bridge("gtp_br0")
> > > -
> > > 0. priority 0 resubmit(,1)
> > > 1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
> > > 2. priority 0 resubmit(,3)
> > > 3. No match. drop Final flow: unchanged Megaflow: 
> recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
> drop ---> Why isn’t the output to controller flow getting hit?
> > > 
> > > 
> > > 3 - We are also seeing the flow counts go up for the output to 
> controller flow per the ofctl dump-flows output (pasting relevant flows)
> > > 
> > > NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, 
> table=0, n_packets=1408, n_bytes=148464, idle_age=1, priority=0 
> actions=resubmit(,1)
> > > cookie=0x0, duration=1482.244s, table=1, n_packets=1283, 
> n_bytes=123662, idle_age=1, priority=10,in_port=32770 
> actions=set_field:0->metadata,resubmit(,2)
> > > cookie=0x0, duration=1482.244s, table=2, n_packets=1247, 
> n_bytes=122150, idle_age=1, priority=0 actions=resubmit(,3)
> > > cookie=0x0, duration=1482.245s, table=3, n_packets=1245, 
> n_bytes=122010, idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
> actions=CONTROLLER:65535 ---> Notice that this is getting hit as well
> > 
> > OK, I spent a few minutes to mock up your environment (thanks for 
> all
> > the details!) and experiment.  It looks like the problem is 
> actually a
> > mismatch between the formatting and parsing code for datapath 
> flows.  If
> > I run:
> > 
> > ovs-appctl ofproto/trace 
> "in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > 
> > that is, add "eth()" to the datapath flow, then I get the expected
> > results:
> > 
> > $ ovs-appctl ofproto/trace 
> "in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > Flow: 
> ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > 
> > bridge("br0")
> > -
> >  0. priority 0
> > resubmit(,1)
> >  1. in_port=32770, priority 10
> > load:0->OXM_OF_METADATA[]
> > resubmit(,2)
> >  2. priority 0
> > resubmit(,3)
> >  3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
> > CONTROLLER:65535
> > 
> > Final flow: unchanged
> > Megaflow: 
> recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
> > Datapath actions: drop
> > This flow is handled by the userspace slow path because it:
> > - Sends "packet-in" messages to the OpenFlow controller.
> > 
> > Clearly that's a bug.  I'll see what I can do about it.
> > 
> > > Also, Whoever improved the output of ofproto/trace thanks a ton!
> > 
> > That was me :-)  You're welcome.
> > 
> > 
> 
> 
___
discuss mailing list
disc...@openvswitch.org

Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Amar Padmanabhan]

Yup thanks we are unblocked!
- Amar

On 12/6/17, 12:36 PM, "Ben Pfaff"  wrote:

OK.

In the meantime, you can add "eth()" to the flows you're tracing to get
the expected results.

On Wed, Dec 06, 2017 at 07:02:42PM +, Amar Padmanabhan wrote:
> Thanks Ben for taking a look,
> Regards,
> - Amar
> 
> On 12/6/17, 10:17 AM, "Ben Pfaff"  wrote:
> 
> On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan wrote:
> > We are debugging a setup and are seeing something that we are 
finding it hard to explain.
> > 
> > 1 - Here is the ovs-dpctl dump-flows output.
> > 
recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
 packets:550, bytes:53900, used:0.364s, 
actions:userspace(pid=3276048382,slow_path(controller))
> 
> OK, the above datapath flow just says that packets in this flow have 
to
> be handled in the userspace slow path because 
> 
> > 2 - We are now trying to trace this flow and are not seeing the 
output to controller flow getting hit in the trace.
> > sudo ovs-appctl ofproto/trace 
"in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > Flow: 
packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > bridge("gtp_br0")
> > -
> > 0. priority 0 resubmit(,1)
> > 1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
> > 2. priority 0 resubmit(,3)
> > 3. No match. drop Final flow: unchanged Megaflow: 
recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
drop ---> Why isn’t the output to controller flow getting hit?
> > 
> > 
> > 3 - We are also seeing the flow counts go up for the output to 
controller flow per the ofctl dump-flows output (pasting relevant flows)
> > 
> > NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, table=0, 
n_packets=1408, n_bytes=148464, idle_age=1, priority=0 actions=resubmit(,1)
> > cookie=0x0, duration=1482.244s, table=1, n_packets=1283, 
n_bytes=123662, idle_age=1, priority=10,in_port=32770 
actions=set_field:0->metadata,resubmit(,2)
> > cookie=0x0, duration=1482.244s, table=2, n_packets=1247, 
n_bytes=122150, idle_age=1, priority=0 actions=resubmit(,3)
> > cookie=0x0, duration=1482.245s, table=3, n_packets=1245, 
n_bytes=122010, idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
actions=CONTROLLER:65535 ---> Notice that this is getting hit as well
> 
> OK, I spent a few minutes to mock up your environment (thanks for all
> the details!) and experiment.  It looks like the problem is actually a
> mismatch between the formatting and parsing code for datapath flows.  
If
> I run:
> 
> ovs-appctl ofproto/trace 
"in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> 
> that is, add "eth()" to the datapath flow, then I get the expected
> results:
> 
> $ ovs-appctl ofproto/trace 
"in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> Flow: 
ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> 
> bridge("br0")
> -
>  0. priority 0
> resubmit(,1)
>  1. in_port=32770, priority 10
> load:0->OXM_OF_METADATA[]
> resubmit(,2)
>  2. priority 0
> resubmit(,3)
>  3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
> CONTROLLER:65535
> 
> Final flow: unchanged
> Megaflow: 
recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
> Datapath actions: drop
> This flow is handled by the userspace slow path because it:
> - Sends "packet-in" messages to the OpenFlow controller.
> 
> Clearly that's a bug.  I'll see what I can do about it.
> 
> > Also, Whoever improved the output of ofproto/trace thanks a ton!
> 
> That was me :-)  You're welcome.
> 
> 


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Ben Pfaff]

OK.

In the meantime, you can add "eth()" to the flows you're tracing to get
the expected results.

On Wed, Dec 06, 2017 at 07:02:42PM +, Amar Padmanabhan wrote:
> Thanks Ben for taking a look,
> Regards,
> - Amar
> 
> On 12/6/17, 10:17 AM, "Ben Pfaff"  wrote:
> 
> On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan wrote:
> > We are debugging a setup and are seeing something that we are finding 
> it hard to explain.
> > 
> > 1 - Here is the ovs-dpctl dump-flows output.
> > 
> recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
>  packets:550, bytes:53900, used:0.364s, 
> actions:userspace(pid=3276048382,slow_path(controller))
> 
> OK, the above datapath flow just says that packets in this flow have to
> be handled in the userspace slow path because 
> 
> > 2 - We are now trying to trace this flow and are not seeing the output 
> to controller flow getting hit in the trace.
> > sudo ovs-appctl ofproto/trace 
> "in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> > Flow: 
> packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> > bridge("gtp_br0")
> > -
> > 0. priority 0 resubmit(,1)
> > 1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
> > 2. priority 0 resubmit(,3)
> > 3. No match. drop Final flow: unchanged Megaflow: 
> recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
> drop ---> Why isn’t the output to controller flow getting hit?
> > 
> > 
> > 3 - We are also seeing the flow counts go up for the output to 
> controller flow per the ofctl dump-flows output (pasting relevant flows)
> > 
> > NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, table=0, 
> n_packets=1408, n_bytes=148464, idle_age=1, priority=0 actions=resubmit(,1)
> > cookie=0x0, duration=1482.244s, table=1, n_packets=1283, 
> n_bytes=123662, idle_age=1, priority=10,in_port=32770 
> actions=set_field:0->metadata,resubmit(,2)
> > cookie=0x0, duration=1482.244s, table=2, n_packets=1247, 
> n_bytes=122150, idle_age=1, priority=0 actions=resubmit(,3)
> > cookie=0x0, duration=1482.245s, table=3, n_packets=1245, 
> n_bytes=122010, idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
> actions=CONTROLLER:65535 ---> Notice that this is getting hit as well
> 
> OK, I spent a few minutes to mock up your environment (thanks for all
> the details!) and experiment.  It looks like the problem is actually a
> mismatch between the formatting and parsing code for datapath flows.  If
> I run:
> 
> ovs-appctl ofproto/trace 
> "in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> 
> that is, add "eth()" to the datapath flow, then I get the expected
> results:
> 
> $ ovs-appctl ofproto/trace 
> "in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> Flow: 
> ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> 
> bridge("br0")
> -
>  0. priority 0
> resubmit(,1)
>  1. in_port=32770, priority 10
> load:0->OXM_OF_METADATA[]
> resubmit(,2)
>  2. priority 0
> resubmit(,3)
>  3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
> CONTROLLER:65535
> 
> Final flow: unchanged
> Megaflow: 
> recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
> Datapath actions: drop
> This flow is handled by the userspace slow path because it:
> - Sends "packet-in" messages to the OpenFlow controller.
> 
> Clearly that's a bug.  I'll see what I can do about it.
> 
> > Also, Whoever improved the output of ofproto/trace thanks a ton!
> 
> That was me :-)  You're welcome.
> 
> 
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Amar Padmanabhan]

Thanks Ben for taking a look,
Regards,
- Amar

On 12/6/17, 10:17 AM, "Ben Pfaff"  wrote:

On Wed, Dec 06, 2017 at 05:58:41AM +, Amar Padmanabhan wrote:
> We are debugging a setup and are seeing something that we are finding it 
hard to explain.
> 
> 1 - Here is the ovs-dpctl dump-flows output.
> 
recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
 packets:550, bytes:53900, used:0.364s, 
actions:userspace(pid=3276048382,slow_path(controller))

OK, the above datapath flow just says that packets in this flow have to
be handled in the userspace slow path because 

> 2 - We are now trying to trace this flow and are not seeing the output to 
controller flow getting hit in the trace.
> sudo ovs-appctl ofproto/trace 
"in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
> Flow: 
packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
> bridge("gtp_br0")
> -
> 0. priority 0 resubmit(,1)
> 1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
> 2. priority 0 resubmit(,3)
> 3. No match. drop Final flow: unchanged Megaflow: 
recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
drop ---> Why isn’t the output to controller flow getting hit?
> 
> 
> 3 - We are also seeing the flow counts go up for the output to controller 
flow per the ofctl dump-flows output (pasting relevant flows)
> 
> NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, table=0, 
n_packets=1408, n_bytes=148464, idle_age=1, priority=0 actions=resubmit(,1)
> cookie=0x0, duration=1482.244s, table=1, n_packets=1283, n_bytes=123662, 
idle_age=1, priority=10,in_port=32770 actions=set_field:0->metadata,resubmit(,2)
> cookie=0x0, duration=1482.244s, table=2, n_packets=1247, n_bytes=122150, 
idle_age=1, priority=0 actions=resubmit(,3)
> cookie=0x0, duration=1482.245s, table=3, n_packets=1245, n_bytes=122010, 
idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
actions=CONTROLLER:65535 ---> Notice that this is getting hit as well

OK, I spent a few minutes to mock up your environment (thanks for all
the details!) and experiment.  It looks like the problem is actually a
mismatch between the formatting and parsing code for datapath flows.  If
I run:

ovs-appctl ofproto/trace 
"in_port(3),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"

that is, add "eth()" to the datapath flow, then I get the expected
results:

$ ovs-appctl ofproto/trace 
"in_port(1),eth(),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
Flow: 
ip,in_port=32770,vlan_tci=0x,dl_src=00:00:00:00:00:00,dl_dst=00:00:00:00:00:00,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0

bridge("br0")
-
 0. priority 0
resubmit(,1)
 1. in_port=32770, priority 10
load:0->OXM_OF_METADATA[]
resubmit(,2)
 2. priority 0
resubmit(,3)
 3. ip,metadata=0,nw_dst=192.168.128.0/24, priority 0
CONTROLLER:65535

Final flow: unchanged
Megaflow: 
recirc_id=0,eth,ip,in_port=32770,nw_dst=192.168.128.0/24,nw_frag=no
Datapath actions: drop
This flow is handled by the userspace slow path because it:
- Sends "packet-in" messages to the OpenFlow controller.

Clearly that's a bug.  I'll see what I can do about it.

> Also, Whoever improved the output of ofproto/trace thanks a ton!

That was me :-)  You're welcome.


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Discrepancy between ofproto/trace output and dpctl dump-flows output

[Amar Padmanabhan]

Hi,
We are debugging a setup and are seeing something that we are finding it hard 
to explain.

1 - Here is the ovs-dpctl dump-flows output.
recirc_id(0),in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no),
 packets:550, bytes:53900, used:0.364s, 
actions:userspace(pid=3276048382,slow_path(controller))

2 - We are now trying to trace this flow and are not seeing the output to 
controller flow getting hit in the trace.
sudo ovs-appctl ofproto/trace 
"in_port(3),eth_type(0x0800),ipv4(dst=192.168.128.0/255.255.255.0,frag=no)"
Flow: 
packet_type=(1,0x800),in_port=32770,nw_src=0.0.0.0,nw_dst=192.168.128.0,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
bridge("gtp_br0")
-
0. priority 0 resubmit(,1)
1. in_port=32770, priority 10 set_field:0->metadata resubmit(,2)
2. priority 0 resubmit(,3)
3. No match. drop Final flow: unchanged Megaflow: 
recirc_id=0,packet_type=(1,0x800),in_port=32770,nw_frag=no Datapath actions: 
drop ---> Why isn’t the output to controller flow getting hit?


3 - We are also seeing the flow counts go up for the output to controller flow 
per the ofctl dump-flows output (pasting relevant flows)

NXST_FLOW reply (xid=0x4): cookie=0x0, duration=1482.245s, table=0, 
n_packets=1408, n_bytes=148464, idle_age=1, priority=0 actions=resubmit(,1)
cookie=0x0, duration=1482.244s, table=1, n_packets=1283, n_bytes=123662, 
idle_age=1, priority=10,in_port=32770 actions=set_field:0->metadata,resubmit(,2)
cookie=0x0, duration=1482.244s, table=2, n_packets=1247, n_bytes=122150, 
idle_age=1, priority=0 actions=resubmit(,3)
cookie=0x0, duration=1482.245s, table=3, n_packets=1245, n_bytes=122010, 
idle_age=1, priority=0,ip,metadata=0,nw_dst=192.168.128.0/24 
actions=CONTROLLER:65535 ---> Notice that this is getting hit as well

4 - Misc info:
ovs-vsctl (Open vSwitch) 2.8.0
DB Schema 7.15.0

ovs-appctl dpif/show
gtp_br0:
gtp0 32768/4: (gtp: key=flow, remote_ip=flow)
gtp_br0 65534/1: (internal)
int_nat_peer 32770/3: (system)
veth0_ovs 32769/2: (system)

Also, Whoever improved the output of ofproto/trace thanks a ton!

Thanks in advance!
Amar
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss