F5 BIG-IP LTM Interview Questions — Full Proxy, SNAT, Answers & Cheat-Sheet

① LTM core objects — the full-proxy hierarchy

F5 interviews open here, and the very first question is usually a trap: “Is LTM just a load balancer?” The winning answer is that BIG-IP LTM is an ADC (Application Delivery Controller) built as a full proxy. It does not forward packets like a router — it terminates the client's connection at the Virtual Server and opens a brand-new connection to the chosen server.

The F5 LTM vocabulary every interview opens with

Know these four cold before anything else — getting the hierarchy right is half the interview. Tap each card.

The object hierarchy is sacred: a Virtual Server (VIP) sends traffic to a Pool, which contains Pool Members, each of which is a Node plus a service port. The crisp line: VIP = IP:port clients hit; Pool = the backend group; Member = Node:Port; Node = bare server IP.

② Load balancing & persistence

Once the VIP terminates the request, LTM has to pick a member. The load-balancing method is set on the pool. The four you must know cold: Round Robin (even rotation), Least Connections (fewest active connections), Ratio (weighted by server size) and Priority Group Activation (tiered failover). Fastest sends to the member with the lowest measured latency.

But load balancing alone breaks stateful apps. Persistence (a.k.a. stickiness) forces every request in a session to the same member. Source-address persistence works for any protocol; Cookie persistence (HTTP only) is the most accurate. There are also SSL, SIP and Universal persistence.

③ Health monitors — knowing UP from DOWN

LTM only load-balances to members it believes are healthy, and health monitors decide that. The ladder of types: ICMP monitor (L3, Node-level), TCP monitor (port open), and HTTP/HTTPS monitor (application-layer). The HTTP monitor is configured with a Send string and a Receive string.

Two timing values matter: Interval (how often to probe) and Timeout — F5's rule of thumb is Timeout ≈ (3×Interval)+1. And know the two modes: out-of-band monitor (active probe, the normal monitors) vs in-band monitor (passive — watches real traffic).

④ Profiles, SNAT, SSL & iRules + troubleshooting

Profiles tune the data path. The TCP profile and HTTP profile let LTM understand the traffic; OneConnect pools and reuses server-side TCP connections so backends aren't hammered. SSL offload uses a Client SSL profile (decrypt at the VIP) and optionally a Server SSL profile (re-encrypt to the server).

SNAT is the most-asked LTM gotcha. SNAT Automap uses a self-IP as the new source; a SNAT pool supplies many addresses for huge connection counts; SNAT none preserves the real client IP. You need SNAT when the pool members' default route is not the BIG-IP.

show ltm virtual vs_web_https_443
show ltm pool pool_web_8080 members
list ltm virtual vs_web_https_443 source-address-translation
show ltm node 172.16.10.11      # node-level status (ICMP monitor)

Ltm::Virtual Server: vs_web_https_443   Availability: available (green)
  Destination 10.20.30.40:443   Pool pool_web_8080
Ltm::Pool: pool_web_8080
  Member 172.16.10.11:8080  State: up    Member 172.16.10.12:8080  State: up
source-address-translation { type automap }

iRules are LTM's superpower — only possible because of the full proxy. They run on HTTP_REQUEST (and many other events) to do content switching, header rewrites and redirects.

Experienced-level deep dive — the questions seniors get asked

Name the Virtual Server types and when you'd pick one over another. The four you must know: Standard — the full-proxy VIP, terminates the client connection and supports profiles, SSL, OneConnect, persistence and L7 iRules (use it for HTTP/HTTPS apps). Performance (Layer 4) / FastL4 — a fast, mostly hardware-accelerated path that does NOT terminate the connection at L7; it forwards L4 flows with minimal processing, so pick it for very high-throughput TCP/UDP where you only need load balancing and don't need SSL offload, cookie persistence or HTTP iRules. Forwarding (IP) — no pool at all; LTM just routes the packet to its destination (an L3 forwarder, e.g. for outbound or transparent paths). Stateless — for high-volume UDP (e.g. DNS, syslog) where LTM doesn't keep a per-connection table. Rule of thumb: need L7 features → Standard; need raw speed at L4 → FastL4; need plain routing → Forwarding.

