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