Hi,
I am testing below scenario, and I think there is some issue on TCP conntrack
sequence number filter.
Scenario:
VM1->Host1---------Host2-->VM2
There is SCP file copy below VM1 and VM2, and we configured conntrack. During
the scp, I restart the openvswitch service (process stop and start), then after
the restart, I saw the consequence TCP packets are tagged as invalid by
conntrack and traffic can not be recovered.
I did some debug and found it fails on below check “(ackskew >=
-MAXACKWINDOW)”. I am wondering should it be “(ackskew >=
-(MAXACKWINDOW<<sws))”?? I am not sure whether the algorithm is correct or not,
but indeed undesired behavior.
ackskew = dst->seqlo - ack;
#define MAXACKWINDOW (0xffff + 1500) /* 1500 is an arbitrary fudge factor */
if (SEQ_GEQ(src->seqhi, end)
/* Last octet inside other's window space */
&& SEQ_GEQ(seq, src->seqlo - (dst->max_win << dws))
/* Retrans: not more than one window back */
&& (ackskew >= -MAXACKWINDOW)
/* Acking not more than one reassembled fragment backwards */
&& (ackskew <= (MAXACKWINDOW << sws))
/* Acking not more than one window forward */
&& ((tcp_flags & TCP_RST) == 0 || orig_seq == src->seqlo
|| (orig_seq == src->seqlo + 1) || (orig_seq + 1 == src->seqlo))) {
Details:
TCP Client Seq TCP Client ACK TCP Server Seq
TCP Server ACK
Before the restart: 0x69f1536e 0xa3c81999 0xa3ca2d49
0x69f15302
After the restart(5s later): 0x69f15302 0xa3c81999 0xa3c561e1
0x69f15302
As we can see the new seq 0xa3c561e1 (server steped back since previous
segments are not acked.) is much less than 0xa3c81999 (client keeps sending
last acked packet), which leads to failed check on conntrack.
I am using OVS2.7.0+dpdk16.11.3
Any thought?
Br,
Wang Zhike
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
