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? Sample flows: a) table=40, n_packets=246, n_bytes=21156, priority=61010,ipv6,dl_src=fa: 16:3e:6e:9f:b0,ipv6_src=2001:db8:1234:0:f816:3eff:fe6e:9fb0 actions=ct(table=41,zone=5002) b) table=41, n_packets=0, n_bytes=0, priority=62020,ct_state=-new+est-rel-inv+trk actions=resubmit(,17) c) table=41, n_packets=0, n_bytes=0, priority=62020,ct_state=-new-est+rel-inv+trk actions=resubmit(,17) d) table=41, n_packets=0, n_bytes=0, priority=12806,ct_state=+new+ trk,ipv6,metadata=0x19a80000000000/0x1fffff0000000000 actions=ct(commit,zone=5002),resubmit(,17) e) table=41, n_packets=246, n_bytes=21156, priority=62020,ct_state=+inv+trk actions=drop [*] https://lists.opendaylight.org/pipermail/netvirt-dev/ 2016-December/002527.html Thanks, --Sridhar. > > > > > Thank you, > > --Sridhar. > > _______________________________________________ > > dev mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
