I85PREP
⌘ K
F5 301B BIG-IP LTM study materials
F5 301B BIG-IP LTM study resources

F5 301B BIG-IP LTM: Troubleshooting and monitoring LTM objects

F5 301B BIG-IP LTM · Work through your exam, one topic at a time.

All guide sections

Troubleshooting and monitoring LTM objects

Domain 8 covers diagnosis: where to look first, which tool shows which layer, and how to tell a monitor problem from a routing problem. Questions describe a symptom and ask what to check or what the output means.

Order of checks

  • Confirm the virtual server matched the traffic: correct address and port, enabled VLAN, listener state.
  • Confirm the pool is healthy: member availability, monitor status, last failure reason.
  • Confirm the path: does a capture show packets in both directions with the expected translation?
  • Confirm the servers: default gateway pointing at the BIG-IP when SNAT is None.

Tools

  • tmsh show ltm virtual, show ltm pool and show ltm node for state and counters; tmsh show sys connection for live connections.
  • tcpdump -i 0.0 -s0 host <ip> captures on all VLANs; -i 0.0:nnn adds VLAN tags to the output. Captures taken without the 0.0 pseudo-interface often show nothing.
  • /var/log/ltm holds monitor transitions and TMM events; /var/log/audit holds configuration changes.
  • qkview bundles diagnostics for iHealth analysis; tmsh show sys performance covers platform health.
  • Statistics show bits in and out, current connections, and a growing connection queue when the virtual server is saturated.

Worked example

A dashboard using long polling disconnects almost exactly every 300 seconds. Reasoning: 300 seconds is the idle timeout of the default tcp profile, so BIG-IP closes a connection that has been quiet while the server holds the response. Confirm by watching tmsh show sys connection age the connection to 300 seconds and disappear, or by capturing and seeing the FIN originate from the BIG-IP. Fix with a custom TCP profile (or child profile) with a longer idle timeout on both client and server side, and check OneConnect's own timeout if connection reuse is in play.

Traps

  • Reading node counters when the question is about a specific member.
  • Capturing on the wrong VLAN, or without -i 0.0, and concluding no traffic arrived.
  • Treating "unknown" monitor status as down.
  • Blaming the application when the pool is green but SNAT is None and return traffic bypasses the BIG-IP.
  • Forgetting that a disabled virtual server still appears in configuration listings.