Direct answer: the most useful number in an mtr or pathping report is the loss and latency at the destination, and at the hops just before it. A loss percentage shown at one intermediate router, which does not carry through to the hops after it, is usually that router limiting or deprioritising the ICMP replies it generates itself. It is not loss of your traffic.
Loss that starts at some hop and persists through every later hop to the destination is a useful clue to real path loss, but not proof by itself, and not the only shape real loss can take. Each hop answers its own probes and replies by its own return path, load-balanced paths can change hops between cycles, and the destination can also limit or filter what it returns. Before naming a faulty link, back the report with application or endpoint evidence, or ask the provider for interface counters.
Measure from both ends if you can. Use TCP or UDP probes as well as ICMP, because some networks treat ICMP differently. Collect several time-stamped runs that cover the bad period and a good period. Give the provider the destination-level figures, the hop where loss first appears to persist, the source and destination addresses, and the times, and say that the hop is where the measurements point rather than a proven fault location. That is a pack they can act on. A single screenshot with "40% loss at hop 6" usually is not.
Why it matters
A provider's first response to "the link is slow" is often to ask for evidence, and the first evidence many people send is a traceroute or mtr that shows loss at an intermediate hop. If that loss is an ICMP artefact, the provider correctly rejects it, and the real problem waits another round.
Equally, a genuine fault can be dismissed if the evidence does not show the loss reaching the destination, or does not cover the times users complained about.
The existing performance articles under Related articles are about host and storage bottlenecks and file-service tuning. This article is about measuring the network path between two sites, or between a site and a service, and presenting the result.
How it works
What the tools measure
mtr combines traceroute and ping. It sends probes with increasing TTL. Each router that decrements the TTL to zero returns an ICMP Time Exceeded message, and mtr repeats this every cycle to build per-hop loss and round-trip statistics.
Report mode (-r) runs for the number of cycles set by -c and prints statistics. By default mtr uses ICMP Echo. -u switches to UDP, and -T switches to TCP SYN, with -P choosing the target port. The manual notes that with TCP the packet size is ignored, because SYN packets cannot carry data.
pathping on Windows first traces the path, then sends a number of queries to each hop (default 100, /q) at a set period (default 250 ms, /p). It then reports two loss figures:
- "This Node/Link": loss on each link (shown against a vertical bar) and at each router.
- "Source to Here": cumulative loss from the source.
Microsoft's own worked example explains the difference. A link showing 13% loss indicates congestion affecting forwarded traffic. Routers at hops 2 and 4 that drop "packets addressed to them" show that this "doesn't affect their ability to forward traffic that isn't addressed to them".
Why intermediate-hop loss is often not real
A router forwards transit traffic in hardware, but it generates ICMP Time Exceeded and Echo Reply messages in its control plane. Router requirements allow, and in places require, that rate to be limited:
- RFC 1812 says a router "SHOULD also be able to limit the rate at which it sends other sorts of ICMP error messages", including Time Exceeded.
- RFC 4443 requires IPv6 nodes to rate-limit the ICMPv6 errors they originate, and recommends a token bucket.
The mtr manual's BUGS section notes that "some modern routers give a lower priority to ICMP ECHO packets than to other network traffic", so their reported reliability is "significantly lower than the actual reliability".
The practical rule follows from this. Loss that appears at hop N and disappears at hop N+1 is usually not loss of forwarded packets, because the probes to later hops were forwarded through hop N and still got answers. Treat that as a strong clue, not proof: with load balancing (ECMP), probes to different hops can take different routes, and each reply comes back by its own return path.
Latency spikes at one hop
The same applies to latency. A high round-trip time at one intermediate hop, with normal values at later hops, usually reflects slow ICMP generation on that router. A latency step that begins at a hop and carries through to the destination points to the link or queue at that point. Long-distance links will legitimately add a step, so compare against the expected propagation delay for the distance.
Return paths
Each hop's reply returns by that router's own path back to you, which may differ from the forward path. A loss or latency step can therefore come from the reverse direction. That is one reason to run the test from both ends.
Metrics standards
RFC 2681 defines a round-trip delay metric, and RFC 7680 defines one-way packet loss with an explicit waiting time. OWAMP (RFC 4656) and TWAMP (RFC 5357) are protocols for active one-way and two-way measurement between cooperating endpoints. They are outside the scope of a quick diagnosis, but they are the right reference if you and the provider agree on formal measurements.
Read-only checks
None of these was run for this article. Running mtr on Linux usually needs root rights or an installed helper for raw sockets. TCP probes send SYNs to the target port, which may show up in the target's or a firewall's logs, so tell the owner of the destination before you probe it. Keep the rate at the defaults. The mtr manual warns that each running instance "generates a significant amount of network traffic", and Microsoft advises sending pings "at a sufficiently slow pace".
1. Baseline report with ICMP (Linux).
mtr -r -w -n -c 300 <destination>
This sends 300 cycles at the default one-second interval (about five minutes) in wide report mode with numeric addresses. Save the output with the start time and the source address.
2. The same path with TCP to the service port.
mtr -r -w -n -c 300 -T -P 443 <destination>
Use -u for a UDP service. Compare the destination-level figures with the ICMP run.
3. pathping from Windows.
pathping /n <destination>
This uses the defaults of 100 queries per hop and a 250 ms period. The statistics phase takes a few minutes and lengthens with the hop count.
4. Repeat over time. Run the report on a schedule, for example every 15 minutes, through a period users report as bad and a period they report as good. Save each run with a timestamp. mtr can write CSV (-C, semicolon-separated) or JSON (-j, if built with JSON support) for later analysis.
5. Run from the other end. If you control a host at the far site or in the hosting environment, run the same tests back towards your site.
6. Record the context: link type, any VPN in the path, the time zone of the timestamps, and whether a test ran during a backup or replication window.
Interpreting the results
| Pattern in the report | Likely meaning | What to send or do |
|---|---|---|
| Loss at one intermediate hop only; later hops and the destination at 0% | Most often ICMP rate limiting or deprioritisation on that router | Not evidence of a forwarding fault on its own. Do not send it as evidence unless endpoint or application figures also show a problem |
| Loss starts at hop N and persists to the destination at a similar or higher rate | Consistent with real loss at or beyond the link into hop N, in the forward or return direction; return paths, ECMP and sampling can move the apparent hop | Send the destination figures, hop N as the suspected point and timestamps; ask for counters on that link |
| Loss only at the destination | Destination host or its firewall limiting ICMP, or real loss on the last link | Repeat with TCP to the service port for comparison. SYN replies can also be filtered or rate-limited, so check the application or endpoint counters before deciding |
| Latency step at hop N that carries through to the destination | Possibly queueing or distance at or beyond the link into hop N, in either direction; return paths and ECMP can move the apparent hop | Compare with expected distance delay and with good-period runs; name hop N only as the suspected point |
| Latency spike at one hop only | Most likely slow ICMP generation on that router | Not a fault by itself |
| ICMP run clean, TCP run shows loss, or the reverse | Traffic treated differently by protocol | Report the protocol your application uses |
| Bad only at certain times | Congestion or a scheduled job | Send the time series, not a single run |
| pathping: high router loss but 0% on the following link | Router does not answer probes addressed to it | Microsoft example: does not affect forwarding |
Decision guidance
Building the evidence pack
The pack is for the provider. It is not a change to your network.
- Summary line: source and destination addresses, the affected service and port, and the business impact.
- Destination-level figures: loss %, average and worst RTT, for bad and good periods, with timestamps and time zone.
- The first hop where loss or latency appears to persist to the destination, with its address and owner if known (mtr
-zshows AS numbers), labelled as the suspected point. Note that round-trip tests cannot separate forward from return loss. - ICMP and TCP or UDP results, side by side.
- Results from the other end, if available.
- Raw outputs attached, unedited.
Verification: a colleague who did not run the tests can see from the pack where loss appears to begin, when, and what endpoint or application evidence supports it.
Rollback: remove any scheduled test jobs when the case closes.
Local causes to rule out first
- Wi-Fi on the test client, so test from a wired host.
- A saturated local uplink during backups. Check interface counters at the same time as the test.
- A local firewall or VPN appliance under load, where the loss begins at hop 1 or 2.
Rule these out before engaging the provider, because loss that starts at your own edge is yours to fix.
When the provider needs more
If the provider asks for formal measurement, agree on the endpoints, the protocol (for example TWAMP, if both sides support it) and the measurement window. Ad hoc results are useful for triage, but not for an SLA dispute.
What not to do
- Do not send loss at an intermediate hop that does not persist to the destination as proof of a fault.
- Do not run mtr with sub-second intervals or many parallel instances against a provider's routers.
- Do not probe a third party's hosts with TCP or UDP without their consent.
- Do not rely on one run, especially one taken outside the complaint window.
- Do not change MTU, QoS or routing based on a single ICMP report. Confirm with application-level evidence first.
Limitations
- Option names and availability vary between mtr builds. This article uses the mtr 0.95 manual from Debian bookworm.
- ICMP-based tools measure round-trip behaviour and cannot tell forward-path from return-path loss without tests from both ends.
- Load-balanced paths (ECMP) can give different hops on different cycles. mtr shows several addresses for a hop when this happens.
- This article does not measure throughput. Loss and latency figures explain slow transfers, but do not replace an application-level throughput test.
Acceptance checklist
- [ ] Wired test host, source and destination addresses recorded
- [ ] ICMP and TCP or UDP reports saved for bad and good periods, with timestamps and time zone
- [ ] Destination-level loss and latency stated for each period
- [ ] First persistent hop identified, or loss shown to be only at intermediate hops
- [ ] Local causes (Wi-Fi, local uplink, edge appliance) ruled out
- [ ] Results from the other end included, if available
- [ ] Scheduled test jobs removed after the case closes
References
All accessed 2 November 2026.
- mtr(8) manual page, mtr-tiny 0.95, Debian bookworm (report mode, -T, -u, -P, -C, -j, -z, BUGS note on ICMP priority): https://manpages.debian.org/bookworm/mtr-tiny/mtr.8.en.html
- Microsoft Learn, pathping (parameters, defaults, example interpretation): https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/pathping
- RFC 1812, Requirements for IP Version 4 Routers (4.3.2.8 Rate Limiting): https://www.rfc-editor.org/rfc/rfc1812.txt
- RFC 4443, ICMPv6 (2.4(f) rate limiting of originated errors): https://www.rfc-editor.org/rfc/rfc4443.txt
- RFC 2681, A Round-trip Delay Metric for IPPM: https://www.rfc-editor.org/rfc/rfc2681.txt
- RFC 7680, A One-Way Loss Metric for IP Performance Metrics: https://www.rfc-editor.org/rfc/rfc7680.txt
- RFC 4656, One-way Active Measurement Protocol (OWAMP): https://www.rfc-editor.org/rfc/rfc4656.txt
- RFC 5357, Two-Way Active Measurement Protocol (TWAMP): https://www.rfc-editor.org/rfc/rfc5357.txt
Related articles
- IPsec VPN Tunnel Up but No Traffic: Read-Only Diagnosis
- How to diagnose and tune Windows SMB file services on VMware
-
Small Requests Work but Large Transfers Hang: Proving a Path MTU Black Hole
- Connections Half-Work Through Two Gateways: Proving Asymmetric Routing
Learning notes
- Read loss and latency at the destination first. Loss or latency that persists from an intermediate hop to the end is a useful clue, not the only shape real problems take, and even then it points to a suspected location, not a proven one. Use endpoint, application or provider counter evidence before naming a faulty link.
- Routers rate-limit and deprioritise the ICMP they generate themselves, which creates loss that does not affect forwarded traffic.
- Use TCP or UDP probes to the service port, as well as ICMP, and test from both ends where possible.
- Collect time-stamped series covering bad and good periods. One run proves little.
- Hand the provider the destination figures, the first hop where loss appears to persist, the timestamps, the raw outputs and any endpoint or application evidence.