For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Mat_126116's avatar
Mat_126116
Icon for Nimbostratus rankNimbostratus
Nov 07, 2014

F5 is not flushing expired TCP connections

Hi All,   Last days I noticed that due to unknown factor BigIP F5 load balancer is not flushing expired TCP connections on one VIP. Connections stuck in CLOSE-WAIT/LAST-ACK and FIN-WAIT/CLOSING st...
application delivery
LTM
Mat_126116's avatar
Mat_126116
Icon for Nimbostratus rankNimbostratus
Jan 07, 2015

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.

 

melcaniac's avatar
melcaniac
Icon for Cirrus rankCirrus
Jun 23, 2016
We 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.