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

Wed Dec 21 07:23:13 UTC 2016

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 <diproiettod at ovn.org>
wrote:

> 2016-12-19 21:25 GMT-08:00 Darrell Ball <dball at vmware.com>:
> >
> >
> > From: Jarno Rajahalme <jarno at ovn.org>
> > Date: Monday, December 19, 2016 at 2:30 PM
> > To: Darrell Ball <dball at vmware.com>
> > Cc: Sridhar Gaddam <sgaddam at redhat.com>, "ovs-dev at openvswitch.org" <
> ovs-dev at openvswitch.org>, 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 <dball at vmware.com<mailto:dball
> @vmware.com>> wrote:
> >
> >
> >
> > On 12/16/16, 1:25 PM, "ovs-dev-bounces at openvswitch.org<mailto:
> ovs-dev-bounces at openvswitch.org> on behalf of Jarno Rajahalme" <
> ovs-dev-bounces at openvswitch.org<mailto:ovs-dev-bounces at openvswitch.org>
> on behalf of jarno at ovn.org<mailto:jarno at ovn.org>> wrote:
> >
> >
> >
> > On Dec 16, 2016, at 9:12 AM, Sridhar Gaddam <sgaddam at redhat.com<mailto:
> sgaddam at redhat.com>> wrote:
> >
> >
> >
> >
> > On Tue, Dec 13, 2016 at 1:12 PM, Daniele Di Proietto <
> diproiettod at ovn.org<mailto:diproiettod at ovn.org>>
> > wrote:
> >
> >
> > 2016-12-12 3:21 GMT-08:00 Sridhar Gaddam <sgaddam at redhat.com<mailto:sga
> ddam 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://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
> > dev at openvswitch.org<mailto:dev at openvswitch.org>
> > 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
> > dev at openvswitch.org<mailto:dev at openvswitch.org>
> > 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
> >    dev at openvswitch.org<mailto:dev at openvswitch.org>
> >    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
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>