> On Dec 19, 2016, at 1:29 PM, Darrell Ball <[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]>
>> 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://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=
>>>>  
>>>> <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

> 
>   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=
>>  
>> <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=
>>>>  
>>>> <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=
>>  
>> <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=
>  
> <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

Reply via email to