[ovs-dev] problem: long tcp session instantiation with conntrack and OOT ovs kmod

Vladislav Odintsov odivlad at gmail.com
Fri Nov 12 14:59:57 UTC 2021


Hi Greg,

thanks for the response.
I’ll be grateful if you can find a time on this.

Thanks.

Regards,
Vladislav Odintsov

> On 4 Nov 2021, at 00:48, Gregory Rose <gvrose8192 at gmail.com> wrote:
> 
> 
> 
> On 11/2/2021 9:50 AM, Vladislav Odintsov wrote:
>> Hi,
>> it’s just a quick reminder, that if you know how to debug/fix this, please let me know.
>> Thanks.
>> Regards,
>> Vladislav Odintsov
> 
> Hi Vladislav,
> 
> I'm very short on time at my day job right now and haven't had a chance
> to consider this issue.
> 
> I'll try to find some time to look at it.
> 
> - Greg
> 
>>> On 11 Oct 2021, at 15:48, Vladislav Odintsov <odivlad at gmail.com> wrote:
>>> 
>>> Hi Greg, Pravin,
>>> 
>>> I was suggested to contact you with my OVS/conntrack/OOT KMOD problem. Could you please look at
>>> this and give any thoughts.
>>> 
>>> Initially I posted this question to OVN dev mail list [1] and it seems that OVN is not involved in my issue.
>>> I was able to reproduce the problem with only OVS and OOT OVS kernel module.
>>> The problem was seen in OVS 2.13, but it reproduces with OVS master branch code too.
>>> 
>>> The problem: long tcp session instantiation.
>>> 
>>> If to follow configuration steps from ovs-conntrack tutorial [2] and run in netns "left" some tcp service
>>> (in my example, httpd), enable sysctl -w net.ipv4.tcp_tw_recycle=1 and run curl from "right" netns to "left"
>>> passing argument --local-port with same source tcp port value, first tcp session would be established
>>> correctly (SYN-SYN/ACK-ACK). If we run curl again with same local port, this tcp session instantiation
>>> will take 1 second to establish because 1st TCP SYN packet will be dropped somewhere in conntrack, because
>>> conntrack record with same tcp source/dest IP/port was existed. After 1st SYN this record got dropped.
>>> Then after 1 second tcp makes a retry which is already successful.
>>> 
>>> tcpdump from originating veth for such scenario looks like this:
>>> 
>>> [root at ovn-1 ~]# tcpdump  -ni veth_r0
>>> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
>>> listening on veth_r0, link-type EN10MB (Ethernet), capture size 262144 bytes
>>> 15:18:53.690544 IP 192.168.0.2.12346 > 192.168.0.1.http: Flags [S], seq 4033940784, win 29200, options [mss 1460,sackOK,TS val 957559592 ecr 0,nop,wscale 7], length 0
>>> 15:18:54.692030 IP 192.168.0.2.12346 > 192.168.0.1.http: Flags [S], seq 4033940784, win 29200, options [mss 1460,sackOK,TS val 957560594 ecr 0,nop,wscale 7], length 0
>>> 15:18:54.692127 IP 192.168.0.1.http > 192.168.0.2.12346: Flags [S.], seq 3684571696, ack 4033940785, win 28960, options [mss 1460,sackOK,TS val 957560594 ecr 957560594,nop,wscale 7], length 0
>>> 15:18:54.692150 IP 192.168.0.2.12346 > 192.168.0.1.http: Flags [.], ack 1, win 229, options [nop,nop,TS val 957560594 ecr 957560594], length 0
>>> 
>>> Conntrack output (while true loop) while this syn-syn-syn/ack is running:
>>> 
>>> [root at ovn-1 ~]# while true; do sleep 0.5; date; grep 192.168.0. /proc/net/nf_conntrack; done
>>> ipv4     2 tcp      6 117 TIME_WAIT src=192.168.0.1 dst=192.168.0.2 sport=80 dport=12345 src=192.168.0.2 dst=192.168.0.1 sport=12345 dport=80 [ASSURED] mark=0 zone=0 use=2
>>> Mon Oct 11 15:46:24 MSK 2021  # <<< -here I ran curl
>>> ipv4     2 tcp      6 117 TIME_WAIT src=192.168.0.1 dst=192.168.0.2 sport=80 dport=12345 src=192.168.0.2 dst=192.168.0.1 sport=12345 dport=80 [ASSURED] mark=0 zone=0 use=2
>>> Mon Oct 11 15:46:25 MSK 2021
>>> Mon Oct 11 15:46:25 MSK 2021
>>> Mon Oct 11 15:46:26 MSK 2021
>>> ipv4     2 tcp      6 119 TIME_WAIT src=192.168.0.1 dst=192.168.0.2 sport=80 dport=12345 src=192.168.0.2 dst=192.168.0.1 sport=12345 dport=80 [ASSURED] mark=0 zone=0 use=2  <<< - retry SYN
>>> Mon Oct 11 15:46:26 MSK 2021
>>> ipv4     2 tcp      6 119 TIME_WAIT src=192.168.0.1 dst=192.168.0.2 sport=80 dport=12345 src=192.168.0.2 dst=192.168.0.1 sport=12345 dport=80 [ASSURED] mark=0 zone=0 use=2
>>> 
>>> 
>>> I would highly appreciate if you can look at this as it’s quite important problem for my installation.
>>> Thanks in advance.
>>> 
>>> 1: https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/387623.html <https://mail.openvswitch.org/pipermail/ovs-dev/2021-September/387623.html>
>>> 2: https://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/ <https://docs.openvswitch.org/en/latest/tutorials/ovs-conntrack/>
>>> 
>>> Regards,
>>> Vladislav Odintsov
>>> 
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev



More information about the dev mailing list