This lesson is your Module 7 PDF — interactive
Source file: F5-BIG-IP-LTM-Module-7.pdf (22 slides, Downloads). The posters below are the same Techclick infographics from that deck, not generic stock art. Walk the PDF in order: mindset → intake → last known-good hop → packet proof.
Find the last known-good point. Stop at the first layer where packet evidence breaks. On a Standard VS, client TCP and server TCP are two conversations.
Build the problem statement first
Slide 4 of the PDF: a precise intake cuts troubleshooting time in half. Without it you chase the wrong VIP, port, or timeframe.
Do not open tmsh or the GUI until source, VIP, port, timestamp+timezone, expected vs actual, and last change are written down.
Master flow + decision-tree infographic
PDF slide 5: work top-down. Stop at the first layer that has no packet proof. Slide 16 is the full decision-tree infographic from the same module.
The packet path is the troubleshooting map. I will not change config until I know the last hop that still worked.
DNS, client SYN, Virtual Server (PDF slides 6–9)
dig www.example.com nslookup www.example.com host www.example.com # expected A: 192.0.2.100
Then prove the client SYN actually hits BIG-IP. If SYNs never arrive, the fault is upstream (route, firewall, ACL, NAT) — not the pool.
tcpdump -nni 0.0 host 198.51.100.50
Matches PDF VS checks: dest IP, port, protocol, VLAN, enabled
vs_web_https
PDF: more-specific destination prefix wins at a high level. Client to 192.0.2.100:443 does not match a VS on :8443.
tmsh show ltm virtual tmsh list ltm virtual vs_web_https
Pool, monitor, route, ARP, SNAT (PDF slides 10–17)
tmsh show ltm pool tmsh show ltm pool WEB_POOL tmsh list ltm pool WEB_POOL tmsh show ltm node 10.20.20.101
PDF health-monitor trap: a trailing space on the receive string can fail the monitor silently. Reproduce the monitor, including Host header for name-based apps.
curl -v http://10.20.20.101/health curl -v -H "Host: www.example.com" http://10.20.20.101/health curl -vk https://10.20.20.101/health
tmsh show net route tmsh list net route tmsh show net arp ip neigh arp -an
PDF SNAT lesson: asymmetric routing is one of the most common silent failures. Client → BIG-IP → server, server replies via a router that bypasses BIG-IP. Do not enable Automap blindly.
Infographic: tcpdump client-side vs server-side
tcpdump -nni 0.0 host 198.51.100.50 tcpdump -nni 0.0 host 10.20.20.101 tcpdump -nni 0.0 'host 198.51.100.50 or host 10.20.20.101' tcpdump -nni 0.0 -s0 -w /var/tmp/app_issue.pcap
PCAPs may contain sensitive application data. Capture narrowly, protect the file, delete/archive to policy. F5 K6546: interface 0.0 is not rate-limited like hardware switch taps — filter it in production.
tmsh show sys connection
Infographic: SYN, RST, retransmissions
Retransmissions are a symptom, not a root cause (PDF slide 21). Check loss, congestion, silent firewall drop, busy server, asymmetric routing, MTU — do not auto-blame TMM.
Infographic: VIP is green, application is down
Your 22-slide PDF stops at RST analysis. This poster is the production RCA that uses the same IPs and the same last-known-good method.
| PDF / poster hop | If this fails | First command |
|---|---|---|
| DNS | Wrong VIP | dig www.example.com |
| Client SYN | Upstream | tcpdump -nni 0.0 host 198.51.100.50 |
| VS match | Port/VLAN/proto | tmsh list ltm virtual |
| Pool / member | Monitor, disabled, port | tmsh show ltm pool WEB_POOL |
| Server SYN / SYN-ACK | Backend/FW/ARP | tcpdump -nni 0.0 host 10.20.20.101 |
| Return to client | SNAT / client TLS / iRule | tmsh show sys connection |
Traps from the Module 7 PDF
| PDF trap | What it looks like | Proof |
|---|---|---|
| Change config first | SNAT/iRule flapping | Written intake + last known-good packet |
| Green pool = healthy app | VS/pool Available, users timeout | Client SYN and server SYN in tcpdump |
| Monitor receive string space | Member DOWN, curl works | Reproduce exact send/receive including Host |
| Route without ARP | Route exists, Incomplete ARP | tmsh show net arp |
| Asymmetric return | Server capture OK, BIG-IP never sees reply | Server default gateway vs SNAT |
| RST means F5 | Someone said “F5 reset” | RST source IP + capture point (slide 22) |
| Wide 0.0 capture | Huge PCAP | Host+port filter; K6546 |
1) Point DNS to 192.0.2.200 and prove LTM is the wrong box. 2) VS port 443 vs 8443 mismatch. 3) Firewall drop on member :443 — SYN without SYN-ACK (infographic scenario C). 4) Strip Host from the HTTP monitor. 5) Save a filtered PCAP, then delete it.
“VIP is green, site times out. First packet question?” Did the client SYN reach BIG-IP, and did BIG-IP send a server-side SYN? Weak: “I would bounce TMM.”
Knowledge check
Judgment from your Module 7 PDF + the VIP-green poster.
Sources
- F5-BIG-IP-LTM-Module-7.pdf — your 22-slide Techclick module in Downloads (primary). Infographics: slides 3, 11, 16.
- K6546 — tcpdump on 0.0 is not rate-limited like switch taps; filter in production
- K00463541 — tcpdump
-nn, interface 0.0, version-specific F5 trailers - K40033505 —
tmsh show sys connectionis data-plane - K14800 — virtual server match uses dest/src/port
Related: SSL offload vs re-encrypt · SNAT · Evidence desk · F5 interview · Syllabus
Command flags can vary by BIG-IP version. Confirm on the running release. PDF training mocks are not live TMUI.