Forum Discussion
NimbostratusSend message before connection close on idle timeout
I think I could use TCP::respond as a command for sending this message to client, but I don't know how to trigger event when Big IP detects idle timeout, but before it closes the connection. I found a CLIENT_CLOSED event in the Wiki, but it seems that it is triggered after closing connection and then it's too late to send the message.
Is there any way to do it just before closing?
If nothing better is found, I can disable the idle timeout, but I wouldn't really like to do it.
- There really is no way to do that, since (as you mention) there is no iRule trigger when the connection is reaped.
Disabling idle timeout is not recommended. If no timeout is enforced, then there is no mechanism for clearing out stale entries from the connection table, and over time, the table will grow too large for LTM to handle and force a failover/restart. The connection table is cleared on failover/restart, so the condition would be alleviated temporarily, but at the expense of losing all existing connections. (Took a long time to track this one down the first time I encountered it -- just looked like random restarts until we found an idle timer for ssh sessions to backend servers was set to 0.)
/deb 
Tomasz_RadziszeThank you. In the meantime I discovered that most of my cases of connection closing were due to error in iRule, not due to idle timeout. So I'll set a long timeout (there won't be many connections using this profile).
brad_11480I know this thread is very (very) old. I have some questions about behavior of the TCP idle timeout.
If the TCP connection is idle beyond the setting (default 300 seconds), the connection is dropped from the F5, right?
When this is dropped is there any iRule triggered? In Particular is the CLIENT_CLOSED triggered?
I'm trying to understand if connections are being dropped due to being idle and I've set a couple iRule monitors. Interesting as sometimes the counter goes just above the 300 and then the CLIENT_CLOSED seems to have triggered.. yet other times it does not and it continues to clock.
thanks.
- Kevin_Stewart
Employee
The CLIENT_CLOSED event should be triggered when the TCP session is closed. Generally speaking though, there's no way to be exact about this timing given the nature of networking and client-server communications.
- brad_11480
great. so you are saying that it will be triggered when the session is closed due to a TCP idle timeout on the F5 as well.
If so, is it possible to find out that the reason was due to the idle timeout? If so, what can be checked to determine this is the reason?!
(My objective here is to be able to monitor/log connections where the F5 is droppping them due to the TCP idle timeout.. If there is a better method to do this, I certainly would appreciate the solution!)
Thanks all!
