ICMP and Traceroute: How the Network Reports Errors, and How to Map a Path

The picture: returned post and a game of how-far#

When a letter cannot be delivered, the post office sends it back with a short note: “no such address” or “moved away”. It does not fix the problem. It just tells you what went wrong. ICMP is that note for the Internet.

Now a game. You want to know every post office between you and a friend. Each letter carries a few boxes, and the rule is: “each office ticks one box; whoever ticks the last box sends the letter back to me”. A one-box letter comes back from the first office. A two-box letter comes back from the second. Keep going until a letter reaches your friend. That is traceroute.

Vocabulary, before anything uses it#

What ICMP is and where it lives#

ICMP does two jobs. It reports errors, such as “I could not reach that network” or “this datagram ran out of TTL”. And it carries echo tests, which ping uses.

ICMP counts as part of the network layer, because every IP host and router must handle it. But its messages travel inside IP datagrams, like a TCP or UDP segment, with the IPv4 protocol field set to 1. So ICMP sits just above IP while doing network-layer work.

Every ICMP message starts with a 1-byte type, a 1-byte code and a 2-byte checksum. Then come 4 bytes whose meaning depends on the type, making an 8-byte header. An error message then carries the IP header of the datagram that caused it, plus that datagram’s first 8 data bytes (RFC 792; many routers include more). Those 8 bytes hold the TCP or UDP port numbers, so the sender can tell which connection the error is about.

To stop errors breeding errors, no ICMP error is ever sent about another ICMP error.

The type and code table#

A detail that catches people out: a TCP segment to a closed port gets a TCP reset (RST) back, not ICMP 3/3.

Ping: echo request and echo reply#

Ping is the simplest ICMP tool. It sends an echo request (type 8, code 0) to a host. If the host is up and willing, it sends back an echo reply (type 0, code 0) carrying the same data. Ping matches replies to requests by an identifier and a sequence number, and prints each RTT and the total lost.

No reply does not prove a host is down: many firewalls block echo requests on purpose.

How traceroute works#

Traceroute turns the TTL rule into a map. Classic traceroute (on Linux and macOS) works like this:

1. Send a UDP probe to the destination with TTL = 1. The first router lowers the TTL to 0, drops the probe, and sends back ICMP 11/0, TTL expired. The reply’s source address names that router, and its timing gives the RTT.
2. Send probes with TTL = 2. They pass the first router and die at the second, which sends back 11/0. Now you know router 2.
3. Keep adding 1 to the TTL. Each step reveals one more router.
4. Eventually a probe reaches the destination host. Probes go to a deliberately unlikely UDP port (by default starting at 33434, rising with each probe), so nothing is listening. The host sends back ICMP 3/3, port unreachable: the signal to stop.

By default traceroute sends three probes per TTL, so each line shows three times, and gives up after 30 hops. Windows tracert uses the same TTL trick with ICMP echo requests instead of UDP, and stops at an echo reply.

Reading traceroute output#

Here is a made-up run:

$ traceroute www.dest.example
traceroute to www.dest.example (203.0.113.80), 30 hops max
 1  gw.lan.example (192.0.2.1)                 1.204 ms   0.981 ms   1.112 ms
 2  edge-1.isp.example (198.51.100.1)          9.874 ms  10.231 ms   9.660 ms
 3  agg-2.isp.example (198.51.100.17)         11.402 ms  12.018 ms  11.377 ms
 4  core-atl.isp.example (198.51.100.33)      14.951 ms  15.230 ms  14.889 ms
 5  * * *
 6  core-nyc.transit.example (198.51.100.65)  31.540 ms  31.112 ms  32.008 ms
 7  core-lon.transit.example (198.51.100.81) 104.887 ms 105.301 ms 104.652 ms
 8  www.dest.example (203.0.113.80)          106.214 ms 105.990 ms 106.433 ms

