On 11 Oct 2021, at 15:48, Vladislav Odintsov <[email protected]> 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@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@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
