Forum Discussion
Yes, we finally found the root cause toghether with F5 support but it was not entirely related to F5 configuration.
We took packet captures and found that the pool member is sending fin/ack again and again for every 120 secs on same TCP connection stream.
It seems F5 was in FIN/WAIT-2. FIN/WAIT-2 state are handled by the Idle Timeout setting (300 secs). F5 should have sent fin/ack to the client and go the fin/wait2 state.
The fin/ack from the pool member, reset the counter at F5 TCP idle-time out and the connection is never removed from F5 connection table.
There is no need for the pool member to retransmit the fin/ack every 120 secs, since pool member already received the ack from F5 for the fin/ack.
Resolution: We create a new tcp profile with idle timeout of 110 secs. It seems that it fixed the connection table growth.
- melcaniacJun 23, 2016CirrusWe had a similar problem, where the application was not properly closing TCP connections due to memory issues. In response to the FIN packets sent by the F5, the application server sent back TCP Window Full responses (the window size was already down to 34) and was holding the connection open with ZeroWindowProbes every 60 seconds which would the ACKed by the F5. Eventually this filled up the available ephemeral ports on the server and the F5 was blamed. Even though we proved this was a memory issue with the application, we were able to remediate the issue by using a TCP profile with an Idle Timeout of 55 seconds.