ping says the destination is far or near; traceroute and mtr say where along the path the trouble lives. traceroute takes one snapshot of the route; mtr combines traceroute with ping statistics over time — the live view that pinpoints the lossy or slow hop.

traceroute: the path itself #

Follow the packets to a host
$ traceroute aospix.com
 1  router.lan (192.168.1.1)   1.2 ms
 2  isp-gw.net (81.x.x.1)      9.8 ms
 5  cloudflare.net (104.21.x)  12.4 ms

Each line is one hop: a router that forwarded your probe packet and reported back. The times are per-probe round trips at that hop — the shape to read is where times jump, not any single number. A path that goes 2ms → 9ms → 180ms → 181ms is telling you the cost was added at hop 3; everything after inherits it.

Two mechanics worth knowing: routers rank probe packets as low-priority, so a single hop showing stars or a spike while later hops are fast is a router that deprioritised the reply, not a broken link. Judge by the destination, not by one rude middleman.

mtr: the statistics #

Live path quality, updating in place
$ mtr aospix.com
                             Loss%  Snt  Last  Avg  Best  Wrst
 1. router.lan                 0.0   60   1.1  1.2   0.9   3.0
 2. isp-gw.net                40.0   60   9.8 10.1   8.9  15.2
 3. ...                        0.0   60  11.9 12.0  11.5  13.9

The interpretation rule that makes mtr worth installing: loss that appears at one hop and continues to the end is real; loss at one hop that disappears later is that router deprioritising replies. In the sample above, hop 2 shows 40% but hop 3 is clean — cosmetic. Loss starting at hop 5 and persisting to the destination is a genuine problem at hop 5.

The report form, for tickets and logs
$ mtr -rw -c 100 aospix.com > mtr-report.txt

-rw (report, wide) runs a fixed count and prints a summary — exactly what an ISP ticket wants attached, and what a monitoring script can email on a bad night.

The flags that matter #

FlagToolEffect
-nbothNo DNS — IPs only, faster and often clearer
-c NmtrFixed cycles for reports
-rwmtrReport mode
-T / -utracerouteTCP/UDP probes — ICMP-blocked paths
-i SmtrInterval between probes

-T (TCP traceroute) matters on paths where ICMP is filtered but TCP passes — the case for diagnosing "the site loads slowly" against a server that blocks ping.

Both tools read the interfaces ip configured. The network series continues.