Explain Action On Service Down (None / Reset / Reselect / Drop). This pool setting decides what happens to existing connections when their member goes DOWN. None (default) leaves established connections alone until they time out — new ones go elsewhere. Reset sends a TCP RST so the client immediately knows to reconnect (fast failover, good for short HTTP). Reselect tries to move the connection to another healthy member without telling the client (works for stateless/idempotent traffic; risky for stateful flows). Drop silently discards the packets, leaving the client to hang until its own timeout. For most web apps Reset gives the cleanest user experience.

What is Priority Group Activation, and how does Slow Ramp bring a recovered member back gracefully? Priority Group Activation tiers members by a priority number; lower-priority members only take traffic when the count of available higher-priority members drops below a minimum you set (active/standby or N+1 failover). Slow Ramp Time solves the opposite problem: when a member that was DOWN comes back UP, Least Connections would dump a flood of new sessions onto it (because it has zero connections) and overwhelm cold caches/JIT. Slow Ramp linearly increases the share of traffic the recovered member receives over the configured window, so it warms up instead of being hammered.

Cookie persistence sub-modes — insert vs rewrite vs passive vs hash, and when cookie persistence can't be used. Insert (default) — BIG-IP adds its own cookie naming the chosen member; needs nothing from the app and is the usual choice. Rewrite — the app sends a blank/placeholder cookie that BIG-IP overwrites with the persistence value (app cooperates, but BIG-IP supplies the value). Passive — BIG-IP does NOT set or change the cookie; it only reads a cookie the application already sets (the app must encode the member). Hash — BIG-IP hashes an existing application cookie's value to map to a member, useful when you can't insert. Cookie persistence is HTTP-only and breaks if the traffic is non-HTTP, if it's encrypted end-to-end without an HTTP profile (no SSL termination to read/insert the cookie), or if the client refuses cookies — then fall back to source-address or universal persistence.

After enabling SNAT the backend logs show the self IP, not the client IP — how do you preserve the real client IP? SNAT replaces the client source with a BIG-IP self-IP, so servers logging the source now see the proxy. Because LTM is a full proxy parsing HTTP, the fix is to insert an X-Forwarded-For header carrying the original client IP — turn on Insert X-Forwarded-For in the HTTP profile (or write an iRule that sets the header), then configure the web/app server to log X-Forwarded-For instead of the TCP source. (For non-HTTP traffic you'd preserve the client IP another way — e.g. SNAT none with the BIG-IP as the gateway.)

iRule events in order, with real code. An iRule is a TCL script bound to the VIP that fires on data-path events: CLIENT_ACCEPTED (client TCP established), HTTP_REQUEST (full client request parsed — before the LB decision, ideal for content switching), LB_SELECTED (a pool member has just been chosen), SERVER_CONNECTED (server-side TCP up) and HTTP_RESPONSE (server reply parsed). A common content-switching example:

when HTTP_REQUEST {
    # route /api to the API pool, everything else to the web pool
    if { [HTTP::uri] starts_with "/api" } {
        pool pool_api_8443
    } else {
        pool pool_web_8080
    }
    # preserve the real client IP for the backend logs
    HTTP::header insert X-Forwarded-For [IP::client_addr]
}
when LB_SELECTED {
    log local0. "client [IP::client_addr] -> member [LB::server addr]"
}

iRules vs LTM Policies — which and why. LTM Policies are a GUI-driven, rule-based way to do the common 80% (URI/host matching, pool selection, redirects, header insert) with no code — easier to audit, version and hand off. iRules give the full TCL programmability for the complex 20% (custom logic, data-group lookups, multi-event state). Prefer a Policy when a Policy can express it; reach for an iRule only when you need real logic.

What does CMP-compatible mean, and how can a bad iRule demote a VS? CMP (Clustered Multiprocessing) lets BIG-IP fan a VIP's connections across every TMM/CPU. An iRule that uses a global/serialized construct (certain table/session operations, some after/global-variable patterns) is CMP-incompatible; binding it forces that VS to run on a single TMM — it gets demoted, throughput drops, and tmsh show ltm virtual reports a CMP status of single. The fix: rewrite the iRule to avoid the serializing call, or move logic to an LTM Policy.