ping, traceroute, and mtr - path diagnosis

Reachability tools - ping, traceroute, mtr, tracepath - answer the question “can I get there, and if not, where is it broken?”. They are the first tools to reach for when an application is unreachable.

ping

ping sends ICMP Echo Request and measures Echo Reply:

ping 10.0.0.1                    # basic
ping -c 5 10.0.0.1               # 5 packets, then stop
ping -W 2 10.0.0.1               # 2s timeout per packet
ping -i 0.2 10.0.0.1             # 5 packets per second
ping -s 1472 -M do 10.0.0.1      # 1500-byte packet, DF set
ping6 fe80::1%eth0               # IPv6 link-local with zone

Output:

PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.123 ms
64 bytes from 10.0.0.1: icmp_seq=2 ttl=64 time=0.156 ms
64 bytes from 10.0.0.1: icmp_seq=3 ttl=64 time=0.142 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2043ms
rtt min/avg/max/mdev = 0.123/0.140/0.156/0.014 ms

Reading this:

• Success rate: should be 100% on a healthy network.
• Latency: under 1 ms on a LAN, under 50 ms on a metro link, under 200 ms on a transcontinental link.
• TTL: starts at 64 or 255 and decreases by 1 each hop. An unusual TTL can hint at an intermediate device.

Failure modes

“Destination Host Unreachable”: the local host has no route. Check ip route get.

“Request timed out”: packets were sent but no reply. Either the remote is down, or a firewall is silently dropping ICMP.

“100% packet loss, but the host responds to other things”: the host or an intermediate firewall is blocking ICMP for this source.

traceroute

traceroute walks the path to a destination by manipulating TTL:

traceroute 8.8.8.8                     # default UDP method, no privileges needed
traceroute -n 8.8.8.8                  # no DNS resolution
traceroute -U -p 33434 8.8.8.8         # explicit UDP
sudo traceroute -T -p 443 8.8.8.8      # TCP SYN, port 443 - raw sockets
sudo traceroute -I 8.8.8.8             # ICMP instead of UDP

Note which of those need sudo. The default UDP method is explicitly allowed for unprivileged users. -T opens raw sockets and therefore needs root or CAP_NET_RAW; -I may run unprivileged on kernel 3.0 and later where datagram ICMP sockets are permitted by net.ipv4.ping_group_range, and otherwise needs the same privileges. If you reach for the modes that get through firewalls, expect to reach for sudo with them.

Output:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max
 1  10.0.0.1 (10.0.0.1)       0.412 ms
 2  10.10.0.1 (10.10.0.1)     4.231 ms
 3  192.168.1.1 (192.168.1.1)  8.123 ms
 4  * * *
 5  72.14.215.85 (72.14.215.85)  12.456 ms
 ...

Hop 4 shows * * * - no response. This usually means the router at hop 4 rate-limits or suppresses ICMP Time Exceeded (most production routers do this). The proof that the path is intact is that hop 5 answers: traffic is transiting hop 4 normally, the router is just not talking about itself.

sudo traceroute -T (TCP) often works where UDP/ICMP fail because TCP SYN packets are almost always permitted.

mtr

mtr combines ping and traceroute. It runs continuously and shows loss and latency statistics per hop:

mtr 8.8.8.8                      # interactive
mtr -n 8.8.8.8                   # no DNS
mtr -r -c 100 8.8.8.8            # report mode, 100 cycles
sudo mtr -T -P 443 8.8.8.8       # TCP mode - raw sockets, needs privileges

Output (report mode):

Host                  Loss%  Snt   Last   Avg  Best  Wrst  StDev
1. 10.0.0.1            0.0%  100    0.4   0.4   0.3   0.7   0.1
2. 10.10.0.1           0.0%  100    4.2   4.3   4.1   5.2   0.2
3. 192.168.1.1         0.0%  100    8.1   8.2   7.9   9.1   0.3
4. ???                100.0%  100    0.0   0.0   0.0   0.0   0.0
5. 72.14.215.85        0.0%  100   12.4  12.5  12.2  14.1   0.4
6. 8.8.8.8             0.0%  100   13.1  13.2  13.0  14.5   0.3

Reading this:

• A hop showing 100% loss but later hops showing 0% loss is almost always a router that de-prioritises ICMP (rate-limit). The route is working; the router just doesn’t reply.
• A hop showing loss AND the same percentage of loss on all later hops indicates the loss is real - it happened at that hop.
• Sudden latency increase at a specific hop = congestion or routing change at that hop.

tracepath

tracepath is like traceroute but does not require root (unprivileged UDP), and reports the path MTU:

tracepath 8.8.8.8
tracepath -m 5 8.8.8.8           # max hops 5

Output includes pmtu lines showing the discovered path MTU.

Asymmetric routes

traceroute shows the forward path. To see the return path, traceroute from the destination back to the source (if you can). Asymmetric routes are normal in production networks but complicate firewall rules that assume symmetry.

mtr -z shows AS numbers per hop, useful for understanding upstream paths.

Common diagnostic patterns

Knowledge check