On Fri, 1 May 2020, Abhijeet Rastogi wrote:
> Hi everyone,
> Considering that IPVS is in DR mode with persistence disabled completely
> and the client and real servers are configured to handle long-lived HTTP
> connections (>15min). I understand that the default TCP timeout is 15min
> but t I'm confused about the impact of this timeout on already active
> established connections even when the timer value hits.
Note that these timeouts are for inactivity, not a time from
> For eg, with default value 15min, will the existing connection be simply
> dropped or do we keep the connection table for that 5-tuple intact?
The IPVS structure (IPVS connection) that holds the tuple is
freed 15mins after the last packet is transferred, no packets are sent to
abort the TCP connection after this period. But following packets may get
RST due to the missing IPVS connection. ipvsadm has option to tune this
> - If the connection is simply dropped, are there any signals to look for
> in terms of finding out how widespread it is?
No, we do not have stat/counter for expiration in established
> - If we keep the connection table entry, what's the new policy on this
> existing connection? (Note: persistence is disabled, as I'm aware that
> there's a 60s timer which reactivates the connection template)
> - If this is true, should we keep TCP timeouts on production servers
> lesser than 15min to ensure we're protected in terms of some
> sort of abuse?
DR can be abused, while for NAT we can change the state based on
packets from real server. But it depends on the balanced application.
HTTP usually is not idle for 15mins, ssh apps can use TCP-keepalive to
protect from firewalls dropping the NAT connections. So, it is up to
you to decide what idle period you can tolerate for your application.
IPVS also has sysctl vars that can release IPVS structures on memory
Another option is to use source-based hashing (eg. MH, SH
schedulers) and sloppy mode: echo 1 > sloppy_tcp
It allows creating IPVS connections from non-SYN packets. So, even if
IPVS connection is expired, it can be re-created to the same real
Julian Anastasov <ja@xxxxxx>
Please read the documentation before posting - it's available at:
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users