[ovs-discuss] Issue with connection tracking for packets modified in pipeline

Joe Stringer joe at ovn.org
Thu Jun 22 00:15:44 UTC 2017


On 21 June 2017 at 04:19, Numan Siddique <nusiddiq at redhat.com> wrote:
>
>
> On Tue, Jun 20, 2017 at 3:11 AM, Joe Stringer <joe at ovn.org> wrote:
>>
>> On 19 June 2017 at 00:37, Numan Siddique <nusiddiq at redhat.com> wrote:
>> >
>> >
>> > On Fri, Jun 16, 2017 at 11:22 PM, Joe Stringer <joe at ovn.org> wrote:
>> >>
>> >> On 15 June 2017 at 22:20, Numan Siddique <nusiddiq at redhat.com> wrote:
>> >> >
>> >> >
>> >> > On Thu, Jun 15, 2017 at 5:06 PM, Aswin S <aswinsuryan at gmail.com>
>> >> > 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


More information about the discuss mailing list