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

Tue Dec 20 05:25:52 UTC 2016

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 at 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 at 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:sgaddam 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_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
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=