Understanding F5 BIG-IP Local Traffic Manager

F5 BIG-IP Local Traffic Manager (LTM) sits between your users and your application servers. Its job is to decide where each connection should go, keep it going there when it needs to, and make sure it only goes to servers that are healthy. Along the way it can terminate TLS, rewrite traffic and enforce policies.

If you're new to LTM, or you've inherited a configuration someone else built, this article walks through the main building blocks and how they fit together.

LTM is a full proxy

With a standard virtual server, BIG-IP acts as a full proxy. The client opens a connection to BIG-IP, and BIG-IP opens a separate connection to the chosen server. The two sides can use different TCP settings, different TLS versions and even different protocols.

This matters when troubleshooting. A problem can sit on the client side, the server side, or in how BIG-IP connects the two, so it often helps to look at each side separately.

The core objects

Nodes and pool members

A node is an IP address of a backend server. A pool member is a node plus a service port, for example 10.10.30.11:8443. The same node can be a member of several pools on different ports.

Pools

A pool is a group of members that serve the same application. The pool's load balancing method decides which member gets each new connection. Common choices are round robin, least connections and ratio-based methods.

Health monitors

A monitor checks whether each member can actually serve traffic. A simple ICMP or TCP monitor only proves the server is reachable. An HTTP or HTTPS monitor with a send string and an expected receive string proves the application is answering correctly. When a member fails its monitor, BIG-IP stops sending new connections to it.

Virtual servers

A virtual server is the address and port clients connect to, such as 203.0.113.10:443. It ties everything else together: the pool to use, the profiles that shape traffic, persistence, SNAT and any iRules or security policies.

Profiles

Profiles define how BIG-IP handles a type of traffic. A few you will see everywhere:

• TCP profiles tune connection behaviour on the client and server sides.
• HTTP profiles let BIG-IP understand HTTP, which is required for features such as cookie persistence and many iRules.
• Client SSL profiles hold the certificate and key used to terminate TLS from clients.
• Server SSL profiles are used when BIG-IP re-encrypts traffic towards the servers.

Persistence

Persistence (sometimes called stickiness) sends a returning user to the same pool member, which matters for applications that keep session state on a single server. Source address affinity uses the client's IP address. Cookie persistence uses an HTTP cookie and needs an HTTP profile on the virtual server.

SNAT

Source NAT (SNAT) changes the source address of traffic sent to the servers. A very common reason to use it is to make sure server responses come back through BIG-IP. With SNAT Automap, BIG-IP uses one of its own self IP addresses as the source.

iRules

iRules are event-driven scripts, written in a Tcl-based language, that run when certain events happen, such as when an HTTP request arrives. They're powerful for redirects, header changes and custom routing, but every iRule is code someone has to understand and maintain later.

Following a request through LTM

1. A user's browser connects to the virtual server's address on port 443.
2. The client SSL profile terminates TLS using the configured certificate.
3. The HTTP profile parses the request, and any attached iRules or security policies run.
4. If a persistence record exists for this user, BIG-IP uses that pool member. Otherwise the load balancing method picks a healthy member.
5. BIG-IP opens a server-side connection to that member, applying SNAT and a server SSL profile if configured.
6. The response travels back through BIG-IP to the user.

When something goes wrong, asking "which of these steps failed?" is usually the fastest way to the cause.

High availability in brief

Production BIG-IP systems are often deployed in pairs. The devices share configuration through ConfigSync and use failover so that if the active device has a problem, a standby device takes over the traffic. HA has its own concepts, such as device trust, device groups and traffic groups, and deserves careful planning of its own.

Where to go next

This article is general educational material. For version-specific behaviour, defaults and procedures, always refer to F5's official documentation for the BIG-IP version you run.

If you're working through an LTM issue now, our article on common LTM troubleshooting scenarios is a good next read.