Hi Wang

Pls see inline

Thanks Darrell

On 1/1/18, 10:57 PM, "ovs-dev-boun...@openvswitch.org on behalf of 王志克" 
<ovs-dev-boun...@openvswitch.org on behalf of wangzh...@jd.com> wrote:

    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 */

[Darrell] The above specific check looks ok to me; also, I am not convinced 
widening the valid skew is a good idea in the general case.

               Btw, what is the sws value in your case ?

    
            && (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.


[Darrell] Did you see any eventual resets ?; followed by conn timeout ?
    
    
    
    I am using OVS2.7.0+dpdk16.11.3
    
    
    
    Any thought?
    
    
    
    Br,
    
    Wang Zhike
    
    _______________________________________________
    dev mailing list
    d...@openvswitch.org
    
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddev&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=BVhFA09CGX7JQ5Ih-uZnsw&m=y-qxAvIT_2KCfecDj8-3VCoLgJ-0NF-mDO_50tx2rcs&s=asIHHvNQJ8KbNdwwo78o7tz9FsckFUAdWziWIsltDxQ&e=
    

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to