LTM: Dueling Timeouts

LTM has a number of timeouts that can be set to promote active connection management. This article provides a high level explanation of LTM timeout options and a few guidelines on configuring them appropriately.

LTM Connection Management Overview

LTM manages each load balanced connection explicitly by keeping track of it in the connection table while it is active. The connection table contains state information about clientside flows and serverside flows, the relationships between them, and the last time traffic was seen on each.

Each connection in the connection table consumes system resources maintaining the table entry and monitoring the connection’s status. LTM (like any other IP system) must determine when a connection is no longer active and retire it in order to avoid exhaustion of critical system resources which are at risk if the connection table grows unchecked. For instance, excessive memory and processor cycles may be consumed managing the table itself, and ephemeral ports required for the LTM end of serverside flows may be exhausted if they are not recycled.

LTM Connection Reaping

Connections that close normally (4-way close) or are reset by either side are retired from the connection table automatically. A significant number of connections often go idle without closing normally for any number of reasons.  These connections must be "reaped" by the system once they have been determined to be inactive. 

In order to promote proactive connection retirement or recycling (also known as "reaping"), several different timeouts may be configured in LTM to tear down connections that have seen no active traffic after a specified period of time.  Most of these timeouts are configurable to meet the needs of any application.  Some are not.

Since you can set timeouts in multiple places, it’s important to understand that sometimes more than one timeout will affect the same connection. The optimal timeout configuration is one that retains idle connections for an appropriate amount of time (which of course will vary by application) before deciding they are inactive and retiring them to conserve system resources.

LTM Timeout Options

LTM connections may be timed out by protocol profiles or SNATs associated with the virtual server handling the connection. Connections not handled by a virtual server may be timed out based on SNAT automap or VLAN group settings.

Here is a list of the possible LTM connection timeouts, their default values, and whether that value is configurable:

 Option  Default in 
 Protocol profiles (tcp, fastHTTP, or fastL4)300Y
 Protocol profile (udp)60Y
 SNAT / SNATpool300Y
 SNAT automap300N
 VLAN group300N

The shortest timeout that applies to a connection will always take effect.  In some cases, that's not desirable.  For example, when configuring a forwarding virtual server that's intended to carry long-standing connections that may go idle for long periods of time (such as SSH sessions), you can configure a long idle timeout on the related protocol profile (tcp in this case), but the 300 second static timeout will still take effect if SNAT automap is also enabled. You may be able to avoid the non-configurable global SNAT automap timeout  by creating and applying a similar but more specific object with a configurable timeout (SNAT or SNATpool) as detailed in SOL6017 (see below for link.)

Other LTM Timeouts

There are a couple of other timeouts that can be configured in LTM that do NOT cause connections to be reaped: OneConnect and persistence.

The OneConnect timeout controls only how long an idle serverside flow will be available for re-use, and may cause a serverside connection to be closed after it goes idle for a time. Since that connection will never have been actively in use, no active clientside connections will be affected, and a new serverside flow will transparently be selected or established for new connections. OneConnect timeout settings need not be coordinated with other idle timeouts.

Persistence timeouts are actually idle timeouts for a session, rather than a single connection.  With that in mind, persistence timeouts should typically be set to a value slightly larger than the applicable connection idle timeouts to allow sessions to continue even if a connection within it is timed out.

More Information About LTM Timeouts

SOL7606: Overview of BIG-IP LTM idle session timeouts

SOL1638: Reasons why all SNATs do not use the global TCP idle timeout for SNATs

SOL5401: Idle connections may be allowed to exist after the idle timeout expires

SOL6017: BIG-IP LTM SNAT automap has a static timeout value of 300 seconds
(Please disregard the note in this solution indicating that SNAT automap timeout does not affect VS-handled connections.  The information in SOL7606 above is more current and accurate.  A correction has been requested.)

Get the Flash Player to see this player.
Published Apr 15, 2008
Version 1.0

Was this article helpful?


  • Thank you Deb for this article ! Supposing that we have 3 timeouts configured on a VS : > TCP Idle Time : 1800 seconds > Source Address Persistence Timeout : 1200 seconds > SNAT Automap Timeout : 300 seconds 1) What happens if the SNAT timeout is achieved ? The BIG-IP just deletes the entry from its SNAT table or send something to the client/pool member... 2) Same question, what happens if the persistence timeout is achieved ? Does F5 send something to the client/pool member or just delete the entry from the Persistence records... Another question that comes in mind, if the same source address initiates a new session, F5 calculates and add a new record into the persistence table. Is it possible that the traffic goes to a pool member other than the one chosed during the previous session ? 3) Finally, if TCP Idle Time is achieved, I believe that F5 sends a RST to the client. Is there anything else sent from the F5, for example to the pool member...? Thanks for the help
  • Joad's avatar
    Icon for Nimbostratus rankNimbostratus

    Hi, I've read this:



    If the connection matches a virtual server and automap SNAT object, the system uses the idle timeout specified in the protocol profile. For more information about idle session timeouts, refer to K7606: Overview of BIG-IP LTM idle session timeouts.


    and then the K7606 mentioned above:



    With the idle timeout set to Indefinite, the BIG-IP system internally limits UDP and IP SNAT translation idle timeout periods to a maximum of 300 seconds.


    So, who win if I've an UDP VS configured with UDP profile set to 900 sec.(timeout of course) and SNAT automap ?


    Thank you