LVS
lvs-devel
Google
 
Web LinuxVirtualServer.org

Re: [PATCHv2 net-next 0/2] ipvs: drop packet during rescheduling

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: [PATCHv2 net-next 0/2] ipvs: drop packet during rescheduling
Cc: lvs-devel@xxxxxxxxxxxxxxx, Jiri Bohac <jbohac@xxxxxxx>
From: Simon Horman <horms@xxxxxxxxxxxx>
Date: Mon, 7 Mar 2016 11:57:45 +0900
On Sat, Mar 05, 2016 at 03:03:21PM +0200, Julian Anastasov wrote:
> Jiri Bohac is reporting for a problem with the connection
> rescheduling mechanism added in 3.10 when new SYNs in
> connection to dead real server can be redirected to another
> real server. His solution is to drop SYNs until the IPVS
> connection and its conntrack are properly removed, so that
> a new connection can be established later from client's
> retransmissions. Alternative would be to redirect the
> conntrack (its reply direction) to the new real server but
> we do not see such solution.
> 
> The second patch addresses another scenario: client restarts
> TCP connection by reusing the same IPVS connection:
> 
> - IPVS conn is established, eg. FTP without persistence
> - restart client box
> - start new TCP connection from same port to reuse IPVS conn
> C: SYN with new SEQ
> S: ACK with ACK_SEQ=old SEQ
> C: RST SEQ=old SEQ, IPVS conn:EST->CLOSE
> retransmit pause
> C: SYN, still in CLOSE? => DROP, expire IPVS conn
> Expire IPVS connection
> retransmit pause
> C: SYN, create connection
> 
> In this case we should allow rescheduling in CLOSE state.
> In the worst case for this scenario with initial RTO=3 secs
> the client can be delayed for 9 seconds.

Thanks, I have queued these up dropping the previous versions
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

<Prev in Thread] Current Thread [Next in Thread>