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

Amar Padmanabhan amarpadmanabhan at fb.com
Thu Mar 15 00:03:59 UTC 2018


Awesome thanks Ben!
- Amar

On 3/14/18, 4:49 PM, "Ben Pfaff" <blp at ovn.org> 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 +0000, Amar Padmanabhan wrote:
    > Yup thanks we are unblocked!
    > - Amar
    > 
    > On 12/6/17, 12:36 PM, "Ben Pfaff" <blp at ovn.org> 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 +0000, Amar Padmanabhan wrote:
    >     > Thanks Ben for taking a look,
    >     > Regards,
    >     > - Amar
    >     > 
    >     > On 12/6/17, 10:17 AM, "Ben Pfaff" <blp at ovn.org> wrote:
    >     > 
    >     >     On Wed, Dec 06, 2017 at 05:58:41AM +0000, 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=0x0000,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.
    >     >     
    >     > 
    >     
    > 
    



More information about the discuss mailing list