Thanks Daniele for addressing the issue and fixing the inconsistency. Best Regards, --Sridhar.
On Wed, Dec 21, 2016 at 2:05 AM, Daniele Di Proietto <[email protected]> wrote: > 2016-12-19 21:25 GMT-08:00 Darrell Ball <[email protected]>: > > > > > > 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 <srikanth.vavilapalli@ > ericsson.com> > > Subject: Re: [ovs-dev] OVS2.6+dpdk IPv6 Conntrack support > > > > > > On Dec 19, 2016, at 1:29 PM, Darrell Ball <[email protected]<mailto:dball > @vmware.com>> 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:sga > [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_yUtefdGBHPQFzof9bTj8s0GLdzeq7J > AQxtXKOiw&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. > > > > There is a specific test case in the userspace testsuite that made > sure that we treated > neighbor discovery as invalid: > > ofproto-dpif - conntrack - untrackable traffic > > I thought it made sense because I didn't see much value in handling > stateless policies in the connection tracker. > > I guess we can change the behavior to be consistent with the kernel. > I sent two patches here: > > https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326508.html > https://mail.openvswitch.org/pipermail/ovs-dev/2016-December/326509.html > > The first one is a fix for an unrelated bug that I noticed while > developing the second one. > > Thanks for reporting this, > > Daniele > > > > > > > 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 > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
