Ping and traceroute
ping sends ICMP echo requests and reports replies, round-trip time and loss. It tests the whole path both ways: a ping can fail because the reply can't get back, even when the request arrived fine.
Read the reply line:
ttl=63: replies usually start at TTL 64 (Linux) or 128 (Windows) and lose one per router. Here 64 − 63 = one hop.time=: round-trip latency. Watch for jumps, not absolute values.- The summary: packet loss and min/avg/max/mdev (jitter).
tracepath and traceroute reveal the path by sending packets with increasing TTL. Each router that decrements a TTL to zero sends back an ICMP "time exceeded", identifying itself. tracepath needs no root and also discovers the path MTU. traceroute sends three probes per hop by default (UDP; -I for ICMP, -T for TCP).
Always add -n to skip reverse DNS lookups. Without it, a broken resolver makes every hop look slow.
A row of * * * doesn't necessarily mean a problem: many routers rate-limit or drop the ICMP that traceroute relies on. Look at where the path stops completing, not at individual silent hops.
Interactive: Ping, hop by hop Run a single ping and watch it cross the router and come back. The terminal shows the real output from the lab. (needs JavaScript)
root@client:~# ping -c 3 198.51.100.20
PING 198.51.100.20 (198.51.100.20) 56(84) bytes of data.
64 bytes from 198.51.100.20: icmp_seq=1 ttl=63 time=0.059 ms
64 bytes from 198.51.100.20: icmp_seq=2 ttl=63 time=0.215 ms
64 bytes from 198.51.100.20: icmp_seq=3 ttl=63 time=0.272 ms
--- 198.51.100.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2085ms
rtt min/avg/max/mdev = 0.059/0.182/0.272/0.090 ms
root@client:~# tracepath -n 198.51.100.20
1?: [LOCALHOST] pmtu 1500
1: 192.0.2.1 0.054ms
1: 192.0.2.1 0.014ms
2: 198.51.100.20 0.041ms reached
Resume: pmtu 1500 hops 2 back 2
root@client:~# traceroute -n 198.51.100.20
traceroute to 198.51.100.20 (198.51.100.20), 30 hops max, 60 byte packets
1 192.0.2.1 0.244 ms 0.200 ms 0.188 ms
2 198.51.100.20 0.178 ms 0.154 ms 0.140 ms- Lines 3–5:
ttl=63: the server sent 64 and one router decremented it. Sub-millisecond times because it's all on one machine. - Lines 8–9: The summary to read first: loss, then min/avg/max and mdev (jitter).
- Line 11: tracepath works out the path MTU as it goes: 1500 bytes end to end.
- Lines 12–14: Hop 1 is the router, hop 2 the destination. tracepath may probe a hop more than once.
- Line 15:
hops 2 back 2: the reply path is the same length, so the path looks symmetric. - Lines 18–19: traceroute: three probes per hop, so three times per line.
Interactive: How traceroute finds the path Each probe starts with a TTL one higher than the last, so it dies one hop further along and that router reveals itself. The round-trip times are the real ones from the lab. Tick the box to see what a router that doesn't answer looks like. (needs JavaScript)
Check your understanding
traceroute to a website shows * * * for hops 4 to 6, then reaches the destination at hop 7. What does this mean?
- Packets are being lost at hops 4–6
- Those routers don't send (or rate-limit) ICMP time-exceeded messages; the path itself works
- DNS is broken for those hops
- There's a routing loop