• Each line is one TTL value, so one router (or the destination): its name if a reverse DNS lookup (asking DNS for the name that belongs to an IP address) finds one, its IP address, then three RTTs.
• Hop 5 shows * * *: none of its three probes got a reply in time. The router still forwards traffic, since hop 6 answers. It just did not send ICMP back, often by configuration or rate limiting.
• Hop 8 is the destination. It answered port unreachable (3/3), so traceroute stopped.
• Look for jumps. A big RTT jump between two hops often means a long link between them.

Two cautions. Routers give ICMP replies low priority, so a hop can show a higher RTT than a later one. And the return path can differ from the outward one.

IPv6 has its own version, ICMPv6 (RFC 4443, next header value 58). It does the same jobs, has its own “Packet Too Big” message (IPv6 routers never fragment, so it does the job of IPv4’s 3/4), and replaces ARP (Address Resolution Protocol) with neighbor discovery.

Practice#

For every question, ask two things: who sends the message (a router in the middle, or the destination), and which type and code it is.

1. What IPv4 protocol number marks an ICMP message, and why is ICMP still called a network-layer protocol?
2. A host sends a datagram with TTL 4 to a destination 7 routers away. Which router drops it, and what ICMP type and code does the host get back?
3. A UDP datagram reaches its destination host, but no program is listening on the destination port. What comes back? What changes if it was a TCP segment instead?
4. You ping with 100 bytes of data. How big is the ICMP message, and how big is the IPv4 datagram?
5. A traceroute reaches its destination at hop 11, and every probe is answered. How many probes were sent, and how many of each ICMP message came back? (Three probes per hop.)
6. In the traceroute output above, what does hop 5’s * * * mean, and how do you know the router at hop 5 still forwarded traffic?
7. Why does traceroute send its UDP probes to an unlikely port number?
8. A traceroute line shows RTTs of 48 ms, 47 ms and 49 ms at hop 6, but 41 ms, 42 ms and 40 ms at hop 7. Give one reason a later hop can show a lower RTT.

Solutions#

1. Protocol 1. ICMP rides inside IP datagrams like a segment. But every IP host and router must implement it, and it reports network-layer events such as unreachable networks and expired TTLs.
2. Router 4; type 11, code 0 (TTL expired). The TTL goes 4 → 3 at router 1, → 2 at router 2, → 1 at router 3, and → 0 at router 4, which drops the datagram.
3. ICMP type 3, code 3 (port unreachable), from the destination host. For a TCP segment to a closed port, the host replies with a TCP reset (RST) instead.
4. 108-byte ICMP message; 128-byte IPv4 datagram. 100 + 8 (ICMP header) = 108, and 108 + 20 (IPv4 header) = 128.
5. 33 probes; 30 TTL-expired (11/0) and 3 port-unreachable (3/3). 11 × 3 = 33. Hops 1 to 10 are routers: 10 × 3 = 30 replies of 11/0. The destination answers its 3 with 3/3.
6. None of hop 5’s three probes got an ICMP reply. Yet hops 6, 7 and 8 answered, and their probes had to pass through hop 5.
7. So the destination answers port unreachable (3/3). If a program were listening, it would get the probe and no ICMP would come back, so traceroute could not tell it had arrived.
8. Routers make ICMP replies a low priority. Hop 6 may be slow to generate its reply while still forwarding traffic quickly. The return paths can also differ.

Test-readiness checklist#

• ☐  I can say what ICMP is for and that it travels inside IP datagrams with protocol number 1.
• ☐  I can give the type and code for echo request, echo reply, TTL expired, and the five destination-unreachable codes in the table.
• ☐  I can say whether each message comes from a router in the middle or from the destination host.
• ☐  I can work out ping message and datagram sizes from the data size.
• ☐  I can explain traceroute step by step, including why it uses an unlikely UDP port and when it stops.
• ☐  I can count the probes and ICMP replies in a traceroute run.
• ☐  I can read traceroute output, including * * * lines and RTT jumps.

Frequently asked questions#

Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.