You run `mtr` toward a server and hop 6 reports 40% loss while the final hop reports 0%. What does that intermediate loss tell you, and what pattern in an mtr or traceroute report indicates loss that is actually hurting your traffic?

## Where the numbers in an mtr report come from `mtr` is traceroute and ping fused together. It sends probes with deliberately small TTL values: a probe with TTL 1 expires at the first router, TTL 2 at the second, and so on. Each router whose TTL counter hits zero is expected to send back an ICMP time-exceeded message, and that reply is what identifies the hop. Probes addressed all the way to the destination are answered by the destination itself. mtr repeats this continuously and builds a table with `Loss%`, `Snt`, `Last`, `Avg`, `Best`, `Wrst` and `StDev` per hop. The crucial asymmetry hides in that description. For an intermediate hop, the number you are measuring is *how reliably that router talks to you about itself*. For the destination row, you are measuring *how reliably packets get all the way there and back*. Those are different questions, and only the second one is about your traffic. ## Why middle hops lie Forwarding a packet is fast-path work: on a real router it happens in hardware or a tight dataplane loop. Generating an ICMP time-exceeded message is control-plane work handled by the router's CPU, and every serious vendor rate-limits it, precisely so that a flood of expiring packets cannot become a denial of service against the router's brain. Some operators deprioritise or drop these replies entirely. The result is the single most misread output in network troubleshooting: a scary red row in the middle of an mtr report from a device that is passing your traffic perfectly. ## The cumulative rule Read an mtr report top to bottom and ask whether loss *persists*: ``` 5. router-a.isp.net 0.0% 100 ... 6. router-b.isp.net 40.0% 100 ... <- artifact 7. router-c.isp.net 0.0% 100 ... 8. api.example.com 0.0% 100 ... <- what you actually care about ``` Hop 6 cannot be dropping 40% of transit traffic while hop 7 and the destination see none — the packets that reach hop 7 went *through* hop 6. That row is ICMP policing, nothing more. The pattern that matters is the opposite one: loss that appears at some hop and continues, at roughly the same level or worse, through every hop after it and at the destination. That is the point where the path starts dropping packets. In practice the last row is the row that decides whether you have a problem at all; the hops above it only help you locate it. ## The asymmetry caveat Every hop you see is a hop on the *forward* path. The replies take whatever return route the internet chooses, and that route is frequently different. So a hop that shows genuine loss may be innocent, with the damage happening on a return path you cannot see from this end. When it matters, run mtr from both ends and compare. ## Making the probes look like real traffic Default Linux traceroute sends UDP datagrams to high ports; mtr defaults to ICMP echo. Both are shaped and filtered differently from your production traffic. When you suspect policy rather than congestion, probe the real port: ```bash mtr -rwc 100 --tcp --port 443 api.example.com traceroute -T -p 443 api.example.com tracepath api.example.com ``` `mtr -rwc 100` is the form you paste into a ticket: `-r` produces a one-shot report, `-w` uses wide output so full hostnames fit, and `-c 100` fixes the sample count so the loss percentages mean something. `traceroute -T` sends TCP SYNs and needs privileges; `tracepath` needs none. ## What a good answer sounds like Name the mechanism (control-plane ICMP generation is rate-limited), state the cumulative rule, and then say what you would do with the finding. Even genuine mid-path loss inside someone else's network is usually not yours to fix — the useful outcomes are evidence for the provider, or a decision to route around it. An interviewer is checking that you do not open a ticket every time one row in an mtr report turns red.