|
On Sun, Feb 07, 2016 at 01:07:30PM +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, applied.
--
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
|
