On 16 December 2016 at 09:12, Sridhar Gaddam <[email protected]> wrote: > > > > On Tue, Dec 13, 2016 at 1:12 PM, Daniele Di Proietto <[email protected]> > wrote: > >> 2016-12-12 3:21 GMT-08:00 Sridhar Gaddam <[email protected]>: >> > 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. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
