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 <[email protected]> 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 <[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 >>> > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
