We are in this kind of situation wherein BIG-IP is keeping connections for more than an hour. We found out the reason why BIG-IP is behaving this way is because the server is continuously sending keep-alive packets to BIG-IP and, this is also the reason why TCP timeout is not kicking in.
What we want to achieve here is to remove idle connection which doesn't transmit or send data for a period of time. Is there other timeouts we can utilize like SSL timeout or any settings in SSL or other profiles that can remove or check the existing connection if it's still in use or not?
Or maybe do know some iRule to use in this kind of situation.
SSL termination is done by BIG-IP, the traffic is not HTTP and that is why we are having hard time monitoring the session if there are payload being sent since the start of connection. So basically we just wanted to overwrite the TCP idle timeout session and flush connections that go beyond 30mins since the start of session.
@Nath I haven't had the opportunity to do it but you might be able to monitor the connection and when the F5 sees the keepalive flag come across it can set a timer and then kill the connection after a certain time. I do not believe this is the best use of the F5 because it's unnecessary overhead and is better handled by the server or you can just turn off keepalive if the majority of these connections are just sitting.
Thanks Paulius, I think we will just blindly close the session after 30 mins using an iRule. Since we observed that legit traffic with payload only lasts 4-5 seconds per transaction.
@Nat24 The downside to arbitrarily closing tcp connections based on time open is they could be legitimate connections that you're closing. If you know most users get what they need in 4-5 seconds per transaction I would just turn off keepalive and then you won't have to deal with reaping connections at all.
I don't know, but you want something that looks at throughput and possibly when it slows down or stays the same kills it. Rather than just relying on timealone.
As @Paulius that could cause the users/clients issues up stream. Is there anything the application could do?
