mtr Network Path & Packet Loss Diagnosis Prompt
Turn raw mtr/traceroute output into a clear verdict on where packet loss or latency is actually being introduced along a path — and whether it's real or an ICMP rate-limit mirage.
- Target user
- Linux admins and SREs chasing intermittent latency or loss between hosts
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a senior network engineer who has read thousands of mtr reports and knows the difference between real packet loss and ICMP de-prioritization at intermediate hops. I will provide: - The exact `mtr --report --report-cycles [COUNT] [TARGET]` output (text), ideally with `-w -b -c [COUNT]` - Both directions if I have them (loss is often asymmetric) - Whether the symptom is throughput, latency, or connection resets, and the affected protocol/port - `mtr -T -P [PORT]` (TCP mode) output if UDP/ICMP results look unreliable - Source and destination context: same DC, cross-region, over a VPN/WireGuard tunnel, or public internet Your job: 1. **Read the columns correctly** — explain Loss%, Snt, Last, Avg, Best, Wrst, StDev per hop for THIS report, and call out high StDev as a jitter signal. 2. **Distinguish real loss from ICMP rate-limiting** — the cardinal rule: loss at an intermediate hop that does NOT persist to the final hop is almost always the router de-prioritizing ICMP TTL-expired replies, NOT a real problem. Identify which hops are red herrings here. 3. **Locate the real fault** — find the first hop where loss appears AND continues to the destination. Distinguish forward-path vs return-path loss using the both-directions data. 4. **Latency vs loss vs jitter** — separate a hop that merely adds latency (long-haul link, fine) from one degrading the connection. Flag bufferbloat patterns (Avg climbing under load). 5. **Recommend the next probe** — when to switch to `mtr -T` (TCP) because ICMP is filtered, when to involve the upstream/transit provider with a specific hop and timestamp, and what to capture (`tcpdump`, `ss -i`) to confirm. Output as: (a) a per-hop annotated read of the report, (b) a single clear verdict — "loss is real and originates at hop N (owner: ___)" or "no real loss; intermediate counters are ICMP rate-limit artifacts", (c) the next diagnostic command to run, (d) who to escalate to with what evidence. Verify before acting: do not open a provider ticket or reroute traffic until the both-directions data confirms the loss persists to the final hop — intermediate-only loss is not actionable.
Why this prompt works
mtr output is one of the most misread diagnostics in networking. The single most common mistake — made by junior and senior engineers alike — is panicking over loss shown at an intermediate hop. Routers routinely de-prioritize or rate-limit the ICMP “TTL expired” replies that mtr depends on, so a core router can show 40% “loss” while forwarding 100% of your actual traffic perfectly. This prompt hard-codes the cardinal rule (loss must persist to the final hop to be real) so the AI doesn’t lead you to escalate a phantom.
The prompt also forces the model to keep latency, loss, and jitter as separate concepts. A transcontinental link adding 80ms of Avg latency is physics, not a fault; a hop with high StDev is jitter that will wreck a VoIP or replication stream even at low average latency. By demanding a per-hop annotated read plus a single plain-English verdict, you get something you can paste into an incident channel or a provider ticket without re-explaining.
Finally, it pushes toward the right next step instead of a dead end. ICMP and UDP probes get filtered or deprioritized in ways TCP-mode mtr does not, so the model is told when to switch to -T, what supporting capture to grab, and exactly which hop and timestamp to hand to an upstream provider. The AI drafts the interpretation and the escalation evidence; you confirm the both-directions data before anyone touches routing.