F5 BIG-IP LTM Interview Questions and Answers (2026)

Most engineers think…

Most candidates open with “F5 LTM? It's just a load balancer — a packet-based box like a router” — and the interview quietly ends there.

That single sentence fails you. LTM is a FULL PROXY: it terminates the client connection at the Virtual Server and opens a brand-new connection to the server. That termination is exactly what enables SSL offload, OneConnect connection reuse and L7 iRules — none of which a packet-forwarding router can do. This lesson trains the framing that gets you hired.

① 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.

Figure 1 — LTM is a FULL PROXY, not a router

There is one client-side connection and a totally separate server-side connection. The VIP owns the destination IP:port; the Pool is the group of backends; a Member is a Node plus a service port; a Node is just the server IP. That hierarchy is the first thing every F5 interviewer checks.

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.

🎯

Virtual Server

tap to flip

The VIP — an IP:port clients connect to (e.g. 10.20.30.40:443). It terminates the client connection and applies profiles, persistence and the LB decision.

👥

Pool

tap to flip

A group of pool members that serve one application. The Virtual Server's Default Pool; the LB method and health monitor live here.

🖧

Pool Member

tap to flip

Node + service port — e.g. 172.16.10.11:8080. The actual load-balancing target. The same Node can be a member in several pools on different ports.

📍

Node

tap to flip

Just the server IP — 172.16.10.11, no port. ICMP monitors and Node-level disable/force-offline act here; one Node can back many members.

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.

Quick check · Q1 of 10 · Remember

In the F5 LTM object model, what is the difference between a Node and a Pool Member?

a) They are the same thingb) A Node is the server IP only; a Pool Member is that Node plus a service port (Node:Port)c) A Node is the Virtual Server; a Pool Member is the clientd) A Node is a pool of pools

Correct: b. A Node is just the server's IP address (e.g. 172.16.10.11). A Pool Member adds the service port (172.16.10.11:8080) — so the same Node can be a member in several pools on different ports. ICMP monitors act on the Node; TCP/HTTP monitors act on the Member.

👉 So far: LTM is a full-proxy ADC, not a router: it terminates the client connection at the Virtual Server and opens a NEW one to a Pool Member. Hierarchy: Virtual Server (VIP) → Pool → Member (Node:Port) → Node (IP).

The 'LTM is just a load balancer' trap

Answer firmly: it's a full proxy ADC. Because it terminates the client connection and opens a separate server-side connection, it can decrypt and re-encrypt (SSL offload), reuse server TCP connections (OneConnect), and rewrite L7 with iRules. A packet-based router can do none of those — that termination is the whole point.

② 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.

▶ Watch one request cross the full proxy

How a single HTTPS request is terminated, decided, pinned, SNATed and sent to a pool member on a brand-new connection. Press Play for the healthy path, then Break it to see the failure.

① Client-side terminateClient completes TCP to the VIP; the Client-SSL profile decrypts the HTTPS request (SSL offload).

▼

② Profiles + persistenceTCP/HTTP/OneConnect profiles parse it; LTM checks the persistence table for an existing session.

▼

③ Load-balance + SNATNo session yet, so the LB method picks a healthy member; SNAT Automap rewrites the source IP.

▼

④ Server-side connectionLTM opens a NEW TCP to the chosen Pool Member (Node:Port) and records the persistence record for next time.

Press Play to step through the healthy path. Then press Break it.

Figure 2 — A request through the Virtual Server — recite this order

Two facts interviewers love: persistence is checked BEFORE the load-balancing method (a pinned session skips LB entirely), and because LTM is a full proxy the server-side connection is brand-new — that is exactly why SNAT and OneConnect even exist.

COLOUR KEYdown / blockedclient-side / VIPdecision / SSL pointhealthy member / allowed

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.

Quick check · Q2 of 10 · Apply

An Indian e-commerce app at Flipkart keeps logging users out: a user's shopping cart works for a minute, then empties. Each request is landing on a different backend that doesn't share session state. What's missing on the pool/VIP?

a) Persistence (e.g. cookie or source-address) so a session sticks to one memberb) A faster load-balancing methodc) A second Virtual Serverd) SSL offload

Correct: a. The session state lives only on the member that created it. Without persistence, Round Robin spreads each request to a different member and the cart is lost. Enable cookie persistence (best for HTTP) or source-address persistence so the whole session sticks to one member.

Pause & Predict

