We've been having a weird issue, so we have a test system using F5 which appears to have a 60 seconds delay closing the connection.
TCPDUMP shows a normal traffic from client to the server and back to the client (which all happens within seconds), however when the client gets back the response data (HTTP 1.1 200) and sends an ACK to the F5 (which then it passes on to the server). Then it just waits there for a good 60 seconds before the server finally sends a FIN ( I believe this is due to the TCP FIN timeout value on linux which is by default 60 seconds )
Here's the weird part:
Our vendor tested with Apache, and the 60 seconds delay does not happen. After sending ACK, the client immediately follows with a FIN flag which then close the connection properly.
Now we can't really say the code is bad on the vendor side since their argument is on apache it's working as intended (they code the application both on client and the server), so they're blaming it on the F5
Is there anything I can do from the F5 side?
Check the TCP flags on the connection setup between the client and the F5 vs the client and the Apache. It may be possible the F5 is offering a persistence option which the Apache server is not. That's where I would look.
That's what we suspected too, however I couldn't find any persistence option in any of our tcpdump (or perhaps I'm not looking in the right direction)
Would you be able to point where exactly I can find this in the dump file?