From: Jarno Rajahalme <[email protected]> Date: Monday, December 19, 2016 at 2:30 PM To: Darrell Ball <[email protected]> Cc: Sridhar Gaddam <[email protected]>, "[email protected]" <[email protected]>, Srikanth Vavilapalli <[email protected]> Subject: Re: [ovs-dev] OVS2.6+dpdk IPv6 Conntrack support
On Dec 19, 2016, at 1:29 PM, Darrell Ball <[email protected]<mailto:[email protected]>> wrote: On 12/16/16, 1:25 PM, "[email protected]<mailto:[email protected]> on behalf of Jarno Rajahalme" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: On Dec 16, 2016, at 9:12 AM, Sridhar Gaddam <[email protected]<mailto:[email protected]>> wrote: On Tue, Dec 13, 2016 at 1:12 PM, Daniele Di Proietto <[email protected]<mailto:[email protected]>> wrote: 2016-12-12 3:21 GMT-08:00 Sridhar Gaddam <[email protected]<mailto:[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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitch_ovs_blob_master_NEWS&d=DgIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=mKE_yUtefdGBHPQFzof9bTj8s0GLdzeq7JAQxtXKOiw&s=tLk5RAXCyQ-F125wXNI-MI4d4MY3PYCwrgBY6QyI-90&e= 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) This seems to be an inconsistency in handling packets that are not tracked. Even Linux kernel conntrack does not track neighbor discovery for obvious reasons, but it still attaches a special “notrack” entry with the packet and reports it as “NEW”. How does the kernel know these are valid/safe ND packets ? I’m guessing it doesn’t. Jarno Packets are sent thru. conntrack to filter bad flows, but in this case, conntrack is not doing that and records to that effect (i.e. notrack). But we already know conntrack does not handle ND, so why send these packets thru. conntrack in the first place, which was your suggestion earlier. Also, is there some expectation that conntrack should allow all non-tracked packets thru., by default ? iptables allows the user to open these holes via explicit configuration. Flagging ND traffic as “+inv” is probably not the right thing to do, but the workaround for now is to not send ND packets to conntrack in the first place. Jarno 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.opendaylight.org_pipermail_netvirt-2Ddev_&d=DgIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=mKE_yUtefdGBHPQFzof9bTj8s0GLdzeq7JAQxtXKOiw&s=6nqF_U69noH6tzvthi34Sz4vwvywPT7jA9PJkJaLawE&e= 2016-December/002527.html Thanks, --Sridhar. Thank you, --Sridhar. _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DgIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=mKE_yUtefdGBHPQFzof9bTj8s0GLdzeq7JAQxtXKOiw&s=5DbN-MLADnaU83fHKDTMJSqeFvaerpR69ytO3BLbE9k&e= _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DgIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=mKE_yUtefdGBHPQFzof9bTj8s0GLdzeq7JAQxtXKOiw&s=5DbN-MLADnaU83fHKDTMJSqeFvaerpR69ytO3BLbE9k&e= _______________________________________________ dev mailing list [email protected]<mailto:[email protected]> https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DgIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=mKE_yUtefdGBHPQFzof9bTj8s0GLdzeq7JAQxtXKOiw&s=5DbN-MLADnaU83fHKDTMJSqeFvaerpR69ytO3BLbE9k&e= _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