Why is source-address persistence risky when users sit behind a single corporate proxy or NAT? Type your guess.

Answer: Because every user then shares ONE source IP, so source-address persistence pins them ALL to the same pool member — load balancing collapses onto one server. For HTTP traffic, cookie persistence is more accurate because it pins per-browser, not per-IP. That's the classic reason interviewers ask 'cookie vs source-address'.

Sneha at Infosys faces this

A new internal HR portal loses the user's session every few clicks; logs show requests spread across all three members.

Likely cause

No persistence is configured, so each request is load-balanced to a different member and the session (held in server memory) is lost.

Diagnosis

Check the pool's persistence profile; watch the persistence records table while reproducing — if no record is created, persistence isn't applied to the VIP.

Local Traffic ▸ Virtual Servers ▸ (VIP) ▸ Resources ▸ Default Persistence Profile

Fix

Attach a cookie persistence profile (HTTP app) to the VIP, or source-address if it's non-HTTP; verify a persistence record now binds the client to one member.

Verify

Reproduce the journey — the cart/session now survives; the persistence table shows one client → one member.

👉 So far: LB methods live on the pool: Round Robin (even), Least Connections (fewest active), Ratio (weighted), Priority Group Activation (failover). Persistence pins a session to one member — cookie (HTTP, accurate) vs source-address (any protocol, breaks behind shared NAT). Stateful apps REQUIRE 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.

🖥️ This is the screen you build a VIP in — Local Traffic ▸ Virtual Servers ▸ Virtual Server List ▸ Create in the BIG-IP Configuration utility. Fields ①②③ decide who the VIP serves and how traffic leaves it.

https://bigip-mgmt.corp.local · Local Traffic ▸ Virtual Servers ▸ Create

Name *

vs_web_https_443

Type

Standard

Destination Address/Mask *

10.20.30.40 / 255.255.255.255

Service Port *

443 (HTTPS)

HTTP Profile (Client)

http

SSL Profile (Client)

clientssl

Source Address Translation

Auto Map

Default Pool

pool_web_8080

Finished Cancel

① Source Address Translation = Auto Map rewrites the client source to a BIG-IP self-IP so the server's reply returns to the BIG-IP — set this when the pool members' default route is NOT the BIG-IP. ② Default Pool binds this VIP to the backend group; with no pool (and no iRule) the VIP has nowhere to send traffic. ③ Attaching a Client SSL profile is what performs SSL offload — without it the VIP can't decrypt HTTPS.

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).

Pause & Predict

A member answers ping and even accepts a TCP connection on port 8080, but the app behind it returns HTTP 500 for every request. Will a plain ICMP or TCP monitor catch this — and which monitor will? Type your guess.

Answer: No. ICMP only proves the server is reachable at L3, and a TCP monitor only proves the port is listening — both will keep the member UP while the app is broken. You need an HTTP monitor with a Receive string (e.g. expecting '200 OK' or 'HEALTHY'); the 500 response won't match, so LTM correctly marks the member DOWN. Always health-check at the application layer for app traffic.

Quick check · Q3 of 10 · Analyze

A member is marked DOWN. You can ping the Node and you can telnet to its service port successfully, but the HTTP monitor still fails. What's the most likely cause?

a) The Node is unreachable at L3b) The service port is closedc) The HTTP monitor's Send/Receive string doesn't match what the app returns (or the health URL is wrong)d) ICMP is disabled on the BIG-IP

Correct: c. ICMP up + TCP port up means L3 and the listener are fine. The failure is at the application layer: the monitor's Send string hits the wrong URL, or the app's reply doesn't contain the expected Receive string (wrong path, redirect, auth page, or 500). Fix the Send/Receive string to match a real healthy response.

Rahul at HCL faces this

After a deploy, one member at an Indian bank flaps UP/DOWN every interval even though the app team swears the server is fine.

Likely cause

The HTTP monitor's Receive string no longer matches — the health endpoint moved or now redirects (302) — or Timeout is too tight relative to Interval, so a slow reply trips it.

Diagnosis

Manually run the Send string against the member (curl the health URL); compare the actual reply to the configured Receive string; check Interval/Timeout ratio.

Local Traffic ▸ Monitors ▸ (http monitor) ▸ Send/Receive String + Interval/Timeout

Fix

Point the Send string at the correct health URL, set the Receive string to text that always appears in a healthy reply, and set Timeout ≈ (3×Interval)+1 so transient latency doesn't flap it.

