ICMP Time Exceeded (traceroute)

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 (the IP header plus the first 8 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 (typically the IP header plus the first 8 bytes, which includes the source/destination port numbers when the upper-layer protocol is TCP/UDP).

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 (TTL=1→0, but 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)

Linux/macOS traceroute sends packets to a high-numbered UDP port that the destination host normally isn’t using, deliberately triggering a “port unreachable” to detect completion. Because of this, if UDP is blocked by the destination host or a firewall along the path, traceroute may fail to complete even though the destination was actually reached. Windows tracert, on the other hand, uses ICMP Echo Request, so the same kind of problem occurs if ICMP is blocked instead.

Verification on Real Hardware

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
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

Probe (R1 to R4, TTL=1)
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)

ICMP Time Exceeded (R2 to R1)
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: 33434

The 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

ICMP Time Exceeded (R3 to R1)
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: 33437

Notice 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 at the moment it was discarded, not the value it was originally sent with.

Third Hop (TTL=3): Destination Unreachable (Port Unreachable) from Destination R4

Probe (R1 to R4, TTL=3, 1st attempt)
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)

ICMP Destination Unreachable (R4 to R1, Port Unreachable)
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: 33440

The 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.

In the command output, the third hop shows 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 traceroute-xe.pcap

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)