What is ICMP Time Exceeded
ICMP Time Exceeded (Type 11) is an error message that notifies the sender that the TTL (Time To Live) in an IPv4 header reached zero, or that fragment reassembly timed out. It is defined in RFC 792.
TTL exists to prevent a packet from looping forever on the network, and is decremented by 1 at every router it passes through. A packet whose TTL reaches zero is not forwarded any further and is discarded by the router at that point. The discarding router sends a Time Exceeded message to inform the sender that the packet was lost.
| Code | Meaning |
|---|---|
| 0 | TTL exceeded in transit: the TTL reached zero while the packet was being forwarded (most common) |
| 1 | Fragment reassembly time exceeded: fragment reassembly did not complete within the allotted time |
Packet Format
The “Rest of Header” of a Time Exceeded message is unused (zero-filled), and the Data field contains a portion of the original IP packet that caused the problem (at minimum the IP header plus the first 8 bytes per RFC 792; RFC 1812 recommends including as much as possible without the ICMP message exceeding 576 bytes). This lets the sender identify which packet was discarded.
| Field Name | Size | Description |
|---|---|---|
| Type | 1 byte | Fixed at 11. |
| Code | 1 byte | 0 (TTL exceeded) or 1 (fragment reassembly timeout). |
| Checksum | 2 bytes | An error-detection value covering the entire ICMP message. |
| Unused | 4 bytes | Unused. All 0. |
| Data | Variable | A portion of the discarded original IP packet (at minimum the IP header plus the first 8 bytes; when the upper-layer protocol is TCP/UDP, those 8 bytes include the source/destination port numbers). |
How traceroute Works
traceroute deliberately triggers this Time Exceeded message to identify, one hop at a time, the routers along the path to a destination. It sends packets to the same destination with an increasing TTL starting from 1, recording which router discarded the packet at each TTL value.
An example of running traceroute from R1 (192.168.0.1) to R4 (192.168.3.1), with R2 and R3 along the path:
sequenceDiagram
participant R1 as R1
participant R2 as R2 (Hop1)
participant R3 as R3 (Hop2)
participant R4 as R4 (Hop3, destination)
Note over R1: Sends a packet with TTL=1
R1->>R2: Packet (TTL=1→0, discarded)
R2-->>R1: ICMP Time Exceeded (Type 11, Code 0)
Source: R2's IP address
Note over R1: Sends a packet with TTL=2
R1->>R2: Packet (TTL=2→1, passes through)
R2->>R3: Packet (TTL=1→0, discarded)
R3-->>R1: ICMP Time Exceeded (Type 11, Code 0)
Source: R3's IP address
Note over R1: Sends a packet with TTL=3
R1->>R2: Packet (TTL=3→2, passes through)
R2->>R3: Packet (TTL=2→1, passes through)
R3->>R4: Packet (arrives with TTL=1, reaches destination)
Note over R4: The destination host returns
Destination Unreachable (Port) for UDP,
or an Echo Reply for ICMP
- Sending a packet with TTL=1 causes the TTL to reach zero at the first hop, R2, which discards it. R2 returns a Time Exceeded message with its own IP address as the source, revealing that the first-hop device is R2.
- Sending a packet with TTL=2, R2 forwards it but it is discarded at R3. A Time Exceeded from R3 reveals that the second hop is R3.
- This is repeated with the TTL incremented by 1 each time, continuing until the packet finally reaches the destination, R4.
- Once the destination is reached, the packet is not forwarded any further, so no Time Exceeded is generated. traceroute finishes once it receives the destination host’s own response (described below).
Probe Packet Differences Across Operating Systems
While the basic principle of “send with an increasing TTL” is common, the actual protocol used for probe packets differs by OS — which also determines what response is used to detect that the destination has been reached.
| OS/Device | Command | Default Probe | Response on Reaching the Destination |
|---|---|---|---|
| Linux/macOS | traceroute | UDP (uses disposable destination ports starting at 33434) | ICMP Destination Unreachable (Port Unreachable, Code 3) |
| Windows | tracert | ICMP Echo Request | ICMP Echo Reply |
| Cisco IOS XE | traceroute | UDP (destination ports starting at 33434) | ICMP Destination Unreachable (Port Unreachable) |
tracert, on the other hand, uses ICMP Echo Request, so the same kind of problem occurs if ICMP is blocked instead.Verification on Real Devices
R1 through R4 (Cisco IOS XE) are connected in series as shown below, with each router configured with a static (default) route pointing toward its neighbor. Because each router’s route chains to the next, full bidirectional reachability exists across R1-R4, not just in the R1-to-R4 direction (this return path is also what lets the Time Exceeded and Destination Unreachable messages make it back from R2, R3, and R4 to R1). We ran traceroute 10.3.4.4 from R1 and confirmed the behavior of Cisco IOS XE’s traceroute (UDP probes) with a packet capture.
traceroute Command Output
R1#traceroute 10.3.4.4
Type escape sequence to abort.
Tracing the route to 10.3.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.2.2 7 msec 4 msec 3 msec
2 10.2.3.3 4 msec 3 msec 3 msec
3 10.3.4.4 78 msec * 11 msec
R1#Cisco IOS XE’s traceroute sends 3 probes per TTL value and displays the round-trip time for each. The first and second hops return Time Exceeded from R2 (10.1.2.2) and R3 (10.2.3.3) respectively, and the third hop shows that the destination R4 (10.3.4.4) was reached. The second probe at the third hop shows * (no response / timeout), and indeed the capture contains no reply packet for that particular probe.
Packet Capture
The source port increments by one for each probe (49154, 49155, …), and the destination port increments in the same way (33434, 33435, …). Since the UDP probe itself carries no sequence-number-like identifier, the combination of port numbers is what lets the sender match a reply to a specific probe.
First Hop (TTL=1): Time Exceeded from R2
These are packets No.1 (the probe) and No.2 (the Time Exceeded) of the attached capture.
Download just these No.1 and No.2 (traceroute-xe-no1-2.pcap)Ethernet II, Src: 52:54:00:2a:86:3e, Dst: 52:54:00:a8:33:3e
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.1.2.1, Dst: 10.3.4.4
Time to Live: 1
Protocol: UDP (17)
Total Length: 28
User Datagram Protocol, Src Port: 49154, Dst Port: 33434
Length: 8 (0 bytes of data)Ethernet II, Src: 52:54:00:a8:33:3e, Dst: 52:54:00:2a:86:3e
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.1.2.2, Dst: 10.1.2.1
Time to Live: 255
Protocol: ICMP (1)
Total Length: 56
Internet Control Message Protocol
Type: 11 (Time Exceeded)
Code: 0 (TTL exceeded in transit)
Checksum: 0x0f22
Unused: 0x00000000
[Original Datagram]
Internet Protocol Version 4, Src: 10.1.2.1, Dst: 10.3.4.4, Time to Live: 1
User Datagram Protocol, Src Port: 49154, Dst Port: 33434The probe sent with TTL=1 was discarded at R2, which returned a Time Exceeded message with itself (10.1.2.2) as the source.
Second Hop (TTL=2): Time Exceeded from R3
This is the Time Exceeded that appears as packet No.8 of the attached capture (the matching probe is No.7). In the extracted file, No.7 appears as No.1 and No.8 as No.2.
Download just these No.7 and No.8 (traceroute-xe-no7-8.pcap)Ethernet II, Src: 52:54:00:a8:33:3e, Dst: 52:54:00:2a:86:3e
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.2.3.3, Dst: 10.1.2.1
Time to Live: 254
Protocol: ICMP (1)
Total Length: 56
Internet Control Message Protocol
Type: 11 (Time Exceeded)
Code: 0 (TTL exceeded in transit)
Checksum: 0x0f22
Unused: 0x00000000
[Original Datagram]
Internet Protocol Version 4, Src: 10.1.2.1, Dst: 10.3.4.4, Time to Live: 1
User Datagram Protocol, Src Port: 49157, Dst Port: 33437Notice that the source has changed to R3 (10.2.3.3). The probe itself was sent with TTL=2 (as captured on the R1-R2 segment, TTL was 2), but it gets decremented from 2 to 1 while passing through R2, and is then discarded at R3 when it reaches 0. As a result, the TTL of the original packet embedded in the Time Exceeded message is 1 — the value it had when R3, the router that discarded it, received it, not the value R1 originally sent it with.
Third Hop (TTL=3): Destination Unreachable (Port Unreachable) from Destination R4
These are packets No.13 (the probe) and No.14 (the Port Unreachable) of the attached capture. In the extracted file, No.13 appears as No.1 and No.14 as No.2.
Download just these No.13 and No.14 (traceroute-xe-no13-14.pcap)Ethernet II, Src: 52:54:00:2a:86:3e, Dst: 52:54:00:a8:33:3e
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.1.2.1, Dst: 10.3.4.4
Time to Live: 3
Protocol: UDP (17)
Total Length: 28
User Datagram Protocol, Src Port: 49160, Dst Port: 33440
Length: 8 (0 bytes of data)Ethernet II, Src: 52:54:00:a8:33:3e, Dst: 52:54:00:2a:86:3e
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.3.4.4, Dst: 10.1.2.1
Time to Live: 253, DSCP: CS6 (0xc0)
Protocol: ICMP (1)
Total Length: 56
Internet Control Message Protocol
Type: 3 (Destination Unreachable)
Code: 3 (Port Unreachable)
Checksum: 0x171f
Unused: 0x00000000
[Original Datagram]
Internet Protocol Version 4, Src: 10.1.2.1, Dst: 10.3.4.4, Time to Live: 1
User Datagram Protocol, Src Port: 49160, Dst Port: 33440The TTL=3 probe passes through R2 and R3 (TTL 3 to 2 to 1) and reaches R4. Since no process is listening on destination port 33440, R4 returns an ICMP Destination Unreachable (Type 3, Code 3: Port Unreachable). As described earlier, the Type being 3 (instead of 11) and the source being the destination host R4 itself are what let traceroute recognize that the destination has been reached.
78 msec * 11 msec — the second probe timed out (*). In the actual capture, the 1st and 3rd probes (source ports 49160 and 49162) each receive a Port Unreachable reply about 0.06 seconds later, but no reply packet was recorded for the 2nd probe (source port 49161) — confirming that R1 waited roughly 3 seconds for a response before sending the next probe. Download R1 config (r1_icmp-time-exceeded.cfg)
Download R2 config (r2_icmp-time-exceeded.cfg)
Download R3 config (r3_icmp-time-exceeded.cfg)
Download R4 config (r4_icmp-time-exceeded.cfg)
References
- RFC 792 - Internet Control Message Protocol
- RFC 1812 - Requirements for IP Version 4 Routers (recommendation to include up to 576 bytes of the original packet, §4.3.2.3)