Verify

Watch the member status hold UP across several intervals; the monitor logs show consistent matches.

ICMP-only monitoring over-confidence

A green ICMP (or even TCP) monitor only proves the box is reachable or the port is open — it says nothing about whether the application works. For web apps always use an HTTP/HTTPS monitor with a real Send/Receive string, so a 500 or a wrong page marks the member DOWN instead of silently serving errors to users.

👉 So far: Monitors: ICMP (Node, L3) → TCP (port listening) → HTTP/HTTPS (Send/Receive string = true app health). Timeout ≈ (3×Interval)+1. Out-of-band = active probe (normal monitors); in-band = passive, watches real traffic. A member DOWN that pings + accepts TCP = a Send/Receive mismatch.

④ 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).

Figure 3 — Full proxy (LTM) vs packet-based half-proxy (a router)

The one-liner that wins: a router forwards packets; LTM is a full proxy that ends the client's conversation and starts a fresh one with the server — that termination is what makes SSL offload, OneConnect and L7 iRules possible.

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.

Pause & Predict

Your VIP and pool look perfect, monitors are green, but clients get NO response. The servers' default gateway points at the core switch, not the BIG-IP. What single setting fixes it, and why? Type your guess.

Answer: Enable SNAT (Automap) on the Virtual Server. Because LTM is a full proxy, the server's reply must come back to the BIG-IP to be returned to the client. If the server's default route isn't the BIG-IP, it sends the reply straight out via the core switch (asymmetric routing) and the connection breaks. SNAT Automap rewrites the source to a BIG-IP self-IP, so the server always replies to the BIG-IP. The alternative is to make the BIG-IP the server's default gateway.

Arjun at Wipro faces this

A newly built VIP at TCS shows all members green, but external users get a blank page / connection reset; a packet capture shows the server replying straight to the client, not the BIG-IP.

Likely cause

Asymmetric return: the pool members' default route is the core switch, not the BIG-IP, so replies bypass the full proxy and the client's TCP stack drops them.

Diagnosis

tcpdump on the BIG-IP shows the request leaving to the member but no reply returning; the server's route table shows a non-BIG-IP gateway.

Local Traffic ▸ Virtual Servers ▸ (VIP) ▸ Source Address Translation = Auto Map

Fix

Set Source Address Translation to Auto Map (or a SNAT pool for very high connection counts) so the source becomes a BIG-IP self-IP and replies return to the proxy — or make the BIG-IP the servers' default gateway.

Verify

Re-test — the page loads; tcpdump now shows the reply returning to the BIG-IP self-IP and back to the client.

Confirm the VIP, pool, members and SNAT from tmsh

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)

Expected output

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.

Quick check · Q4 of 10 · Apply

When do you specifically NEED to enable SNAT on a Virtual Server?

a) Always, on every VIPb) Only when SSL offload is enabledc) Only for UDP trafficd) When the pool members' default route is NOT the BIG-IP, so their replies would otherwise bypass the proxy

Correct: d. LTM is a full proxy, so the server's reply must return to the BIG-IP. If the members' default gateway isn't the BIG-IP, replies route around it (asymmetric) and the client never gets them. SNAT Automap rewrites the client source to a BIG-IP self-IP, forcing replies back to the proxy. If the BIG-IP already IS the servers' gateway, you may not need SNAT.

Priya at TCS faces this

A 50/50 A-B app at an Indian bank works for new visitors but breaks for logged-in users — sessions randomly drop, and exactly half of requests fail.

Likely cause

OneConnect is reusing a server-side connection across different clients while persistence isn't honoring the session, so half the authenticated requests land on the wrong member / a pooled connection.

Diagnosis

Check the persistence profile and the OneConnect source mask; reproduce while watching persistence records and the connection table.

Local Traffic ▸ Virtual Servers ▸ (VIP) ▸ persistence + OneConnect profile

Fix

Apply the correct persistence profile (cookie for HTTP) and tune OneConnect's source mask so connection reuse doesn't cross client sessions — pinning each authenticated user to one member.

Verify

Logged-in users stay on one member across the journey; the 50/50 split holds for NEW sessions only, exactly as intended.

Figure 4 — A Pool Member shows DOWN — why? climb the monitor ladder

