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. Julian Anastasov (2): ipvs: drop first packet to redirect conntrack ipvs: allow rescheduling after RST include/net/ip_vs.h | 17 +++++++++++++++++ net/netfilter/ipvs/ip_vs_core.c | 38 +++++++++++++++++++++++++++++--------- 2 files changed, 46 insertions(+), 9 deletions(-) -- 1.9.3 -- 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
