[ovs-discuss] DNAT missing from datapath actions in ofproto/trace

Carl Baldwin carl at ecbaldwin.net
Tue May 7 22:12:10 UTC 2019


Greetings,

I have been using ofproto/trace to verify the actions taken on various
packets through an OVS bridge. My methodology is basically to specify
the action in br_flow format to ovs-appctl ofproto/trace and then
comparing the datapath actions line with expected actions. I ran into
an interesting case. I'm reaching out to the mailing list to try to
get an idea of what is happening and if this is expected behavior.

Thanks in advance for your time to consider this. Details follow.

I was testing a particular path that results in rewriting the ip_dst
of the packet (a stateless DNAT). In my first attempt, the datapath
actions line doesn't include the DNAT  though you can see the
set_field action in table 35 in the output below.

This makes verifying the datapath actions problematic because an
important action is missing. The backup plan here would be to scrape
the actions from the output by looking for keywords like set_field,
pop_vlan, and output in the more verbose trace output. Would you
advise doing this instead of using the datapath actions line?

    $ ovs-appctl ofproto/trace br0
ip,dl_vlan=13,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.39.176.4,in_port=4
    Flow: ip,in_port=4,dl_vlan=13,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.39.176.4,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0

    bridge("br0")
    -------------
     0. ip,in_port=4,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.39.176.4,
priority 3100, cookie 0x1dfd9000600000
        resubmit(,25)
    25. ip,vlan_tci=0x1000/0x1000,nw_dst=10.39.176.4, priority 3100,
cookie 0x1dfd9000600000
        set_field:00:00:5e:00:01:01->eth_src
        set_field:a6:c1:a7:15:a4:3d->eth_dst
        pop_vlan
        resubmit(,28)
    28. priority 100
        resubmit(,35)
    35. ip,nw_dst=10.39.176.4, priority 3100, cookie 0x1dfd9000600000
        set_field:10.16.0.5->ip_dst
        resubmit(,45)
    45. priority 100
        resubmit(,50)
    50. priority 100
        resubmit(,60)
    60. priority 100
        resubmit(,62)
    62. priority 100
        resubmit(,65)
    65. ip,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.16.0.5, priority 3100,
cookie 0x1dfd9000600000
        output:21

    Final flow:
ip,in_port=4,vlan_tci=0x0000,dl_src=00:00:5e:00:01:01,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.16.0.5,nw_proto=0,nw_tos=0,nw_ecn=0,nw_ttl=0
    Megaflow: recirc_id=0,eth,ip,tun_id=0,in_port=4,dl_vlan=13,dl_vlan_pcp=0,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=0.0.0.0/5,nw_dst=10.39.176.4,nw_frag=no
    Datapath actions:
set(eth(src=00:00:5e:00:01:01,dst=a6:c1:a7:15:a4:3d)),pop_vlan,7

By accident, I discovered that if I replaced ip with icmp in the
br_flow spec then I got another unexpected result. The DNAT shows up
on the datapath actions line. However, it also sets the ip src
(src=0.0.0.0/248.0.0.0). This appears to coincide with a match in the
megaflow (nw_src=0.0.0.0/5) effectively making it a no-op. If I change
the nw_src value in the original br_flow, then I get different values
for these but it always boils down to essentially a no-op.

This makes verifying the datapath actions problematic because I'd have
to write extra logic to detect and remove no-ops. I could bake the
no-op actions into my expected actions but I'm not confident that the
internal implementation won't change and leave me with a bunch of
failures to fix up later. This is internal implementation leaking into
the datapath actions. The same backup plan of scraping the output for
action lines and ignoring the datapath actions line would work here
too.

    $ ovs-appctl ofproto/trace br0
icmp,dl_vlan=13,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.39.176.4,in_port=4
    Flow: icmp,in_port=4,dl_vlan=13,dl_vlan_pcp=0,vlan_tci1=0x0000,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.39.176.4,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0

    bridge("br0")
    -------------
     0. ip,in_port=4,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.39.176.4,
priority 3100, cookie 0x1dfd9000600000
        resubmit(,25)
    25. ip,vlan_tci=0x1000/0x1000,nw_dst=10.39.176.4, priority 3100,
cookie 0x1dfd9000600000
        set_field:00:00:5e:00:01:01->eth_src
        set_field:a6:c1:a7:15:a4:3d->eth_dst
        pop_vlan
        resubmit(,28)
    28. priority 100
        resubmit(,35)
    35. ip,nw_dst=10.39.176.4, priority 3100, cookie 0x1dfd9000600000
        set_field:10.16.0.5->ip_dst
        resubmit(,45)
    45. priority 100
        resubmit(,50)
    50. priority 100
        resubmit(,60)
    60. priority 100
        resubmit(,62)
    62. priority 100
        resubmit(,65)
    65. ip,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.16.0.5, priority 3100,
cookie 0x1dfd9000600000
        output:21

    Final flow:
icmp,in_port=4,vlan_tci=0x0000,dl_src=00:00:5e:00:01:01,dl_dst=a6:c1:a7:15:a4:3d,nw_src=1.1.1.1,nw_dst=10.16.0.5,nw_tos=0,nw_ecn=0,nw_ttl=0,icmp_type=0,icmp_code=0
    Megaflow: recirc_id=0,eth,ip,tun_id=0,in_port=4,dl_vlan=13,dl_vlan_pcp=0,dl_src=d8:18:d3:fd:66:40,dl_dst=a6:c1:a7:15:a4:3d,nw_src=0.0.0.0/5,nw_dst=10.39.176.4,nw_frag=no
    Datapath actions:
set(eth(src=00:00:5e:00:01:01,dst=a6:c1:a7:15:a4:3d)),set(ipv4(src=0.0.0.0/248.0.0.0,dst=10.16.0.5)),pop_vlan,7

Thanks for your time,
Carl Baldwin


More information about the discuss mailing list