ICMP/TCP down = it is below the application; a green TCP but failing Send/Receive = the app is up but your health check is wrong; a member that flaps with no errors usually means the server's return path doesn't go back through the BIG-IP (SNAT fixes it).

Figure 5 — F5 BIG-IP LTM interview cheat-sheet

Tap the Preview button at the top to save this one-page card before your interview.

Prove it, don't assume

Don't close an LTM ticket on 'the VIP looks fine'. show ltm virtual proves the VIP is available; show ltm pool <p> members proves the members are UP; a tcpdump on the BIG-IP proves traffic leaves to the member AND the reply returns (if it doesn't, you need SNAT). Those three checks answer most LTM tickets.

👉 So far: Profiles: TCP/HTTP parse traffic, OneConnect reuses server TCP, Client-SSL = SSL offload (+Server-SSL re-encrypts). SNAT Automap = self-IP source, needed when the server's default route isn't the BIG-IP. iRules run on events like HTTP_REQUEST for L7 logic. Verify with show ltm virtual/pool + tcpdump.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from F5 docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: why is F5 LTM called a full proxy, and why does it matter? Then compare to the expert version.

Expert version: Because LTM terminates the client's TCP connection at the Virtual Server and opens a completely separate, new connection to the chosen pool member — two independent TCP stacks instead of forwarding the same packets. That termination is what lets it decrypt and re-encrypt HTTPS (SSL offload), pool and reuse server-side connections (OneConnect), pin sessions with persistence, and inspect/rewrite L7 with iRules. A packet-based router or L4 forwarder can do none of those because it never owns either connection.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Interview Prep at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

BIG-IP LTM: Local Traffic Manager — F5's full-proxy Application Delivery Controller (ADC) that load-balances and manipulates L4–L7 traffic.
Full proxy: LTM terminates the client connection and opens a separate, new server-side connection — two independent connections, not packet forwarding.
Virtual Server (VIP): An IP:port clients connect to; it terminates the client connection and applies profiles, persistence and the LB decision.
Pool / Member / Node: Pool = group of members for one app; Member = Node:Port (e.g. 172.16.10.11:8080); Node = bare server IP.
Load-balancing method: Round Robin (even), Least Connections (fewest active), Ratio (weighted), Fastest, Priority Group Activation (failover tiers).
Persistence: Pins a session to one member — cookie (HTTP, accurate per-browser) vs source-address (any protocol, breaks behind shared NAT); also SSL/SIP/Universal.
Health monitor: Periodic check: ICMP (Node/L3), TCP (port), HTTP/HTTPS (Send/Receive string = app health). Timeout ≈ (3×Interval)+1.
In-band vs out-of-band: Out-of-band = active scheduled probe (normal monitors); in-band = passive, watches real client traffic for failures.
SNAT: Source NAT — Automap (self-IP source), pool (many addresses), or none; needed when the server's default route isn't the BIG-IP.
OneConnect / iRules: OneConnect reuses server-side TCP across requests; iRules are TCL scripts on events like HTTP_REQUEST for L7 logic — both need the full proxy.

📚 Sources

F5 MyF5 / techdocs — BIG-IP Local Traffic Manager: Concepts (nodes, pools, members, virtual servers). techdocs.f5.com
F5 MyF5 / techdocs — NATs and SNATs & SNATs (Automap, SNAT pool, none). techdocs.f5.com
F5 MyF5 / techdocs — Health and Performance Monitoring & Monitors Reference (Send/Receive, Interval/Timeout). techdocs.f5.com
F5 MyF5 — K12531: Troubleshooting health monitors. my.f5.com
F5 clouddocs — iRules reference: SNAT command & HTTP events. clouddocs.f5.com
Oracle Coherence docs — Integrating with F5 BIG-IP LTM (full-proxy traffic flow & persistence). docs.oracle.com

What's next?

Cleared the F5 LTM round? Keep going — the interview-prep library covers Palo Alto, Fortinet, Zscaler, Checkpoint and more, all in the same hands-on style.

Next · All interview lessons → Practice on exam.techclick.in →

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

🎯 By the end you will be able to

Pick where you want to start

Core objects

LB & persistence

Health monitors

Profiles, SNAT & iRules

① LTM core objects — the full-proxy hierarchy

The F5 LTM vocabulary every interview opens with

② Load balancing & persistence

▶ Watch one request cross the full proxy

③ Health monitors — knowing UP from DOWN

④ Profiles, SNAT, SSL & iRules + troubleshooting

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?