Troubleshooting
Troubleshooting
This domain tests a structured approach to BIG-IP faults: isolate the layer, gather evidence, and change one variable at a time. Expect questions on logs, packet capture, qkview, monitor state, and configuration sync.
Core rules
- Work layer by layer: physical and link, IP and routing, TCP, SSL, HTTP, and application. A 503 from BIG-IP often means no pool member is available, not that the application is down.
- Logs live in /var/log/ltm, /var/log/asm, /var/log/apm, and /var/log/gtm. Increase log levels only for the duration of the test.
- tcpdump on the client and server VLANs shows whether packets arrive, are translated, and return. Capture both directions and use a filter for the virtual server address and port.
- qkview collects configuration, logs, and diagnostics for support; run it before rebooting or making disruptive changes.
- tmsh show ltm virtual, tmsh show ltm pool, and tmsh show cm sync-status answer most state and synchronization questions.
- A config sync failure can be caused by version mismatch, network connectivity, or a device group mismatch.
Worked example
Users report intermittent 503 errors on an HTTPS virtual server. The administrator runs tmsh show ltm virtual and sees the virtual server up; tmsh show ltm pool shows one member down with a monitor failure. The monitor is an HTTPS GET to /health expecting OK; the application now returns 200 with an empty body. The administrator fixes the health endpoint or updates the receive string, and the member returns to service. A tcpdump confirms no packets were sent to the down member during the outage.
Traps
- Rebooting before running qkview and losing evidence.
- Assuming a monitor failure means the service is down; the check may be wrong.
- Forgetting route domains or SNAT when troubleshooting return traffic.
- Looking only at the virtual server and not the pool member or node state.
- Changing multiple settings at once and losing the cause of the fix.