BIG-IP® Local Traffic ManagerTM
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.
Local Traffic Manager is one of several products that constitute the BIG-IP product family.
All products in the BIG-IP product family run on the powerful Traffic Management Operating System, commonly referred to as TMOS®
Once you have set up your base network and you have administrative access
to the BIG-IP system, and at least a default VLAN assignment for each interface, the next step is to configure a network for managing traffic targeted to your internal servers.
At the heart of Local Traffic Manager are virtual servers and load balancing
pools. Virtual servers receive incoming traffic, perform basic source IP and destination IP address translation, and direct traffic to servers, which are grouped together in load balancing pools.
To configure a basic local traffic management system, you use the
Configuration utility. With this utility, you can create a complete set of configuration objects that work together to perform local traffic management. Each object has a set of configuration settings that you can use as is or change to suit your needs.
To configure local traffic objects, you can configure each type of object
individually, or, in some cases, you can use the application templates feature to configure all required objects in a single operation.
Once you have configured local traffic objects on the system, either by
configuring the objects individually or by using the using an application template, you can use the network map to display those objects.
The network map
displays a visual representation of the local traffic configuration that you have implemented, such as virtual servers and their associated pools. The network map also displays statistics about existing virtual servers, pools, nodes, and iRules.
Local Traffic Manager has a number of time-outs that can be set to promote
active connection management. The system manages each load-balanced connection explicitly by keeping track of the 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.
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.
To promote proactive reaping, you can configure several different timeout
settings to tear down connections that have seen no active traffic after a specified period of time. While a few of these timeout settings are not user-configurable, you can actively configure most of these timeout settings, to meet the needs of any application.
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 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.
shows 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.
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). However, if the SNAT automap feature is also enabled, the default 300-second static timeout value still takes effect.
Local Traffic Manager includes two other idle timeout settings, but these
settings do not affect connection reaping. These settings appear in the OneConnectTM
and persistence profile types. Table 1.2
shows the default values for these settings and whether the settings are user-configurable.
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.
The 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.
You can filter the results of the network map feature by using the Type
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.
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
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
, 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
Tip: Browsers have limits as to how much data they can render before they
become sluggish and halt processing. Mapping large configurations might approach those limits; therefore, memory constraints might prevent the system from producing a network map of the whole configuration. If this might happen, the system posts an alert indicating that you can use the Network Map summary screen to determine the complexity of the configuration, which can give you an indication of the size of the resulting map. You can modify the search criteria to return fewer results, producing a map that does not encounter those limits.
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.
, shows an example of a network map screen that summarizes local traffic objects on the system.
For each object type listed in the summary, the system shows the number of
objects with each type of status. Table 1.3
shows the various status indicators that the summary screen can display for a local traffic object.
| || |
| || |
| || |The objects are enabled but are currently unavailable. However, the
objects might become available later, with no user action required.
An example of an object showing this status is a virtual server
whose connection limit has been exceeded. When the number of connections falls below the configured limit, the virtual server becomes available again.
| || |The objects are enabled but offline because an associated object
has marked the object as unavailable. To change the status so that the object can receive traffic, you must actively enable the object.
| || |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
, 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.
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.