On 21 June 2017 at 04:19, Numan Siddique <[email protected]> wrote: > > > On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer <[email protected]> wrote: >> >> On 19 June 2017 at 00:37, Numan Siddique <[email protected]> wrote: >> > >> > >> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer <[email protected]> wrote: >> >> >> >> On 15 June 2017 at 22:20, Numan Siddique <[email protected]> wrote: >> >> > >> >> > >> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S <[email protected]> >> >> > wrote: >> >> >> >> >> >> >> >> >> Adding some more info here, Thanks Numan! for pointing to this. >> >> >> >> >> >> The issue I am facing looks similar to the one described in [1] and >> >> >> [2]. >> >> >> But it seems the issue is not yet fixed. Is there a plan to fix >> >> >> this >> >> >> soon? >> >> >> In Opendaylight security groups is implemented using ovs-conntrack. >> >> >> So >> >> >> the >> >> >> flow based router ping responder and floating IP translations hits >> >> >> this >> >> >> issue. >> >> >> >> >> >> >> >> >> >> >> >> [1]https://mail.openvswitch.org/pipermail/ovs-dev/2017-March/329542.html >> >> >> [2]https://patchwork.ozlabs.org/patch/739796/ >> >> >> >> >> > >> >> > The same issuse is also seen in OVN as pointed by Aswin. >> >> > >> >> > Joe - If you remember, we had a chat about this same issue during the >> >> > Openstack Boston summit. >> >> >> >> Hi Numan, yeah I recall we had this discussion. I didn't have much >> >> clarity on where we're at with this. Looking at patchwork, I provided >> >> some feedback on the RFC. The most straightforward approach seems to >> >> be adding a nf_ct_set(skb, NULL, 0); call for each of the 5tuple "set" >> >> actions in the datapath. >> > >> > >> > Thanks. I will try it out and let you know how it went. >> > I remember, I was suppose to provide more clarity after our discussion. >> > My >> > apologies. It slipped out of my head. >> >> No worries, let me know how you go. > > > I tried this and it didn't work. In fact the function set_ipv4 (in > datapath/actions.c) is not even called. > > Below is the flow which responds to ICMP request packet > > cookie=0x64913aa, duration=566.801s, table=17, n_packets=3, n_bytes=294, > idle_age=144, > priority=90,icmp,metadata=0x3,nw_dst=192.168.0.1,icmp_type=8,icmp_code=0 > actions=push:NXM_OF_IP_SRC[],push:NXM_OF_IP_DST[],pop:NXM_OF_IP_SRC[],pop:NXM_OF_IP_DST[],load:0xff->NXM_NX_IP_TTL[],load:0->NXM_OF_ICMP_TYPE[],load:0x1->NXM_NX_REG10[0],resubmit(,18) > > Thanks > Numan
Hi Numan, How are you going about making these changes and testing them? Could you double-check that the correct module was loaded when you ran the test? Given that the IP src and dst are being modified from the flow you described above, I think that the set_ipv4 function should be called for such flows. Some sanity checks: # modinfo openvswitch # find /lib/modules -name openvswitch.ko* | xargs ls -l Might want to double-check that your depmod.d settings are set correctly so it loads the new module instead of the one that comes with your kernel. # man depmod.d Of course, the above doesn't necessarily apply if you're making changes directly in your kernel tree and loading the module from there (for example, using insmod, or make modules_install into the original module path). Cheers, Joe _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
