F5 LTM Troubleshooting Scenarios - VIP Down, Website Timeout, tcpdump, curl, SNAT & Asymmetric Routing

ChatGPT Image Infographic 1 - F5 LTM troubleshooting decision tree

① Incident triage map - where can the flow break?

Most LTM outages are misdiagnosed because teams jump straight to pool members. The correct approach is to isolate control-plane status, data-plane packet flow and application-layer response in one evidence ladder.

Healthy path: Client test -> VIP/listener -> Pool select -> Profile logic -> Return path. Do not skip a layer just because one dashboard tile is green.

Production rule: prove whether the packet fails before VIP, at virtual server selection, during pool selection, inside profile logic, or on return path.

ChatGPT Image Infographic 2 - F5 LTM scenario board

② VIP down or virtual server not accepting traffic

When the VIP looks down, do not start at the backend. First prove whether BIG-IP is even selected for the connection.

• Check listener: destination IP, service port, protocol, source-address match and enabled state.
• Check network scope: VLAN and tunnel enablement, route domain, self IP reachability, ARP and upstream routing.
• Check HA: active device, traffic-group owner, floating address ownership and config sync.

Safe fix: correct the listener, VLAN or traffic-group owner only after proving the VIP is the break point.

③ User cannot access website but BIG-IP looks green

This is the most common trap. A green pool usually means the configured monitor condition passed; it does not always prove the real URI, TLS, host header, authentication path or application dependency.

Do not say: Restart the pool member because the user says the website is down. That answer creates downtime because it skips the actual evidence path.

ChatGPT Image Infographic 3 - curl, tmsh, tcpdump evidence ladder

④ curl, tmsh, tcpdump and log command ladder

Use the smallest possible test first, then widen only when evidence is missing. Keep one failing client IP, one VIP and one pool member in scope.

curl -vk https://<vip-fqdn-or-ip>/health
curl -vk --resolve app.example.com:443:<vip-ip> https://app.example.com/
curl -vk https://<pool-member-ip>:<port>/health
tmsh show ltm virtual /Common/<vs-name>
tmsh show ltm pool /Common/<pool-name> members
tmsh show sys connection cs-client-addr <client-ip>
tcpdump -s0 -ni 0.0 host <client-ip> or host <pool-member-ip>
tail -f /var/log/ltm

Interpretation: if curl to VIP fails but curl to pool member works from BIG-IP, inspect listener, profile and SNAT. If both fail, involve server/app routing. If tcpdump sees request on clientside but not serverside, BIG-IP decision logic stopped it. If serverside sees request but reply bypasses BIG-IP, suspect SNAT or routing symmetry.

ChatGPT Image Infographic 4 - SNAT and asymmetric routing

⑤ SNAT issue and asymmetric routing

SNAT is not a magic checkbox; it is a return-path control. F5 documentation explains that SNAT can ensure server responses return through BIG-IP when the server default route would not normally do so.

Failure pattern: clientside tcpdump shows SYN to VIP, serverside tcpdump shows SYN to member, but the SYN-ACK either never appears back on BIG-IP or comes from an unexpected path. The server may be replying to its default gateway instead of to BIG-IP.

Safe fix options: set backend default gateway to BIG-IP, add route symmetry, use SNAT Automap for simple cases, or use a scoped SNAT pool when you need predictable translation addresses and scale.

⑥ Persistence, HA owner and closeout verification

Not every intermittent issue is network routing. Persistence can keep one user stuck to a weak pool member, and HA ownership can make a VIP behave differently after failover.

• Persistence proof: compare affected user cookie/source persistence records with selected pool member and member health.
• HA proof: verify active/standby state, traffic-group owner, floating self IPs, virtual-address ownership and ARP behavior.
• Closeout proof: replay the original failing user path, check HTTP/TLS result, confirm connection table and verify logs/counters stopped increasing for the failure.