The most surprising thing about ping, traceroute, and mtr is how little they actually tell you about why a packet is taking a certain path, or why it’s slow. They show you what happened, but the "why" is often hidden in plain sight.
Let’s see them in action. First, ping. It’s the simplest: send a packet, wait for a reply.
ping google.com
PING google.com (142.250.184.142) 56(84) bytes of data.
64 bytes from 142.250.184.142 (142.250.184.142): icmp_seq=1 ttl=118 time=15.4 ms
64 bytes from 142.250.184.142 (142.250.184.142): icmp_seq=2 ttl=118 time=15.2 ms
64 bytes from 142.250.184.142 (142.250.184.142): icmp_seq=3 ttl=118 time=15.3 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 15.200/15.300/15.400/0.100 ms
This tells you if the host is reachable and how long it takes for a round trip. High latency or packet loss here points to a problem somewhere between you and google.com. But where?
That’s where traceroute comes in. It maps the path by sending packets with increasing Time To Live (TTL) values. Each router that sees the packet decrements the TTL. When TTL hits zero, the router sends back an ICMP "Time Exceeded" message.
traceroute google.com
traceroute to google.com (142.250.184.142), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 1.234 ms 1.123 ms 1.098 ms
2 10.0.0.1 (10.0.0.1) 10.567 ms 10.456 ms 10.345 ms
3 some.isp.router.net (XX.XX.XX.XX) 12.789 ms 12.678 ms 12.567 ms
4 another.isp.router.net (YY.YY.YY.YY) 15.901 ms 15.890 ms 15.789 ms
5 ...
9 google-gw.net (ZZ.ZZ.ZZ.ZZ) 15.500 ms 15.400 ms 15.300 ms
10 142.250.184.142 (142.250.184.142) 15.450 ms 15.350 ms 15.250 ms
Each line is a hop. The numbers are the round-trip times to that router. Notice the three probes per hop; this helps smooth out jitter. If you see a jump in latency or a * * * (timeout) at a specific hop, that’s where the problem likely is.
However, traceroute has a limitation: it only sends three packets to each hop. It doesn’t show you intermittent problems. This is where mtr (My Traceroute) shines. It’s a fusion of ping and traceroute, continuously probing each hop.
mtr google.com
Start: Tue May 23 10:00:00 2023
HOST: my-laptop Loss% Snt Last Avg Best Wrst StDev
1._gateway 0.0% 10 1.0 1.2 1.0 2.0 0.4
2.10.0.0.1 0.0% 10 10.5 10.4 10.3 10.6 0.1
3.some.isp.router.net 0.0% 10 12.7 12.6 12.5 12.8 0.1
4.another.isp.router.net 5.0% 10 15.8 17.2 15.8 25.0 3.0
5. ...
10.142.250.184.142 0.0% 10 15.3 15.4 15.2 15.5 0.1
mtr gives you a live view. You can watch the Loss%, Avg, Best, Wrst (worst), and StDev (standard deviation) for each hop. This is invaluable for spotting packet loss that traceroute might miss. If hop 4 shows a consistent 5% loss and higher average latency compared to hop 3, the problem is likely at or after hop 4, but before hop 5.
The core problem these tools solve is isolating network bottlenecks. When you can’t reach a service, or it’s slow, the network path is a black box. ping tells you if the box is working at all. traceroute and mtr let you look inside, hop by hop, to see where the delay or blockage is occurring.
A key detail often overlooked is that ICMP (the protocol used by ping and traceroute/mtr for control messages) can be rate-limited or blocked by network devices. If you see * * * for a hop, it doesn’t always mean the router is down or dropping packets. It could just be that the router isn’t sending back ICMP "Time Exceeded" messages, or your own firewall is blocking them. This is why mtr’s statistical view is so powerful – it can show you loss after a hop that might be silent.
The next hurdle to clear is understanding how DNS resolution affects your initial ping or mtr targets, and how that might mask or introduce latency into your tests before the actual network path is even measured.