I investigated this a little bit by putting the following in a file
named 'flows':
table=0 ip,in_port=4,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.39.176.4,priority=3100,
actions=resubmit(,25)
table=25, ip,vlan_tci=0x1000/0x1000,nw_dst=10.39.176.4, priority=3100,
actions=set_field:00:00:5e:00:01:01->eth_src,
set_field:a6:c1:a7:15:a4:3d->eth_dst, pop_vlan, resubmit(,28)
table=28, priority=100, actions=resubmit(,35)
table=35, ip,nw_dst=10.39.176.4, priority=3100
actions=set_field:10.16.0.5->ip_dst, resubmit(,45)
table=45, priority=100, actions=resubmit(,50)
table=50, priority=100, actions=resubmit(,60)
table=60, priority=100, actions=resubmit(,62)
table=62, priority=100, actions=resubmit(,65)
table=65, ip,dl_dst=a6:c1:a7:15:a4:3d,nw_dst=10.16.0.5, priority=3100,
actions=p21
and the following in one named trace-test:
#! /bin/sh -v
ovs-vsctl add-br br0
ovs-vsctl add-port br0 p21
ovs-ofctl add-flows br0 flows
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
and then ran the latter inside "make sandbox". I reproduced the
behavior.
When I look closer, I see that the logic inside OVS, in
commit_set_nw_action() in particular, uses the presence of a nonzero IP
protocol to determine whether there's actually an L3 header present.
Thus, specifying an IP protocol, e.g. with "icmp" or "tcp" or "udp",
makes the issue go away.
This is definitely surprising behavior. I am not sure whether the
nonzero IP protocol number check is actually necessary. If I remove it,
it does fix this problem. That may be the correct fix.
On Tue, May 07, 2019 at 04:12:10PM -0600, Carl Baldwin wrote:
> 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
> _______________________________________________
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
_______________________________________________
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
