F5 301B BIG-IP LTM study materials
F5 301B BIG-IP LTM study resources

F5 301B BIG-IP LTM cheat sheet

F5 301B BIG-IP LTM · Keep the key ideas within reach.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.

Quick reference

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.