Ben,
Thanks for your quick response. Your assessment makes sense to me. For
IPv4, I don't think 0 would be a valid protocol number but for IPv6 it
would mean that the hop-by-hop options are present.
What do you think about the extra no-op actions in the datapath
actions when I set the protocol to icmp? 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 seems
some of the internal megaflow implementation leaking into the datapath
actions.
Thank you,
Carl
$ 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
On Tue, May 7, 2019 at 5:00 PM Ben Pfaff <b...@ovn.org> wrote:
>
> 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
