A client hits a VIP:port. The virtual-server type decides how much of the packet BIG-IP actually owns. On a Standard VS the path is VLAN → profiles → LTM policy / iRule → persistence lookup → load-balancing method → monitor-up pool member → SNAT → server. If the server’s default gateway is not BIG-IP, or client and server share a subnet, SNAT is what forces the reply back through the box. Persistence pins a returning client; without OneConnect, HTTP is still one load-balance per TCP connection. Config sync is not connection mirroring.
1. Ticket hook — why the VIP path matters
Night shift: “app.example.com:443 is up in the GUI. Half the users bounce.” The virtual server is Performance (Layer 4). Someone attached an HTTP profile, a cookie persist profile, and an iRule on HTTP_REQUEST that sends /api to pool_api. The VIP status is green. The iRule never fires. Performance (Layer 4) is a Fast L4 virtual server — it is not a full HTTP proxy.
That is the interview. Type first, then persist, then SNAT. Reciting “BIG-IP load-balances” without naming those three objects is an L1 answer.
Virtual server (VS) — VIP:port clients hit. Virtual address — the IP part; one address can host 80, 443, 161. Standard VS — full proxy; L7 profiles, iRules, SSL, persistence. Performance (Layer 4) — Fast L4 profile; packet-speed L4. SNAT — rewrite the source toward the server so the reply returns through BIG-IP. Auto Map — translation address is a self IP, typically the floating self IP of the egress VLAN. Cookie insert — default cookie BIGipServer<pool_name> with encoded member address and port. OneConnect — reuse idle server-side TCP; with an HTTP profile, load-balance each request. LTM policy — draft → publish → attach; first-match / best-match / all-match. Traffic group — floating VIP + floating self IPs that fail over together. Connection mirroring — live flows over TCP 1028 to the next-active device; not the same as config sync.
2. Mental model: full proxy vs fast path
BIG-IP is not “a VIP in front of a pool.” The type of virtual server decides whether TMM terminates the client connection or forwards L4.
Standard (full proxy)
Two connections: client↔BIG-IP and BIG-IP↔pool member. HTTP, Client SSL / Server SSL, iRules, LTM policies, cookie persist, and OneConnect all live here. This is the default interview object.
Performance (Layer 4)
Official wording: a Performance (Layer 4) virtual server is a virtual server with a Fast L4 profile. It speeds Layer 4. It is the wrong type for HTTP_REQUEST iRules, cookie insert you expect per request, or SSL offload.
Forwarding (IP) has no pool. It forwards to the destination IP already in the packet and still tracks the connection. Reject drops anything destined for that VIP. Stateless is UDP-only: no connection table, no SNAT Auto Map, no iRules, no port translation — you must still assign a default pool.
Read the diamond first. Standard walks 1–5. Fast L4 and Forwarding skip the HTTP objects interviewers love to attach.
3. Request order on a Standard VS
Flowchart first. Official SNAT chapter: destination translation to the pool member is the normal LTM job. SNAT is the extra rewrite of the source when the server would otherwise answer past the box.
Green persist hit reuses the member. Red SNAT branch is one-arm or “gateway is not BIG-IP.” Sources: Session Persistence Profiles; SNATs chapter.
Attaching cookie persist to a VIP that has no OneConnect, then wondering why keep-alive HTTP from a proxy still lands on the first member. Official persistence chapter: without OneConnect, Local Traffic Manager load-balances once per TCP connection and can ignore a later cookie on that same connection.
4. How to choose VS, SNAT, persist, policy, HA
Interviewers mix these on purpose. Keep the verbs separate: terminate, translate source, pin, decide, fail over.
Virtual server types
Official Table 1 (LTM Concepts — Virtual Servers). Use Standard unless you can name why you do not need a full proxy.
| Type | What it is | Choose when | Interview trap |
|---|---|---|---|
| Standard | Load-balancing VS; default pool; full proxy | HTTP/HTTPS, SSL, iRules, LTM policy, cookie persist | “Standard is slower, never use it” |
| Performance (Layer 4) | Fast L4 profile | L4 only; no HTTP inspection | HTTP_REQUEST iRule or cookie insert you expect to honor per request |
| Performance (HTTP) | Fast HTTP profile | HTTP speed path with limited L7 | Treating it as a full Standard VS |
| Forwarding (IP) | No pool; forwards to dest IP in the packet | Route-through / transparent hop | Assigning a pool “so it load-balances” |
| Forwarding (L2) | Can share a node IP on a VLAN group | L2 transparent insert | Skipping the VLAN-group + disable-on-VLAN steps |
| Reject | Rejects traffic to that VIP | Blackhole a prefix/port | Expecting a pool or iRule to run |
| Stateless | UDP; no conn table | High-volume one-way UDP | SNAT Auto Map, iRules, or port translation — all disallowed |
| Internal | Sends to an intermediary (for example ICAP) | Adapt / DLP off-box, then back to the Standard VS | Using it as the client-facing VIP |
SNAT: Auto Map versus a SNAT pool versus none
Official SNAT chapter: create a SNAT when the server default gateway is not the BIG-IP, or when clients and servers share a network (virtual-server bounceback). Auto Map picks a self IP — typically the floating self IP of the egress VLAN. A SNAT pool is a pool of translation addresses you assign as a virtual-server resource. SNATs track connections (NATs do not) and default to TCP/UDP only.
Using a SNAT for inbound connections can exhaust ephemeral ports. That is why Auto Map on a busy VIP fails with “no translation address available” long before the pool looks sick.
| None (nPath / inline GW) | Auto Map | SNAT pool | |
|---|---|---|---|
| Translation address | Client IP preserved | Self IP (prefer floating on egress VLAN) | Addresses you allocated |
| Choose when | Servers route back through BIG-IP; you need the real client IP on the wire | One-arm or “gateway is not us”; modest connection rate | Same topology, high connection rate / port exhaustion |
| Proof | tcpdump on the server VLAN shows client source | tmsh show ltm snat-translation; server log shows self IP |
Same command, many translation addresses in use |
| Trap | One-arm without SNAT — server answers the client, client RSTs | One floating self IP × 64k ports | Pool too small, or forgot to attach it on the VS |
Persistence
A persistence profile stores which pool member served the client so later requests bypass a new load-balance. Cookie insert (default method) writes BIGipServer<pool_name> with the encoded member address and port. Source address affinity (simple persistence) keys on client IP — it collapses behind CGNAT. Destination address affinity is for cache arrays. Universal / hash need an iRule. SSL persistence keys on the SSL session ID for non-terminated SSL.
OneConnect
OneConnect holds idle server-side TCP and reuses it when the OneConnect source mask says the new client is eligible. Assign an HTTP profile when you optimize HTTP. Without OneConnect, each TCP connection is load-balanced once. With OneConnect + HTTP, each request can go to a different member — which is also how a later cookie is honored. If the VIP also has a SNAT, BIG-IP translates the source first, then applies the OneConnect mask to the translated address.
LTM policy versus iRule
Official policy manual: create a draft, publish, then associate the published policy with the virtual server. Each policy has a matching strategy — first-match, best-match, or all-match — plus rules of conditions and actions (forward to pool, redirect, insert/remove header, persist, log, reset). Conditions inside a rule are AND; values inside a condition are OR. A rule with no conditions, last in the list, is the default on first-match or best-match.
The same manual prints an iRule next to every example (Nimda URI discard, selective compression, X-Forwarded-For spoof). Use the policy when the condition type exists (HTTP URI path, Host, header, method, User-Agent). Use an iRule when you need Tcl events, tables, sideband, or logic the action list cannot express. Do not write a 40-line HTTP_REQUEST just to send /images to another pool.
| LTM policy | iRule | |
|---|---|---|
| What it is | Published rule list with a matching strategy | Tcl script on events (CLIENT_ACCEPTED, HTTP_REQUEST, …) |
| Lifecycle | Draft → publish → attach | Save and attach; it is live |
| Choose when | URI / host / header / redirect / pool / persist / log | Custom parse, table, sideband, events a policy cannot see |
| Proof | Local Traffic › Policies › Policy List (Published); tmsh list ltm policy |
Local Traffic › iRules; tmsh list ltm rule; /var/log/ltm if you log |
HA: device trust, device group, traffic group, mirroring
Device service clustering (DSC): devices trust each other with certificates. A Sync-Failover device group syncs configuration and fails traffic groups over. A traffic group is the floating set — virtual addresses and floating self IPs — that actually moves. Module provisioning must match on every member.
Connection and persistence mirroring is a separate switch. Official virtual-server chapter: mirroring runs over TCP 1028 to the traffic group’s next-active device, only between identical hardware platforms, and the system can mirror up to 15 active traffic groups. Config sync without mirroring means the VIP comes up empty. Failover is not “stateful” until you can name that socket.
5. Do: VIP proof + persist + HA
Side A is the GUI you would open in a lab. Side B is the tmsh you quote in the room. Side C is the sentence that proves you will not reboot the pair. Primary source for Side A: LTM Concepts — Virtual Servers and SNATs (Source Address Translation on the VS). Primary source for policies: Getting Started with Policies — draft, publish, associate.
Side A — Virtual server properties (training mock)
Path: Local Traffic › Virtual Servers › Virtual Server List › vs_app443. Confirm Type, HTTP Profile, Source Address Translation, Default Persistence Profile, and that any LTM policy is a published policy, not a leftover draft.
Local Traffic / Virtual Servers / vs_app443 / Properties
Virtual Server Properties
Training mock · field names from Local Traffic › Virtual Servers (Type, Source Address Translation, Default Persistence Profile). Dummy RFC 5737 address only. Lab intent: Standard + HTTP + Auto Map + cookie.
Side A — Publish the LTM policy (training mock)
Path: Local Traffic › Policies › Policy List. Official order: draft policy → publish → associate the published policy with the virtual server. A draft attached to nothing is not in the data path.
Local Traffic / Policies / Policy List
Policy List
Training mock · Getting Started with Policies: draft, publish, associate. Matching strategy first-match. Last rule with no conditions is the default.
Side B — CLI: virtual, connection, persist, HA
-
Prove the VIP type and SNAT
Quote Type, pool, persist, and snat from the running object. Do not argue from memory of last week’s change window.
BIG-IP · virtual servertmsh list ltm virtual vs_app443 type pool persist source-address-translation profiles tmsh show ltm virtual vs_app443
-
Reproduce once, then read the connection
Have the user retry one HTTPS hit. Then filter the connection table. Server-side source should be the SNAT address if Auto Map or a SNAT pool is on.
BIG-IP · connection + SNATtmsh show sys connection cs-client-addr 10.20.30.44 tmsh show ltm snat-translation
-
Prove persistence, not a guess
Cookie insert should show a persist record (and a
BIGipServer…cookie in the browser). Source-address affinity keys on the client IP — useless if many users share a NAT.BIG-IP · persist recordstmsh show ltm persistence persist-records
-
Prove HA is more than “the pair is green”
Device trust, device group, which device is active for the traffic group, and whether connection mirroring is on. Mirroring peer is the next-active device for that traffic group.
BIG-IP · DSC / traffic grouptmsh show cm traffic-group tmsh show cm device tmsh list ltm virtual vs_app443 mirror
Rebooting the standby “to refresh HA,” or running a blanket tmsh delete sys connection on a production TMM to force new persist records. Filter one client address. Do not treat a TCP ping to the VIP as proof of HTTP persist or of SSL offload.
Side C — Close the change window
Say this: I confirmed Type is Standard, I quoted the SNAT translation, I saw the persist record for that client, I did not dump the whole connection table, I retested the original URI. If this pair fails over, I also checked mirror on the VIP — config sync alone will not keep the TCP session.
6. Runtime path after go-live
Once the first request has built a connection, production tickets are mostly “why is this still the old member?”
- Client reuses the same TCP connection (browser keep-alive or a proxy).
- Without OneConnect, BIG-IP does not load-balance again. A new cookie on that TCP can be ignored.
- With OneConnect + HTTP, the next request can honor persist or a policy pool select.
- A published policy change applies to new matching requests; a draft does nothing.
- An iRule save is live on the next event. That is why a bad
HTTP_REQUESTtakes production down faster than a draft policy. - On failover: the traffic group floats the VIP and floating self IPs. Only mirrored connections continue. Auto Map after failover uses the floating self IP — that is why the floating address on the egress VLAN matters.
7. Eight interview scenarios
Each one is a production ticket. Answer with the direct line, then the evidence. Weak answers reboot the pair, write an iRule first, or confuse Auto Map with a SNAT pool.
Q1 · Scenario — HTTP iRule on a Performance (Layer 4) VIP
vs_app443 is Performance (Layer 4), status green. An iRule on HTTP_REQUEST should send /api to pool_api. Every request stays on the default pool. First fix?
Strong framing (say this)
I list the virtual and quote Type and profiles before I debug Tcl.
Evidence to name
tmsh list ltm virtual vs_app443 type profiles; Local Traffic › Virtual Servers › Type.
Q2 · Troubleshoot — one-arm, no SNAT, client RSTs
BIG-IP and the pool members share 10.0.10.0/24. Source Address Translation is None. tcpdump on the server shows the real client IP. The client sends RST. First check?
Strong framing (say this)
Same subnet or gateway-not-us: SNAT. I prove it with a server-side capture, not with VIP status.
Evidence to name
tcpdump on the server VLAN; tmsh show sys connection server-side source; VS Source Address Translation.
Q3 · Compare — cookie insert versus source address
A shopping cart VIP sits behind a carrier-grade NAT. Users hop members mid-checkout. The persist profile is source_addr. What do you change, and what do you not change?
BIGipServer<pool_name> on the client. Thousands of subscribers behind one public IP no longer share one persist record.Strong framing (say this)
Cookie for HTTP users. Source-addr for non-HTTP or when you cannot set a cookie. SSL persist is for non-terminated SSL session IDs.
Evidence to name
Local Traffic › Profiles › Persistence; browser Set-Cookie; tmsh show ltm persistence persist-records.
Q4 · Architecture — cookie ignored on the same TCP
Cookie insert is on. A reverse proxy multiplexes many users on one keep-alive to the VIP. The second request carries a cookie for member B. Traffic still hits member A. Why, and what profile do you add?
Strong framing (say this)
OneConnect is per-request HTTP on reused server-side (and client-side multiplexed) TCP. I name the HTTP profile with it.
Evidence to name
VS profile list includes oneconnect + http; Persistence Profiles “HTTP parsing with and without a OneConnect profile.”
Q5 · Compare — URI routing: policy or iRule?
Product wants /images to pool_img and everything else to pool_app. A junior starts an iRule. What do you ship instead, and when would you keep the iRule?
Strong framing (say this)
Published policy first. iRule when I can name the event the policy cannot see.
Evidence to name
Local Traffic › Policies › Published; tmsh list ltm policy; Getting Started with Policies (draft / publish / associate).
Q6 · Evidence — Auto Map worked until lunch
One-arm VIP, Source Address Translation Auto Map. New connections fail. Existing ones stay up. Pool members are green. What field do you read first?
Strong framing (say this)
I show snat-translation counters, then I size a SNAT pool. I do not add another self IP and call it a pool.
Evidence to name
tmsh show ltm snat-translation; /var/log/ltm port-exhaustion messages; Local Traffic › Address Translation.
Q7 · Architecture — failover dropped the long TCP sessions
Sync-Failover pair. Primary loses power. The VIP comes up on the peer. New users work. Hour-long TCP uploads die. Config sync is In Sync. Explain both.
mirror is disabled on the VIP, those connections were never on the peer.Strong framing (say this)
Device trust, device group, traffic group, then mirror. I name TCP 1028 and the next-active peer.
Evidence to name
tmsh list ltm virtual vs_app443 mirror; Device Management › Traffic Groups; tmsh show cm traffic-group; DSC administration.
Q8 · Unsafe shortcut — “turn SNAT off so the app sees the client IP”
App owners want X-Forwarded-For and the real client IP in server logs. A junior sets Source Address Translation to None on a one-arm Standard VS. What do you stop, and what do you build instead?
Strong framing (say this)
SNAT for return path. Header for identity. Topology change if they truly need the IP on the packet.
Evidence to name
VS Source Address Translation; HTTP profile insert XFF / policy Insert http header; Getting Started with Policies XFF example.
8. Traps and proof checklist
| Trap | What you see | Safer next step |
|---|---|---|
| L7 objects on Fast L4 | VIP green; iRule / cookie / policy idle | List Type; move to Standard + HTTP |
| One-arm, SNAT None | Server SYN-ACK to client; client RST | Auto Map or SNAT pool; confirm with tcpdump |
| Source-addr behind CGNAT | Thousands of users share one member | Cookie insert for HTTP; do not raise timeout |
| Cookie persist, no OneConnect | Keep-alive / proxy ignores later cookie | Add OneConnect + HTTP; retest the second request |
| Draft policy “attached” | URI still hits the default pool | Publish, then associate the published policy |
| iRule for a one-line URI route | Tcl outage risk for an IF→THEN | LTM policy first-match; iRule only for real Tcl |
| Auto Map port exhaustion | New connects fail; members still UP | show ltm snat-translation; add a SNAT pool |
| “In Sync means stateful HA” | VIP floats; long TCP dies | Enable mirror on the VIP; confirm TCP 1028 to next-active |
| Clear SNAT to expose client IP | Bounceback outage on one-arm | Keep SNAT; insert X-Forwarded-For; change topology if the wire IP is mandatory |
- VS Type spoken (Standard vs Performance L4 vs Forwarding).
- Source Address Translation matches the topology (None only if replies already hairpin).
tmsh show sys connectionshows the expected server-side source.- Persist method matches the app (cookie vs source-addr) and OneConnect is on if HTTP is multiplexed.
- LTM policy is Published and associated — or the iRule event is one a policy cannot express.
- HA: traffic group active device named;
mirrorstate named if the ticket is failover. - Original URI retested — not a TCP ping to the VIP.
Knowledge check
Six judgment items. Each maps to a promise bullet. Check answers, then reset and re-read the traps table if you miss any.
Sources
- Virtual Servers — types (Standard, Forwarding L2/IP, Performance HTTP/L4, Stateless, Reject, Internal); SNAT Auto Map; connection mirroring TCP 1028; identical platforms; traffic groups
- SNATs — bounceback; gateway-not-us; Auto Map uses a self IP (typically floating on egress VLAN); SNAT pool; ephemeral ports
- Session Persistence Profiles — cookie insert
BIGipServer<pool>; source / dest affinity; OneConnect required so later cookies are not ignored - Other Profiles — OneConnect — idle server-side reuse; source mask; HTTP per-request LB; SNAT then mask
- Getting Started with Policies — draft, publish, associate; official iRule-equivalent examples
- Introducing Local Traffic Policies — first-match / best-match / all-match; conditions and actions
- iRules — Tcl event scripts when a policy is not enough
- Introducing BIG-IP Device Service Clustering — device trust, Sync-Failover device group, traffic groups, equivalent module provisioning
- K14163: Overview of BIG-IP virtual server types
- K7820: Overview of SNAT features
- K7208: Overview of the OneConnect profile
- K7964: Persistence may appear ignored without OneConnect
- K26898044: Persistence methods available in BIG-IP
- DevCentral: To iRule, or not to iRule — policies replace common IF→THEN iRules
Related: F5 session factory · F5 evidence desk · LTM virtuals and pools · LTM troubleshooting · iRules basics · F5 LTM interview guide · F5 interview hub · F5 practice dashboard