|
Hello,
On Mon, 7 Apr 2008, Siim Põder wrote:
> I have a server behind LVS-NAT that sends all it's data quite fast
> followed by a FIN. after that, it retransmits lost packets as needed.
> the problem is, that for some reason, the connection-terminating FIN
> (with the last ACK) from CLIENT isn't delivered to the RS (in some
> cases), which keeps on sending the last packet until it gives up.
Server sends FIN, IPVS switches to FIN_WAIT (2 minutes):
> 13:34:21 1.2.3.4.8888 > 4.3.2.1.9876: FP 63382:64463(1081) ack 323
2 minutes passed:
> 13:35:25 4.3.2.1.9876 > 1.2.3.4.8888: . ack 15862
> 13:35:25 1.2.3.4.8888 > 4.3.2.1.9876: . 15862:17302(1440) ack 323
> 13:35:25 4.3.2.1.9876 > 1.2.3.4.8888: . ack 17302
> 13:35:25 1.2.3.4.8888 > 4.3.2.1.9876: . 17302:18742(1440) ack 323
> 13:37:25 4.3.2.1.9876 > 1.2.3.4.8888: F 323:323(0) ack 17302
> 13:37:28 4.3.2.1.9876 > 1.2.3.4.8888: F 323:323(0) ack 17302
> 13:37:33 4.3.2.1.9876 > 1.2.3.4.8888: F 323:323(0) ack 17302
> I'm not entirely sure if I was able to read the said information fast
> enough (lots of connections, big tables) but it seems that at that time
> ipvsadm -L --connection shows that connection in "FIN_WAIT" while
> /proc/net/ip_conntrack does not have an entry for it at all.
Hm, you can try to increase FIN_WAIT timeout in Netfilter.
IPVS extends its timeout with 2mins on every packet and as you see
IPVS connection is still present. May be you can play with following
parameters in /proc/sys/net/netfilter/:
nf_conntrack_tcp_max_retrans
nf_conntrack_tcp_timeout_fin_wait
I'm not expert for Netfilter timeouts, the idea is to
increase FIN_WAIT timeout. You can do the same for IPVS timeouts,
see ipvsadm --set.
> Alltogether, a few percent of connections is affected by this. My
> interpetation is, that for some reason LVS code seems to remove the
> conntrack immediately when a final FIN is seen and stops forwarding
... or Netfilter removes its connection after strictly
expiring timer after 2 mins in FIN_WAIT.
Regards
--
Julian Anastasov <ja@xxxxxx>
|
