<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Jun 23, 2017 2:25 PM, &quot;Joe Stringer&quot; &lt;<a href="mailto:joe@ovn.org">joe@ovn.org</a>&gt; wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="elided-text">On 22 June 2017 at 16:08, Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
&gt; On Jun 23, 2017 1:31 AM, &quot;Joe Stringer&quot; &lt;<a href="mailto:joe@ovn.org">joe@ovn.org</a>&gt; wrote:<br>
&gt;<br>
&gt; On 22 June 2017 at 04:16, Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Jun 22, 2017 at 5:45 AM, Joe Stringer &lt;<a href="mailto:joe@ovn.org">joe@ovn.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On 21 June 2017 at 04:19, Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer &lt;<a href="mailto:joe@ovn.org">joe@ovn.org</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; On 19 June 2017 at 00:37, Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt; On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer &lt;<a href="mailto:joe@ovn.org">joe@ovn.org</a>&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; On 15 June 2017 at 22:20, Numan Siddique &lt;<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; On Thu, Jun 15, 2017 at 5:06 PM, Aswin S &lt;<a href="mailto:aswinsuryan@gmail.com">aswinsuryan@gmail.com</a>&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; wrote:<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; Adding some more info here, Thanks Numan! for pointing to this.<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; The issue I am facing looks similar to the one described in [1]<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; and<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; [2].<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; But it seems the issue is not yet fixed.  Is there a plan to fix<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; this<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; soon?<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; In Opendaylight security groups is implemented using<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; ovs-conntrack.<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; So<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; the<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; flow based router  ping  responder and floating IP translations<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; hits<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; this<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; issue.<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; [1]<a href="https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html" rel="noreferrer" target="_blank">https://mail.openvswitch.<wbr>org/pipermail/ovs-dev/2017-<wbr>March/329542.html</a><br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; [2]<a href="https://patchwork.ozlabs.org/patch/739796/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.<wbr>org/patch/739796/</a><br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; The same issuse is also seen in OVN as pointed by Aswin.<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; Joe - If you remember, we had a chat about this same issue during<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; the<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &gt; Openstack Boston summit.<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; Hi Numan, yeah I recall we had this discussion. I didn&#39;t have much<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; clarity on where we&#39;re at with this.  Looking at patchwork, I<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; provided<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; some feedback on the RFC. The most straightforward approach seems<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; to<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; &quot;set&quot;<br>
&gt;&gt;&gt; &gt;&gt; &gt;&gt; actions in the datapath.<br>
&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;&gt; &gt; Thanks. I will try it out and let you know how it went.<br>
&gt;&gt;&gt; &gt;&gt; &gt; I remember, I was suppose to provide more clarity after our<br>
&gt;&gt;&gt; &gt;&gt; &gt; discussion.<br>
&gt;&gt;&gt; &gt;&gt; &gt; My<br>
&gt;&gt;&gt; &gt;&gt; &gt; apologies. It slipped out of my head.<br>
&gt;&gt;&gt; &gt;&gt;<br>
&gt;&gt;&gt; &gt;&gt; No worries, let me know how you go.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; I tried this and it didn&#39;t work. In fact the function set_ipv4 (in<br>
&gt;&gt;&gt; &gt; datapath/actions.c) is not even called.<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Below is the flow which responds to ICMP request packet<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; cookie=0x64913aa, duration=566.801s, table=17, n_packets=3,<br>
&gt;&gt;&gt; &gt; n_bytes=294,<br>
&gt;&gt;&gt; &gt; idle_age=144,<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; priority=90,icmp,metadata=0x3,<wbr>nw_dst=192.168.0.1,icmp_type=<wbr>8,icmp_code=0<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; actions=push:NXM_OF_IP_SRC[],<wbr>push:NXM_OF_IP_DST[],pop:NXM_<wbr>OF_IP_SRC[],pop:NXM_OF_IP_DST[<wbr>],load:0xff-&gt;NXM_NX_IP_TTL[],<wbr>load:0-&gt;NXM_OF_ICMP_TYPE[],<wbr>load:0x1-&gt;NXM_NX_REG10[0],<wbr>resubmit(,18)<br>
&gt;&gt;&gt; &gt;<br>
&gt;&gt;&gt; &gt; Thanks<br>
&gt;&gt;&gt; &gt; Numan<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi Numan,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; How are you going about making these changes and testing them? Could<br>
&gt;&gt;&gt; you double-check that the correct module was loaded when you ran the<br>
&gt;&gt;&gt; test? Given that the IP src and dst are being modified from the flow<br>
&gt;&gt;&gt; you described above, I think that the set_ipv4 function should be<br>
&gt;&gt;&gt; called for such flows.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Some sanity checks:<br>
&gt;&gt;&gt; # modinfo openvswitch<br>
&gt;&gt;&gt; # find /lib/modules -name openvswitch.ko* | xargs ls -l<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Might want to double-check that your depmod.d settings are set<br>
&gt;&gt;&gt; correctly so it loads the new module instead of the one that comes<br>
&gt;&gt;&gt; with your kernel.<br>
&gt;&gt;&gt; # man depmod.d<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Of course, the above doesn&#39;t necessarily apply if you&#39;re making<br>
&gt;&gt;&gt; changes directly in your kernel tree and loading the module from there<br>
&gt;&gt;&gt; (for example, using insmod, or make modules_install into the original<br>
&gt;&gt;&gt; module path).<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Hi Joe,<br>
&gt;&gt;<br>
&gt;&gt; I verified that the loaded openvswitch module loaded is indeed modified by<br>
&gt;&gt; me.  I also put some printks in functions like &quot;ovs_packet_cmd_execute&quot; to<br>
&gt;&gt; verify.<br>
&gt;&gt;<br>
&gt;&gt; I created my testing scenario as per the commands here [1]. There are 2<br>
&gt;&gt; logical ports with IPs 192.168.0.2 and 192.168.0.3 associated to 2<br>
&gt;&gt; namespaces ns1 and ns2. The logical switch is also connected to a logical<br>
&gt;&gt; router.<br>
&gt;&gt;<br>
&gt;&gt; I pinged from 192.168.0.2 to 192.168.0.3 continuously and monitored the<br>
&gt;&gt; kernel flows with the command -<br>
&gt;&gt;<br>
&gt;&gt; $watch -n1 -d &quot;sudo ovs-dpctl dump-flows system@ovs-system&quot;<br>
&gt;&gt;<br>
&gt;&gt; recirc_id(0),in_port(3),eth(<wbr>src=00:00:00:00:00:00/01:00:<wbr>00:00:00:00,dst=50:54:00:00:<wbr>00:01),eth_type(0x0800),ipv4(<wbr>dst=<a href="http://192.168.0.2/255.255.255.254,frag=no" rel="noreferrer" target="_blank">192.168.0.2/255.255.255.<wbr>254,frag=no</a>),<br>
&gt;&gt; packets:28, bytes:2744, used:0.323s, actions:2<br>
&gt;&gt;<br>
&gt;&gt; recirc_id(0),in_port(2),eth(<wbr>src=00:00:00:00:00:00/01:00:<wbr>00:00:00:00,dst=50:54:00:00:<wbr>00:02),eth_type(0x0800),ipv4(<wbr>dst=<a href="http://192.168.0.2/255.255.255.254,frag=no" rel="noreferrer" target="_blank">192.168.0.2/255.255.255.<wbr>254,frag=no</a>),<br>
&gt;&gt; packets:28, bytes:2744, used:0.323s, actions:3<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I pinged from 192.168.0.2 to 192.168.0.1 (without any ACLs, so the ping<br>
&gt;&gt; would be successful), I observed that the action is always userspace and I<br>
&gt;&gt; could see that the function &quot;odp_execute_masked_set_<wbr>action&quot; in<br>
&gt;&gt; lib/odp-execute.c is called in vswitchd.<br>
&gt;&gt;<br>
&gt;&gt; $watch -n1 -d &quot;sudo ovs-dpctl dump-flows system@ovs-system&quot;<br>
&gt;&gt;<br>
&gt;&gt; recirc_id(0),in_port(2),eth(<wbr>src=50:54:00:00:00:01,dst=00:<wbr>00:00:00:ff:01),eth_type(<wbr>0x0806),arp(sip=192.168.0.2,<wbr>tip=192.168.0.1,op=1/0xff,sha=<wbr>50:54:00:00:00:01,tha=00:00:<wbr>00:00:00:00),<br>
&gt;&gt; packets:0, bytes:0, used:never,<br>
&gt;&gt; actions:userspace(pid=<wbr>4294958020,slow_path(action))<br>
&gt;&gt;<br>
&gt;&gt; recirc_id(0),in_port(2),eth(<wbr>src=50:54:00:00:00:01,dst=00:<wbr>00:00:00:ff:01),eth_type(<wbr>0x0800),ipv4(src=192.168.0.2,<wbr>dst=192.168.0.1,proto=1,ttl=<wbr>64,frag=no),icmp(type=8,code=<wbr>0),<br>
&gt;&gt; packets:9, bytes:882, used:0.937s,<br>
&gt;&gt; actions:userspace(pid=<wbr>4294958021,slow_path(action))<br>
&gt;&gt;<br>
&gt;&gt; In this case, the ICMP reply is framed by the OVS flow  and there is<br>
&gt;&gt; &quot;clone&quot;<br>
&gt;&gt; action involved for the packet to go to and from the logical switch to<br>
&gt;&gt; logical router pipeline.<br>
&gt;&gt;<br>
&gt;&gt; To avoid clone action, I added some code in ovn-northd to respond the ICMP<br>
&gt;&gt; reply if the ip4.dst = 192.168.0.1 which translated to the below OF flow<br>
&gt;&gt;<br>
&gt;&gt; table=19, n_packets=619, n_bytes=60662, idle_age=1,<br>
&gt;&gt; priority=90,icmp,metadata=0x1,<wbr>nw_dst=192.168.0.1,icmp_type=<wbr>8,icmp_code=0<br>
&gt;&gt;<br>
&gt;&gt; actions=move:NXM_OF_IP_SRC[]-&gt;<wbr>NXM_OF_IP_DST[],mod_nw_src:<wbr>192.168.0.1,push:NXM_OF_ETH_<wbr>SRC[],push:NXM_OF_ETH_DST[],<wbr>pop:NXM_OF_ETH_SRC[],pop:NXM_<wbr>OF_ETH_DST[],load:0xff-&gt;NXM_<wbr>NX_IP_TTL[],load:0-&gt;NXM_OF_<wbr>ICMP_TYPE[],load:0x1-&gt;NXM_NX_<wbr>REG10[0],resubmit(,20)<br>
&gt;&gt;<br>
&gt;&gt; And in both the cases I see that there is an upcall for each packet and<br>
&gt;&gt; odp_execute_masked_set_action is called.<br>
&gt;<br>
&gt; OK, I think that my suggestion for that patch (patchwork 739796) was<br>
&gt; actually addressing a subtly different issue.<br>
&gt;<br>
&gt; With regards to this issue, as far as I understand back to the<br>
&gt; original report, connection with tuple A is committed to the<br>
&gt; connection tracker. A is then statelessly modified to tuple B, then a<br>
&gt; lookup with B is performed. Typically if you have tuple A or tuple A&#39;<br>
&gt; (ie, the reversed tuple) in the packet headers then looking up with<br>
&gt; either of these headers will find the same connection. If you then<br>
&gt; perform a lookup with tuple B, then it can only look up using B or B&#39;;<br>
&gt; no state was kept about the translation from A-&gt;B, so there&#39;s no way<br>
&gt; for the connection tracker to associate tuple B back to tuple A.<br>
&gt; Lookup using B and B&#39; cannot find a connection because it was never<br>
&gt; committed like that. Therefore it would be new. However, since B is a<br>
&gt; SYN-ACK packet, the Linux connection tracker considers that it is<br>
&gt; invalid rather than new. For it to work, the tuple B&#39;, ie the original<br>
&gt; SYN, should be committed first.<br>
&gt;<br>
&gt;<br>
&gt; Thanks for the explanation. The issue we are seeing is for ICMP packets and<br>
&gt; looking into the connection tracking entries I see the packet is in<br>
&gt; UNREPLIED state. When the ICMP reply is framed by the ovs flows, the tuple<br>
&gt; would still remain the same right ? Only ip4.src is swapped with ip4.dst and<br>
&gt; ICMP code is changed.<br>
<br>
</div>Right, so for ICMP I think the problem is different. Yes, by the looks<br>
only src/dst are swapped and code changed, which should produce a<br>
tuple that can look up and find the original connection. Given that<br>
the execution is happening in userspace, that would be one path to<br>
follow: exactly what is executed upon the packet in terms of datapath<br>
actions after the kernel runs userspace(...,slow_path(<wbr>action))? Where<br>
is the conntrack call from that path, and how does it try to get the<br>
ct_state from the kernel?<br>
<br>
I wonder if the ICMP issue is related to the patch here:<br>
<a href="http://patchwork.ozlabs.org/patch/775756/" rel="noreferrer" target="_blank">http://patchwork.ozlabs.org/<wbr>patch/775756/</a></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Thanks. I will test some more and get back on this.</div><div dir="auto"><br></div><div dir="auto">Nirman</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
</blockquote></div><br></div></div></div>