<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 22, 2017 at 5:45 AM, Joe Stringer <span dir="ltr"><<a href="mailto:joe@ovn.org" target="_blank">joe@ovn.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 21 June 2017 at 04:19, Numan Siddique <<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>> wrote:<br>
><br>
><br>
> On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer <<a href="mailto:joe@ovn.org">joe@ovn.org</a>> wrote:<br>
>><br>
>> On 19 June 2017 at 00:37, Numan Siddique <<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer <<a href="mailto:joe@ovn.org">joe@ovn.org</a>> wrote:<br>
>> >><br>
>> >> On 15 June 2017 at 22:20, Numan Siddique <<a href="mailto:nusiddiq@redhat.com">nusiddiq@redhat.com</a>> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S <<a href="mailto:aswinsuryan@gmail.com">aswinsuryan@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >><br>
>> >> >> Adding some more info here, Thanks Numan! for pointing to this.<br>
>> >> >><br>
>> >> >> The issue I am facing looks similar to the one described in [1] and<br>
>> >> >> [2].<br>
>> >> >> But it seems the issue is not yet fixed. Is there a plan to fix<br>
>> >> >> this<br>
>> >> >> soon?<br>
>> >> >> In Opendaylight security groups is implemented using ovs-conntrack.<br>
>> >> >> So<br>
>> >> >> the<br>
>> >> >> flow based router ping responder and floating IP translations hits<br>
>> >> >> this<br>
>> >> >> issue.<br>
>> >> >><br>
>> >> >><br>
>> >> >><br>
>> >> >> [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>
>> >> >> [2]<a href="https://patchwork.ozlabs.org/patch/739796/" rel="noreferrer" target="_blank">https://patchwork.ozlabs.<wbr>org/patch/739796/</a><br>
>> >> >><br>
>> >> ><br>
>> >> > The same issuse is also seen in OVN as pointed by Aswin.<br>
>> >> ><br>
>> >> > Joe - If you remember, we had a chat about this same issue during the<br>
>> >> > Openstack Boston summit.<br>
>> >><br>
>> >> Hi Numan, yeah I recall we had this discussion. I didn't have much<br>
>> >> clarity on where we're at with this. Looking at patchwork, I provided<br>
>> >> some feedback on the RFC. The most straightforward approach seems to<br>
>> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple "set"<br>
>> >> actions in the datapath.<br>
>> ><br>
>> ><br>
>> > Thanks. I will try it out and let you know how it went.<br>
>> > I remember, I was suppose to provide more clarity after our discussion.<br>
>> > My<br>
>> > apologies. It slipped out of my head.<br>
>><br>
>> No worries, let me know how you go.<br>
><br>
><br>
> I tried this and it didn't work. In fact the function set_ipv4 (in<br>
> datapath/actions.c) is not even called.<br>
><br>
> Below is the flow which responds to ICMP request packet<br>
><br>
> cookie=0x64913aa, duration=566.801s, table=17, n_packets=3, n_bytes=294,<br>
> idle_age=144,<br>
> priority=90,icmp,metadata=0x3,<wbr>nw_dst=192.168.0.1,icmp_type=<wbr>8,icmp_code=0<br>
> 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->NXM_NX_IP_TTL[],<wbr>load:0->NXM_OF_ICMP_TYPE[],<wbr>load:0x1->NXM_NX_REG10[0],<wbr>resubmit(,18)<br>
><br>
> Thanks<br>
> Numan<br>
<br>
</div></div>Hi Numan,<br>
<br>
How are you going about making these changes and testing them? Could<br>
you double-check that the correct module was loaded when you ran the<br>
test? Given that the IP src and dst are being modified from the flow<br>
you described above, I think that the set_ipv4 function should be<br>
called for such flows.<br>
<br>
Some sanity checks:<br>
# modinfo openvswitch<br>
# find /lib/modules -name openvswitch.ko* | xargs ls -l<br>
<br>
Might want to double-check that your depmod.d settings are set<br>
correctly so it loads the new module instead of the one that comes<br>
with your kernel.<br>
# man depmod.d<br>
<br>
Of course, the above doesn't necessarily apply if you're making<br>
changes directly in your kernel tree and loading the module from there<br>
(for example, using insmod, or make modules_install into the original<br>
module path).<br>
<br></blockquote><div><br></div><div>Hi Joe,</div><div><br></div><div>I verified that the loaded openvswitch module loaded is indeed modified by me. I also put some printks in functions like "ovs_packet_cmd_execute" to verify.</div><div><br></div><div>I created my testing scenario as per the commands here [1]. There are 2 logical ports with IPs 192.168.0.2 and 192.168.0.3 associated to 2 namespaces ns1 and ns2. The logical switch is also connected to a logical router.</div><div><br></div><div>I pinged from 192.168.0.2 to 192.168.0.3 continuously and monitored the kernel flows with the command -</div><div><br></div><div>$watch -n1 -d "sudo ovs-dpctl dump-flows system@ovs-system"</div><div><div>recirc_id(0),in_port(3),eth(src=00:00:00:00:00:00/01:00:00:00:00:00,dst=50:54:00:00:00:01),eth_type(0x0800),ipv4(dst=<a href="http://192.168.0.2/255.255.255.254,frag=no">192.168.0.2/255.255.255.254,frag=no</a>), packets:28, bytes:2744, used:0.323s, actions:2</div><div>recirc_id(0),in_port(2),eth(src=00:00:00:00:00:00/01:00:00:00:00:00,dst=50:54:00:00:00:02),eth_type(0x0800),ipv4(dst=<a href="http://192.168.0.2/255.255.255.254,frag=no">192.168.0.2/255.255.255.254,frag=no</a>), packets:28, bytes:2744, used:0.323s, actions:3</div></div><div><br></div><div><br></div><div>I pinged from 192.168.0.2 to 192.168.0.1 (without any ACLs, so the ping would be successful), I observed that the action is always userspace and I could see that the function "odp_execute_masked_set_action" in lib/odp-execute.c is called in vswitchd.</div><div><br></div><div>$watch -n1 -d "sudo ovs-dpctl dump-flows system@ovs-system"<br></div><div><div>recirc_id(0),in_port(2),eth(src=50:54:00:00:00:01,dst=00:00:00:00:ff:01),eth_type(0x0806),arp(sip=192.168.0.2,tip=192.168.0.1,op=1/0xff,sha=50:54:00:00:00:01,tha=00:00:00:00:00:00), packets:0, bytes:0, used:never, actions:userspace(pid=4294958020,slow_path(action))</div><div>recirc_id(0),in_port(2),eth(src=50:54:00:00:00:01,dst=00:00:00:00:ff:01),eth_type(0x0800),ipv4(src=192.168.0.2,dst=192.168.0.1,proto=1,ttl=64,frag=no),icmp(type=8,code=0), packets:9, bytes:882, used:0.937s, actions:userspace(pid=4294958021,slow_path(action))</div></div><div><br></div><div>In this case, the ICMP reply is framed by the OVS flow and there is "clone" action involved for the packet to go to and from the logical switch to logical router pipeline.</div><div><br></div><div>To avoid clone action, I added some code in ovn-northd to respond the ICMP reply if the ip4.dst = 192.168.0.1 which translated to the below OF flow</div><div><br></div><div>table=19, n_packets=619, n_bytes=60662, idle_age=1, priority=90,icmp,metadata=0x1,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0 actions=move:NXM_OF_IP_SRC[]->NXM_OF_IP_DST[],mod_nw_src:192.168.0.1,push:NXM_OF_ETH_SRC[],push:NXM_OF_ETH_DST[],pop:NXM_OF_ETH_SRC[],pop:NXM_OF_ETH_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,20)<br></div><div><br></div><div>And in both the cases I see that there is an upcall for each packet and odp_execute_masked_set_action is called.</div><div><br></div><div>Thanks</div><div>Numan</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>I </div><div><br></div><div>[1] - <a href="https://gist.github.com/russellb/4ab0a9641f12f8ac66fdd6822ee7789e">https://gist.github.com/russellb/4ab0a9641f12f8ac66fdd6822ee7789e</a></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
Joe<br>
</blockquote></div><br></div></div>