Application does not send final RST when closing idle timeout

Products

• CA Directory

Issue/Introduction

You may be dealing with a ongoing issue were you are hitting the hard capped open files limit.

Although this is essentially caused by a application sending excessive queries, yoy noticed whilst doing network troubleshooting, Symantec Directory does close idle timeouts but does not send the final RST. As a result, the VIP is required to send the final RST to client and server, this east up connection pools on the F5 VIP and causes the client to open even more connections.

Is this by design?

Environment

Release : 14.1

Resolution

The short answer is yes, this is by design.

From Symantec Directory side, the FIN being sent (not RST) using call to close socket seems to be right from Directory perspective and you need to update the F5 LB configuration to reduce FIN_WAIT_2_TIMEOUT as documented in F5 KB.

Reference:
https://my.f5.com/manage/s/article/K39702017

Looks like default is 300 secs, which corresponds to 5 mins delay of RST from FIN as you may see in your network packet capture.

Further... 

See https://datatracker.ietf.org/doc/html/rfc793 (section 3.2 Terminology and the flow chart).

The FIN packet is sent and the system waits for some time to receive the FIN reply. After the wait times out, the socket is closed by the system (kernel) and no RST is sent since a FIN has already been sent.
If the client (i.e. application) tries to communicate after the socket is closed, then the client system would receive a TCP RST response. In general, the client may not "know" that the socket has been closed until it tries to use it again.

The correct fix for this situation is to reduce the F5 FIN-WAIT-2 timeout from the default of 5 minutes to the desired value. The F5 will send TCP RST to *BOTH* sides of the conversation - both the client and server - after the F5 timeout expires.

For an example, the default is 300 secs, which corresponds to 5 mins delay of RST from FIN as you may see in your network packet capture. Try to set the 'FIN_WAIT_2_TIMEOUT' to a lower value (e.g. 30 seconds) and see how it behaves. This will be a trial and error method so keep adjusting the value until you find a sweet spot.