# F5 interview answers that also teach the path Source: https://ai.techclick.in/blog_f5_interview Markdown: https://ai.techclick.in/blog_f5_interview.md Publisher: Techclick Infosec Pvt Ltd F5 interview questions and answers (2026) that also teach: VS types, SNAT bounceback, cookie vs source persist, iRules vs LTM policy, OneConnect per-request, and HA traffic-group mirroring. Say this out loud 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. Hero · who talks to whom Notice: the client never addresses a pool member. The VIP is the only destination the client knows. Everything after that is a BIG-IP decision. Hard words, once 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. Flow 1 · VIP type decides how much you own Client packet hits a VIP; type splits full proxy from Fast L4 and forwarding - Client packet Match VIP:port + VLAN / tunnel VS type? own the session? Standard Full proxy L7 + persist Fast L4 / fwd 1 Profiles TCP HTTP SSL 2 Policy / iRule maybe new pool 3 Persist hit? reuse member 4 LB + monitor only members UP 5 SNAT → server reply must return here If you picked the wrong type, steps 2–3 never run Performance (HTTP) uses Fast HTTP. Forwarding (IP) has no pool. Reject never reaches a member. Stateless = UDP, no conn table, no Auto Map, no iRules. Internal = ICAP / adapt before the Standard VS. Source: BIG-IP LTM Concepts — Virtual Servers, Table 1 types. Say the type before you defend the iRule. Read the diamond first. Standard walks 1–5. Fast L4 and Forwarding skip the HTTP objects interviewers love to attach. Path · five stations Notice: persist sits before a new load-balance decision. SNAT sits after the member is chosen. Mixing those two in an answer is the classic weak interview. ## 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. Flow 2 · persist miss vs persist hit · SNAT or not Persistence lookup then SNAT decision on a Standard virtual server HTTP request in Persist record? cookie / src-addr HIT Same pool member skip new LB (if still UP) MISS LB method + monitor Round Robin / Least Conn / … Server GW = BIG-IP and not one-arm? YES NO — SNAT Auto Map or SNAT pool force reply through BIG-IP OneConnect changes the diamond No OneConnect: one LB per TCP connection. HTTP + OneConnect: each request can pick a different member (and honor a new cookie). Cookie persist without OneConnect can ignore a later cookie on the same TCP flow. Sources: Persistence Profiles; OneConnect profile. Green persist hit reuses the member. Red SNAT branch is one-arm or “gateway is not BIG-IP.” Sources: Session Persistence Profiles; SNATs chapter. Common miss 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 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. https://203.0.113.10/tmui/Control/jspmap/tmui/locallb/virtual_server/properties.jsp Training mock · not live Local Traffic / Virtual Servers / vs_app443 / Properties ### Virtual Server Properties Name vs_app443 Type Standard Destination Address/Mask 203.0.113.80/32 Service Port 443 HTTP Profile http Source Address Translation Auto Map Default Persistence Profile cookie Default Pool pool_app443 Cancel Update 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. https://203.0.113.10/tmui/Control/jspmap/tmui/locallb/policy/list.jsp Training mock · not live Local Traffic / Policies / Policy List ### Policy List Published Policies pol_uri_route (first-match) Draft Policies pol_uri_route (draft) Rule 1 · condition HTTP URI path starts-with /api → Forward pool pool_api Rule 2 · default No condition (last) → Forward pool pool_app443 Create draft Publish 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 server tmsh 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 + SNAT tmsh 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 records tmsh 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 group tmsh show cm traffic-group tmsh show cm device tmsh list ltm virtual vs_app443 mirror Unsafe shortcut 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_REQUEST takes 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. Ops · proof desk Close the ticket with a connection line and a persist record, not with “the virtual is green.” ## 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? Direct answer Change the virtual server Type to Standard (and give it an HTTP profile). Performance (Layer 4) is Fast L4. HTTP_REQUEST is not in that path. Why production cares A green VIP only means the object is enabled and the pool has an up member. It does not mean your L7 objects ran. Weak answer / trap “The iRule syntax is wrong — rewrite it.” Or attach Fast HTTP and hope Tcl events appear. #### 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? Direct answer This is virtual-server bounceback. The server answers the client directly; the source IP is the server, not the VIP, so the client rejects it. Enable SNAT (Auto Map or a SNAT pool) so the server replies to a BIG-IP address. Why production cares Official SNAT chapter draws this exact picture: client rejects the response because destination and source no longer match. Weak answer / trap “Disable the server firewall” or “add a Reject VS.” The path is asymmetric, not blocked. #### 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? Direct answer Switch to cookie insert (HTTP Cookie Insert is the default cookie method). Source address affinity treats the CGNAT IP as one client. Do not “fix” it by lengthening the source-addr timeout. Why production cares Cookie insert stores the encoded member in BIGipServer<pool_name> on the client. Thousands of subscribers behind one public IP no longer share one persist record. Weak answer / trap Destination address affinity. That pins on the destination IP — useful for caches, not for a user’s cart. #### 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? Direct answer Without OneConnect, LTM load-balances once per TCP connection and can ignore later cookie data on that connection. Assign a OneConnect profile and an HTTP profile so each request is inspected and the cookie can select member B. Why production cares Official persistence chapter uses this proxy example. Universal persist has the same warning: add OneConnect. Weak answer / trap Delete the persist profile, or bounce TMM. The cookie is fine; the TCP reuse is the bug. #### 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? Direct answer A local traffic policy: HTTP URI path starts-with /images → Forward pool pool_img; last rule, no condition, → pool_app. Matching strategy first-match. Draft, publish, attach. Keep an iRule if you need Tcl the action list cannot do (tables, sideband, a non-HTTP event). Why production cares Official policy manual is built as “policy plus the equivalent iRule.” Policies are the supported IF→THEN path; iRules stay for the rest. Weak answer / trap Attaching the draft. Or all-match with two Forward pool actions and hoping both fire cleanly. #### 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? Direct answer Ephemeral ports on the translation address. Auto Map is a small set of self IPs (often one floating address). Official SNAT text: inbound SNAT can exhaust ephemeral ports until some source ports free. Move to a SNAT pool with enough addresses. Why production cares VIP status stays green because monitors do not consume the SNAT port space the same way clients do. Weak answer / trap Mark a pool member down “to shed load,” or add a second Performance L4 VIP. #### 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. Direct answer Config sync moved the objects. Connection mirroring did not move the flows. Mirroring is per traffic group, over TCP 1028, to the next-active device, and only between identical hardware. If mirror is disabled on the VIP, those connections were never on the peer. Why production cares Sales language says “stateful HA.” The virtual-server chapter lists the socket and the identical-platform limit you must say. Weak answer / trap “HA always mirrors TCP. Reboot the new active so TMM rebuilds state.” #### 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? Direct answer Stop the change — you will recreate bounceback RSTs. Keep SNAT. Insert X-Forwarded-For with an HTTP profile / LTM policy (the official policy book even has an anti-spoof XFF example). If the app must see the client IP on the wire, redesign to inline (servers’ default gateway is BIG-IP) or a supported nPath design — do not just clear SNAT on one-arm. Why production cares Client IP visibility and return-path symmetry are different problems. Solving the first by breaking the second is an outage. Weak answer / trap Auto Map on every VIP “just in case,” including a pair that already owns the server default route and now hides every client from the SIEM. #### 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 Proof checklist (pilot / interview close) - VS Type spoken (Standard vs Performance L4 vs Forwarding). - Source Address Translation matches the topology (None only if replies already hairpin). - tmsh show sys connection shows 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; mirror state 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. Q1 A Performance (Layer 4) virtual server has an HTTP_REQUEST iRule that never fires. What is the first fix? Add a SNAT pool so the iRule can see the client IP Enable connection mirroring on the traffic group Change Type to Standard and attach an HTTP profile Switch the iRule event to CLIENT_ACCEPTED only Correct: c . Performance (Layer 4) is Fast L4. HTTP events need a Standard (full proxy) VS. Re-read mental model + Q1. Q2 BIG-IP and pool members share a subnet. SNAT is None. The client RSTs the server’s reply. What is required? A Reject virtual server on the server VLAN SNAT (Auto Map or a SNAT pool) so the server replies to BIG-IP Destination address affinity persistence Change the VS type to Forwarding (IP) Correct: b . Official bounceback case: same network, no SNAT, client rejects a response that did not come from the VIP. Re-read SNAT table + Q2. Q3 Cookie insert is configured. A proxy reuses one TCP connection. The second request’s cookie for member B is ignored. What is missing? Match Across Pools on the cookie profile A Stateless virtual server Disabling the HTTP profile so Fast L4 can honor cookies A OneConnect profile (with HTTP) so each request is inspected Correct: d . Without OneConnect, LTM load-balances once per TCP connection and can ignore a later cookie. Re-read OneConnect + Q4. Q4 You must send HTTP URI /images to pool_img and all other paths to pool_app. What should you ship first? A published LTM policy (first-match) with an HTTP URI condition, then a default rule A draft policy left in Drafts so it can be edited live A Performance (Layer 4) VS with two pools Source address affinity with a /8 mask Correct: a . Official lifecycle is draft → publish → associate. URI path is a built-in condition. Re-read policy table + Q5. Q5 Auto Map has been fine for months. New client connections now fail while pool members stay UP. What is the first official explanation? Cookie persist records filled the connection table The traffic group is no longer floating Ephemeral ports on the Auto Map translation address are exhausted — use a SNAT pool Stateless mode disabled SNAT Automap automatically Correct: c . Official SNAT chapter: inbound SNAT can exhaust ephemeral ports. Auto Map is a tiny address set. Re-read SNAT + Q6. Q6 After failover the VIP is up on the peer and config is In Sync, but long-lived TCP sessions dropped. Why is that expected if mirroring is off? Config sync always includes the connection table Connection mirroring is a separate path (TCP 1028 to the next-active device); sync is only configuration Traffic groups never float virtual addresses OneConnect deletes all connections at failover by design Correct: b . DSC syncs config; mirroring copies flows over TCP 1028 on identical hardware. Re-read HA + Q7. Check answers Reset ## 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 ; 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 --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt