Applies To:
Show Versions
BIG-IP LTM
- 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
Introduction to Local Traffic Manager
What is BIG-IP Local Traffic Manager?
BIG-IP® Local Traffic Manager™ controls network traffic that comes into or goes out of a local area network (LAN), including an intranet.
A commonly-used feature of Local Traffic Manager is its ability to intercept and redirect incoming network traffic, for the purpose of intelligently tuning the load on network servers. However, tuning server load is not the only type of local traffic management.
Local Traffic Manager includes a variety of features that perform functions such as inspecting and transforming header and content data, managing SSL certificate-based authentication, and compressing HTTP responses. In so doing, the BIG-IP system not only directs traffic to the appropriate server resource, but also enhances network security and frees up server resources by performing tasks that web servers typically perform.
Timeout settings for connections and sessions
Local Traffic Manager has a number of time-outs that can be set to promote active connection management. The system manages each connection explicitly by keeping track of a connection in the connection table while the connection is still active. The connection table contains state information about client-side and server-side connections, as well as the relationships between them.
Each connection in the connection table consumes system resources to maintain the table entry and monitor connection status. Local Traffic Manager must determine when a connection is no longer active and then retire the connection to avoid exhausting critical system resources. Resources such as memory and processor cycles are at risk if the connection table grows and remains unchecked.
You can also manage the duration of entries in the persistence table when using session persistence.
Connection reaping
Connections that close or reset in a normal way are retired from the connection table automatically. A significant number of connections, however, often remain idle without closing normally, for any number of reasons. Consequently, Local Traffic Manager must reap these connections once they have been determined to be inactive. Reaping is the process of retiring or recycling connections that would otherwise remain idle.
Since you can configure timeout settings in multiple places, it is important to understand that sometimes more than one timeout setting affects the same connection. The optimal timeout configuration is one that retains idle connections for an appropriate amount of time (variable by application) before deciding that the connections are inactive and should be retired, to conserve system resources.
Idle timeout options
Idle connections can be timed out by protocol profiles or SNATs associated with the virtual server handling the connection. Connections that a virtual server does not manage can be timed out based on SNAT automap or VLAN group settings.
The shortest timeout value that applies to a connection is the value that always takes effect. In some cases, however, you might want to change this behavior.
For example, you might have configured a forwarding virtual server that is intended to carry long-standing connections, and these connections might become idle for long periods of time (such as SSH sessions). In this case, you can configure a long idle timeout value on the related protocol profile (in this case, TCP).
Idle timeout settings that affect connection reaping
A list of objects containing idle connection timeout settings that affect reaping. For each object type, the table lists the default value and whether that value is user-configurable.
| Configuration Object Types | Default in Seconds | User-configured? |
|---|---|---|
| Fast L4, Fast HTTP, TCP, and SCTP profiles | 300 | Yes |
| UDP profiles | 60 | Yes |
| SNAT automap | Indefinite | No |
| VLAN group | 300 | No |
Other timeout settings
Local Traffic Manager™ includes two other idle timeout settings, but these settings do not affect connection reaping. These settings appear in the OneConnect™ and persistence profile types.
The OneConnect timeout value controls the length of time that an idle server-side connection is available for re-use; that is, this timeout value might cause the system to close a server-side connection after becoming idle for a certain period of time. In this case, since that connection was never actively in use, no active client-side connections are affected, and the system transparently selects or establishes another server-side connection for new connections. The OneConnect timeout setting need not be coordinated with the idle timeout settings of other profiles.
Persistence timeout settings are actually idle timeout settings for a session, rather than for a single connection. Thus, persistence timeout settings should typically be set to a value slightly larger than the applicable connection idle timeout settings, to allow sessions to continue even if a connection within the session has expired.
Idle timeout settings that do not affect connection reaping
Local Traffic Manager includes two other idle timeout settings, but these settings do not affect connection reaping. These settings appear in the OneConnect™ and persistence profile types. This table shows the default values for these settings and whether the settings are user-configurable.
| Configuration Object Type | Default in Seconds | User-configured? |
|---|---|---|
| OneConnect™ profiles | Disabled | Yes |
| Cookie Hash, Destination Address Affinity, Hash, SIP, Source Address Affinity, and Universal persistence profiles | 180 | Yes |
| MSRDP and SSL persistence profiles | 300 | Yes |
About the network map
The BIG-IP Configuration utility includes a feature known as the network map. The network map shows a summary of local traffic objects, as well as a visual map of the virtual servers, pools, and pool members on the BIG-IP® system. For both the local traffic summary and the network map, you can customize the display using a search mechanism that filters the information that you want to display, according to criteria that you specify. The system highlights in blue all matches from a search operation.
The filtering mechanism
You can filter the results of the network map feature by using the Type and Status lists in the filter bar, as well as a Search box. With the Search box, you can optionally type a specific string. Figure 1.1 shows the filtering options on the Network Map screen.
Filtering options on the Network Map screen
When using the Search box, you can specify a text string that you want the system to use in a search operation. The default is asterisk ( * ). The settings of the Status and Type fields determine the scope of the search. The system uses the specified search string to filter the results that the system displays on the screen.
For example, if you constrain the search to include only unavailable nodes whose IP address includes 10.10, the operation returns those nodes, along with the members of the pool, the pool itself, the associated virtual server, and any iRules® that you explicitly applied to that virtual server. The system sorts results alphabetically, by virtual server name.
The system supports searching on names, IP address, and IP address:port combinations, in both IPv4 and IPv6 address formats. The system processes the string as if an asterisk wildcard character surrounds the string. For example, you specify 10, the system effectively searches as if you had typed *10*. You can also specifically include the asterisk wildcard character. For example, you can use the following search strings: 10.10.10.*:80, 10.10*, and *:80. if you specifically include a wildcard character, the system treats the string accordingly. For example, if you specify 10*, the system assumes you want to search for objects whose IP addresses begin with 10.
Object summary
When you first open the Network Map screen, the screen displays a summary of local traffic objects. This summary includes the type of objects specified with the search mechanism, the number of each type of object, and, for each object type, the number of objects with a given status.
The summary displays data for these object types:
- Virtual servers
- Pools
- Pool members
- Nodes
- iRules
This figure shows an example of a network map screen that summarizes local traffic objects on the system.
Local Traffic summary
The network map display
The network map presents a visual hierarchy of the names and status of virtual servers, pools, pool members, nodes, and iRules® defined on the system. The map shows all objects in context, starting with the virtual servers at the top. The Status, Type, and Search settings at the top of the screen determine the objects that the map includes.
When you position the cursor over an object on the map, the system presents hover text containing information about the object. When you position the cursor over the status icon accompanying an object, the system presents hover text containing information about the object's status, text which also appears on the pool's Properties screen.
The system arranges objects in alphabetic order, and organizes the dependent objects in a hierarchy.
Due to the way that a network map presents objects in context, the updated screen also shows objects of other statuses, types, and names that relate to those objects. This is because a network map always shows objects in context with the objects that depend on them, and the objects they depend on.
For example, if you have an available virtual server with an available pool and two pool members, one available and one offline, then selecting Offline from the Status list causes the system to show the offline pool member in context with the available virtual server and the available pool. This is because the available virtual server and the available pool depend on the offline pool member.
