[ovs-dev] OVS2.6+dpdk IPv6 Conntrack support

Joe Stringer joe at ovn.org
Fri Dec 16 19:15:09 UTC 2016


On 16 December 2016 at 09:12, Sridhar Gaddam <sgaddam at redhat.com> wrote:
>
>
>
> On Tue, Dec 13, 2016 at 1:12 PM, Daniele Di Proietto <diproiettod at ovn.org>
> wrote:
>
>> 2016-12-12 3:21 GMT-08:00 Sridhar Gaddam <sgaddam at redhat.com>:
>> > Hello,
>> >
>> > In our setup, we are using OVS 2.6+dpdk and are noticing that conntrack
>> for
>> > IPv6 traffic is NOT working.
>> > However, the same use-case works fine for Ipv4 traffic.
>> >
>> > We had a look at OVS 2.6 release notes[1], and it mentions that "Basic
>> > connection tracking for the user space datapath (no ALG, fragmentation or
>> > NAT support yet) is supported".
>> > There is no explicit mention of IPv6. So, can someone please confirm if
>> > conntrack for IPv6 is supported in OVS2.6+dpdk?
>> >
>> > [1] https://github.com/openvswitch/ovs/blob/master/NEWS
>>
>> IPv6 should be supported.  There are a few testcases in the system
>> userspace testsuite (`make check-system-userspace`) that cover that.
>>
>> Could you tell us more about your setup?
>>
>
>
> Sorry for the delay in response. I do not have a local setup to reproduce
> the issue, so was trying to gather some details from the team that
> originally noticed this.
>
> Basically we are seeing this issue in OpenDaylight use-case when using
> OVS2.6+dpdk along with conntrack.
>
> A simplified view of the use-case is as follows.
> 1. We have a VM spawned with MAC of "fa:16:3e:6e:9f:b0" and it is sending
> out a Neighbor Solicitation for another VM on the same network.
> 2. We use conntrack for tracking the connections, so the Neighbor
> Solicitation packets initially hit flow (a) in table40, and in table41 the
> ct_state matches to "+inv" and are getting dropped (flow e).
> 3. This behavior (i.e., ct_state=+inv+trk) is seen for ICMPv6 Neighbor
> Solicitation messages and not for other IPv6 TCP/UDP traffic.
> 4. Also, this behavior is NOT seen when using OVS kernel datapath (i.e., in
> table 41, we see that ct_state matches to +new+trk instead of +inv+trk)
>
> Srikanth, who is noticing this issue, was also informed by his switch team
> that OVS
> conntrack
> explicitly treats the IPv6 Neighbor Solicitation as an invalid connection.
> For more details, please see the email thread [*] where this issue is
> discussed.
>
> We are trying to see if we should bypass conntrack for NDP packets. In the
> meantime, if you know the specific reason why NS packets are treated this
> way, can you please let us know?

Neighbour discovery isn't a point-to-point connection, so it doesn't
make sense to statefully track whether it's "established" and so on.


More information about the dev mailing list