F5 301B BIG-IP LTM cheat sheet
F5 301B BIG-IP LTM · Keep the key ideas within reach.
BIG-IP LTM Configuration and Virtual Servers
A standard virtual server binds a destination IP:port (or a wildcard/network route domain address) to exactly one pool plus one or more profiles; the destination listener decides which traffic is captured.
Virtual server types: Standard (IP-based listener), Forwarding (IP) for routing-style forwarding, Performance L4 (fastL4) for stateless packet forwarding, and Stateless for one-way UDP-style flows.
A wildcard virtual server (0.0.0.0:0 or ::.0) acts as a catch-all; its specificity is lower than a host-specific virtual server, and overlapping definitions are resolved by most-specific destination match.
Route domains (partitioned IDs) allow overlapping IP address spaces; an address is written as 10.1.1.1%2 to mean 10.1.1.1 in route domain 2.
A virtual server's source-address translation is controlled by SNAT or Automap; Automap uses the self IP of the egress VLAN, so a missing self IP or VLAN breaks return traffic.
VLAN/listener binding: a virtual server with VLAN enabled and a specific VLAN only accepts traffic arriving on that VLAN; disabled VLANs explicitly exclude it.
Profiles attached to a virtual server are inherited in order of specificity: default profile, then parent profile, then the profile attached to the virtual server; later, more specific settings win.
A virtual server in a non-default partition can reference only objects in its own partition or /Common; cross-partition references require the object to be in /Common.
Profiles and Traffic Processing
Profiles are layered: a custom profile inherits defaults from its parent (for example http derived from tcp), and only explicitly changed settings override the parent.
The TCP profile governs idle timeout, keepalive, and window scaling; the default idle timeout for TCP is 300 seconds, and an idle connection is reset when it expires.
The HTTP profile controls header insertion (X-Forwarded-For), response chunking, server-side keepalive, and the enforcement of RFC-compliant request parsing.
OneConnect (source-IP based) reuses server-side TCP connections to reduce handshakes; it is incompatible with NTLM unless NTLM connection reuse is handled by a dedicated profile.
Client and server SSL profiles are attached separately; the client SSL profile terminates TLS, while the server SSL profile re-encrypts to the pool member.
The HTTP/2 profile requires an HTTP profile and an SSL profile on the same virtual server; HTTP/2 is negotiated via ALPN, and the fallback is HTTP/1.1.
A stream profile performs fixed-size record splitting or content matching on non-HTTP protocols and can be used for rewrites without an iRule.
Persistence, iRules, and profiles all execute in a defined order: profiles first, then iRules, then load-balancing selection and persistence lookup, so an iRule can override a pool choice.
Pools, Nodes, and Load Balancing Methods
Pool members are node:port pairs; a node is the physical/logical server address, and the same node can appear in multiple pools on different ports.
Round Robin distributes connections sequentially; Ratio assigns weights per member; Dynamic Ratio uses a monitor's reported ratio (for example from a real-server or SNMP monitor).
Least Connections selects the member with the fewest active connections; Weighted Least Connections biases by member weight; Observed uses a moving average of past connections.
Fastest selects the member with the lowest measured response time (round-trip), and Predictive estimates future performance from a trend.
Priority groups: members in the highest active priority group receive all traffic; lower-priority members are used only when all higher-priority members are down.
A member's state combines monitor status (up/down/unknown) and admin state (enabled/disabled/forced offline); an admin-disabled member receives no new connections regardless of monitor result.
Pool-level settings include the load-balancing method, health monitors, slow-ramp time, and an optional fallback host for HTTP responses when all members are down.
A node address of 0.0.0.0 or a wildcard member is not valid for standard pools; a default pool on a wildcard virtual server can catch unmatched traffic.
Persistence and Session Management
Source Address Affinity (source_addr) hashes the client IP; its default mask is 255.255.255.255 (host), and a /24 mask groups clients by subnet.
Cookie persistence inserts a BIG-IP cookie (default name BIGipServer) that encodes the selected member; HTTP Cookie persistence reads the client's cookie on subsequent requests.
Destination Address Affinity (dest_addr) keys on the destination IP; it is typically used for outbound or transparent scenarios rather than inbound web traffic.
SSL persistence uses the SSL session ID; it fails when clients renegotiate or when session IDs are not reused, so it is often combined with another method.
SIP persistence keys on the Call-ID in the SIP header and is used for VoIP registrations and call flows.
Universal persistence allows an iRule to compute the key from any data (for example a header or URI) and store it in a persistence table.
Persistence entries have a timeout; the default for source address persistence is 180 seconds (idle), and an entry is removed after the timeout or when the member goes down.
Persistence and load balancing interact: on the first request the load-balancing method picks a member and the persistence record is created; later requests in the timeout window bypass the method.
Monitors and Health Checking
A monitor is bound at node, pool, or member level; the most specific binding wins, and a member-level monitor overrides the pool-level monitor.
Health monitors send probes on the interval and mark a member down after the configured number of failures (default 3), and up after the configured successes (default 3).
Monitor types include ICMP, TCP, TCP Half Open, HTTP, HTTPS, and scripted monitors; an HTTPS monitor can verify the server certificate when configured to do so.
The HTTP monitor succeeds on a 2xx/3xx response by default; a receive string or send string can add content matching, and the receive-disable string inverts the check.
A monitor marked 'transparent' passes the client's source address and does not use the BIG-IP self IP, which matters when servers filter by source.
When all pool members are marked down, the pool's action depends on the 'Action On Service Down' setting: None, Reject, Drop, or Reselect.
A node-level monitor applies to all pool members on that node; a member inherits the pool monitor unless a member-specific monitor is bound.
Monitor status is visible in the member state (up/down/checking); 'unknown' means no monitor result yet, and the member is not used until it is confirmed up.
SSL/TLS Termination and Client Certificate Handling
Client SSL profile = BIG-IP terminates TLS from the client; Server SSL profile = BIG-IP originates TLS to the pool member. Both can be attached to the same virtual server for full proxy.
Certificate and key are referenced by the client SSL profile; a certificate chain must include intermediate CAs, or clients fail with an incomplete-chain error.
Client certificate authentication is enabled by setting 'Client Certificate' to request or require in the client SSL profile; 'require' rejects clients without a certificate.
Certificate Revocation List (CRL) and OCSP stapling can be configured in the client SSL profile to check revocation; CRL must be updated or the check can fail closed.
SNI (Server Name Indication) allows one virtual server to serve multiple certificates; the default SSL profile is used when the client sends no SNI.
TLS versions and ciphers are set in the SSL profile; the default profile allows TLS 1.0-1.2 on older versions, and current practice restricts to TLS 1.2/1.3.
SSL forward proxy (explicit or transparent) intercepts outbound TLS and can inspect traffic using a CA certificate installed on clients.
iRules and Traffic Manipulation
Events fire in order: CLIENT_ACCEPTED, HTTP_REQUEST, LB_SELECTED, HTTP_RESPONSE, HTTP_REQUEST_RELEASE, CLIENT_CLOSED; the event name determines what data is available.
Commands that change routing must run before the connection is established: pool in HTTP_REQUEST or LB_SELECTED overrides the default pool.
persist and persist uie commands create or read persistence records from an iRule; the key can be any string expression.
HTTP::header, HTTP::uri, HTTP::host, and HTTP::path read or rewrite request data; HTTP::redirect issues a 302 and HTTP::respond issues a custom response.
A class with 'class match' performs data-group lookups; matchclass against an address or string class is the standard way to route by source or URI.
The 'when' block and priority argument control ordering when multiple iRules are attached; higher priority runs first, and the default priority is 500.
TCL errors in an iRule are caught per event; an unhandled error aborts that event, and the connection may be dropped, so guard with catch or if checks.
iRules run in the context of the virtual server and can reference only objects visible in the partition; a pool in another partition must be qualified or in /Common.
Troubleshooting and Monitoring LTM Objects
Use tcpdump on the client and server VLANs to confirm where a connection is dropped; a SYN with no SYN-ACK points to the pool member or a routing issue.
The statistics page and 'show sys connection' display active connections; a member showing connections but no responses indicates a server-side problem.
Monitor failures show in the member's monitor status; check the monitor's send/receive strings and the interval/timeout before assuming a network fault.
Virtual server statistics include bits in/out, current connections, and total connections; a zero current-connection count with rising totals indicates short-lived flows.
Logs: /var/log/ltm records configuration and iRule errors; /var/log/audit records configuration changes; /var/log/gtm covers DNS/GTM.
A virtual server with no matching listener (wrong VLAN, wrong port, or address conflict) shows no connection attempts; check the destination and VLAN binding first.
Persistence troubleshooting: 'show ltm persistence persist-records' lists entries; a missing entry means the key changed (cookie stripped, source NAT changed the client IP).
SSL handshake failures are logged with the alert code; a common cause is a missing intermediate certificate or a cipher mismatch between client and profile.