How to read a traceroute and an MTR report

02Traceroute and MTR commands for Linux, macOS and Windows

Trace towards the address that is actually failing, while the problem is happening. A trace taken an hour later proves nothing.

In mtr, -r prints a report after -c cycles, -w keeps long names intact, -b shows names and addresses, and -z adds each hop's AS number, which tells you whose network a router belongs to (see what an ASN is). On Windows, pathping does the job of a report-mode MTR.

# Linux
traceroute -n example.com                  # UDP probes, numeric output
traceroute -n -I example.com               # ICMP echo probes
sudo traceroute -n -T -p 443 example.com   # TCP SYN to port 443
mtr -rwbz -c 100 example.com               # 100-cycle report with IPs and AS numbers
mtr -rwbz -T -P 443 -c 100 example.com     # the same over TCP port 443

# macOS (built-in traceroute; mtr from a package manager, run with sudo)
traceroute -n example.com
traceroute -I -n example.com

# Windows (Command Prompt)
tracert /d example.com
pathping /n example.com

03How to read each line of the output

Each line is one hop: the TTL used, the router that sent the Time Exceeded reply, and the round-trip times to it. MTR adds statistics over all cycles. Hostnames often encode a city or interface, but they can be stale; trust the address and AS number more.

In the sample report below, read from the bottom up. The destination at hop 7 shows no loss and a stable 17 ms, so the path works. Hop 4 shows 62% loss and erratic times, but hops 5 to 7 behind it are clean, which means hop 4 forwards traffic perfectly and is merely slow to answer probes addressed to itself. That is not a fault.

• Loss%: the share of probes to this hop that received no reply
• Snt: the number of probes sent to this hop
• Last, Avg, Best, Wrst: the latest, average, lowest and highest round-trip time in milliseconds
• StDev: how much the round-trip time varies; high values mean jitter
• AS column (-z): the autonomous system that announces the hop's address

Start: 2026-10-24T09:12:03+0000
HOST: client                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.1.1         0.0%   100    0.6   0.7   0.4   2.1   0.2
  2. AS64496  198.51.100.1        0.0%   100    7.9   8.3   7.1  14.2   1.0
  3. AS64496  198.51.100.45       0.0%   100    8.8   9.1   8.2  12.7   0.7
  4. AS64500  203.0.113.9        62.0%   100   41.3  38.9  15.2  97.4  18.6
  5. AS64500  203.0.113.30        0.0%   100   16.1  16.4  15.8  19.9   0.6
  6. AS64511  192.0.2.1           0.0%   100   16.8  17.0  16.3  21.5   0.8
  7. AS64511  192.0.2.80          0.0%   100   17.2  17.1  16.5  20.3   0.6

04What do asterisks, missing hops and !H mean?

An asterisk means no reply arrived for that probe before the timeout. A row of asterisks in the middle of a trace that still reaches its destination means that router does not send Time Exceeded messages, filters them, or rate-limits them; the later hops prove the path continues. Microsoft's tracert documentation says the same: some routers never return these messages and are invisible to the tool.

Asterisks from some hop to the end are different. Either the path really stops there, or the destination and the routers near it filter that probe type. Repeat the test with TCP to a port the service listens on, such as 443, before concluding anything. Linux traceroute also annotates replies: !H, !N and !P mean host, network or protocol unreachable, and !X means communication administratively prohibited, usually a firewall answering.

MPLS backbones can hide interior hops, so a long stretch appears as one hop with a large latency step; mtr -e shows MPLS labels where routers include them.

05When packet loss and latency are real, and when they are not

Routers forward transit packets in hardware but generate ICMP replies in software, and they are expected to limit how fast they do it. RFC 1812 says a router SHOULD be able to rate-limit ICMP error messages, Time Exceeded included, and RFC 4443 makes rate limiting mandatory for ICMPv6 errors. A router answering probes slowly or not at all tells you about its CPU policy, not about your traffic.

Latency needs the same discipline. A jump that persists to the end of the trace is real distance or real queueing. Distance sets a floor: light in optical fibre travels at roughly 200,000 km/s, about two thirds of its speed in a vacuum, so every 1,000 km of fibre adds about 10 ms of round-trip time (2 x 1,000 km / 200,000 km/s). A 70 ms step on a transatlantic hop is physics; the same step between two routers in one city that persists to the destination is congestion.

HOST: client                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  4. AS64500  203.0.113.9         0.0%   100   15.9  16.0  15.4  18.8   0.5
  5. AS64511  192.0.2.1          17.0%   100   88.2  71.5  16.9 143.0  31.2
  6. AS64511  192.0.2.33         18.0%   100   90.1  73.0  17.2 150.1  32.8
  7. AS64511  192.0.2.80         17.0%   100   86.7  72.4  17.0 139.6  30.5

06Asymmetric paths: the half traceroute cannot show

A traceroute shows the forward path only. Replies return along whatever route the far end chooses, which is often a different one, and a problem on the return path still shows up as loss or latency in your trace, attributed to hops that may be perfectly healthy. Routing between networks is decided by each network's BGP policy, which is why the two directions differ.

APNIC's guide to interpreting traceroutes recommends tracing from both ends. Ask for a trace back towards your address, or use a looking glass in the destination network, before blaming the first suspicious hop.

07What to send your provider when reporting packet loss

A report that shows loss continuing to the destination, measured properly, gets taken seriously; one built on a single mid-path hop usually does not.

• An mtr report with at least 100 cycles (mtr -rwbz -c 100), or WinMTR output exported as text, taken while the problem occurs
• The same test over TCP to the affected port (mtr -T -P 443) if the ICMP results are ambiguous
• A trace in the reverse direction, from the server towards your public address, if you can get one
• Your public IP address, the destination address, the date and time with time zone, and whether it was IPv4 or IPv6
• A baseline report from a time when the service worked, and what the application experienced since when

08Reading a traceroute during a DDoS attack

When a volumetric attack saturates the links into a target, the trace shows loss and latency that begin at the last hops before the target and persist to it, often starting inside the target's own provider. A UDP flood or a ping flood against a game server typically looks like this from every vantage point at once.

If the provider null-routes the attacked address to protect the rest of its network, traces stop at or near the provider's edge and the destination never answers, from anywhere. That outcome, the service offline although nothing is wrong with it, is the problem that filtered transit is meant to solve; see DDoS protection for game servers.