Loading learning content...
Imagine a delivery driver given a package with instructions: "You can only make 64 stops before giving up." Each time the driver reaches a new location and must continue, they subtract one from their remaining stops. When the counter hits zero, the driver abandons the delivery and notifies the original sender that the package spent too much time in transit.
This is precisely how the Time To Live (TTL) field works in IP packets, and the ICMP Time Exceeded message (Type 11) is the notification mechanism. It informs the sender that a packet was discarded because it exhausted its allotted "lifetime" in the network.
But Time Exceeded isn't just an error message—it's the foundational mechanism behind traceroute, one of the most important network diagnostic tools ever created. Understanding Time Exceeded means understanding how network engineers map and troubleshoot paths across the Internet.
By the end of this page, you will understand the complete mechanics of ICMP Time Exceeded messages, the two distinct code values and their triggers, the engineering genius behind traceroute, and how to interpret Time Exceeded messages during network analysis. You'll gain insight into one of the most elegant applications of protocol design.
The Time To Live (TTL) field is an 8-bit field in the IP header that serves as a loop-prevention mechanism. Without TTL, a packet caught in a routing loop would circulate forever, consuming bandwidth and resources until the network collapsed under the weight of zombie packets.
The TTL Lifecycle:
The name 'Time To Live' is historical. Originally, TTL was meant to be measured in seconds. However, practical implementations always decremented by 1 at each hop regardless of actual time elapsed. RFC 791 specifies that holding a packet at a router gateway should also decrement TTL to approximate time, but this is rarely implemented. In practice, TTL functions as a hop count limit rather than a true time limit.
| Operating System | Default TTL | Maximum Hops |
|---|---|---|
| Linux/Unix | 64 | Up to 64 hops |
| Windows 10/11 | 128 | Up to 128 hops |
| macOS | 64 | Up to 64 hops |
| Cisco IOS | 255 | Up to 255 hops |
| Juniper JUNOS | 64 | Up to 64 hops |
| Solaris | 255 | Up to 255 hops |
| FreeBSD | 64 | Up to 64 hops |
The Anti-Loop Protection:
Consider what happens when a routing misconfiguration creates a loop:
Router A → Router B → Router C → Router A → Router B → ...
Without TTL, this packet would circulate indefinitely. With TTL:
TTL doesn't prevent routing loops from forming, but it limits the damage they can cause.
The ICMP Time Exceeded message follows the standard ICMP error message format. It includes enough information from the original packet for the sender to identify which transmission was affected.
12345678910111213141516171819
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Type (11) | Code | Checksum |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Unused (zeros) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |+ Original IP Header (20-60 bytes) +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| First 8 Bytes of Original Datagram |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 11 (Time Exceeded)Code: 0 = TTL exceeded in transit 1 = Fragment reassembly time exceededChecksum: Internet checksum of ICMP messageUnused: All zeros (32 bits)| Field | Size | Value/Description |
|---|---|---|
| Type | 8 bits | 11 (Time Exceeded) |
| Code | 8 bits | 0 = TTL exceeded; 1 = Fragment reassembly timeout |
| Checksum | 16 bits | One's complement checksum |
| Unused | 32 bits | Reserved, must be zero |
| Original IP Header | 20-60 bytes | Complete IP header from discarded packet |
| Original Data | 8 bytes | First 8 bytes of discarded packet's payload |
Critical Design Element:
Like Destination Unreachable messages, Time Exceeded includes the original IP header plus 8 bytes of payload. This allows the source to:
Without this information, the source could not determine which of its many transmissions triggered the error.
Code 0: TTL Exceeded in Transit is the most frequently encountered Time Exceeded code. It's generated when a router decrements an incoming packet's TTL and finds the result would be zero or less.
RFC 792 explicitly states that ICMP error messages must never generate other ICMP error messages. Without this rule, an ICMP Time Exceeded message with TTL=1 would trigger another Time Exceeded, creating an infinite error storm. This is why routers check if a packet contains an ICMP error before generating new ICMP errors.
Common Causes of TTL Expiration:
Routing Loops: The most serious cause. Packets cycle between routers until TTL exhausts.
Excessively Long Paths: Rare, but possible. The Internet's backbone diameter rarely exceeds 30 hops, but complex multi-homed enterprise networks can approach 64 hops.
Deliberately Low Initial TTL: Applications or tools (like traceroute) intentionally set low TTL to trigger Time Exceeded from intermediate routers.
TTL Manipulation Errors: Security appliances or NAT devices that incorrectly modify TTL can cause premature expiration.
1234567891011121314151617181920212223
# View current TTL in ping responsesping -c 3 google.com# Sample output:# 64 bytes from 142.250.189.174: icmp_seq=1 ttl=117 time=12.3 ms# The response TTL of 117 tells you:# - Google server's initial TTL was likely 128 (Windows)# - 128 - 117 = 11 hops between you and Google # Send packet with specific TTLping -t 5 -c 1 google.com # TTL=5, will likely fail # Expected response (Time Exceeded from 5th hop):# From 10.0.0.5: Time to live exceeded # Set TTL on Linuxping -t 10 destination.example.com # View TTL field in captured packetssudo tcpdump -i eth0 -v icmp# Look for: ttl 64 (original) or ttl 255 (response) # Monitor for Time Exceeded messages specificallysudo tcpdump -i eth0 'icmp[0]=11' -nn -vCode 1: Fragment Reassembly Time Exceeded is a more specialized condition. When an IP datagram is fragmented, all fragments must arrive at the destination host within a reasonable time for reassembly to succeed. If the timeout expires before all fragments arrive, the destination discards the partial fragments and generates this ICMP message.
When a large IP datagram is fragmented, each fragment travels independently through the network. They may take different paths and arrive out of order. The destination host must collect all fragments, identified by the IP Identification field, and reassemble them. The reassembly timer starts when the first fragment arrives and applies a deadline for all remaining fragments.
| Operating System | Default Timeout | Configurable? |
|---|---|---|
| Linux | 30 seconds | Yes (ipfrag_time sysctl) |
| Windows | 60 seconds | Via registry |
| FreeBSD | 30 seconds | Yes (sysctl) |
| Cisco IOS | 15 seconds | Not easily |
| RFC 791 Recommendation | 15 seconds | N/A |
Why Fragment Reassembly Timeouts Matter:
Resource Protection: Holding incomplete datagrams consumes memory buffers. Without timeouts, malicious actors could exhaust destination host memory by sending only first fragments.
Security Implications: Fragment reassembly attacks (like the "teardrop" attack) exploit this process. Timeouts limit exposure windows.
Performance Debugging: Frequent Code 1 errors indicate:
Modern networks largely avoid fragmentation through Path MTU Discovery (PMTUD). TCP negotiates Maximum Segment Size (MSS) during connection establishment, and applications typically don't create datagrams requiring fragmentation. Code 1 Time Exceeded messages are consequently rare—if you see them frequently, investigate why fragmentation is occurring at all.
1234567891011121314151617181920
# View current fragment reassembly timeout (in seconds)cat /proc/sys/net/ipv4/ipfrag_time# Default: 30 # Change fragment reassembly timeoutsudo sysctl -w net.ipv4.ipfrag_time=15 # Make persistent across rebootsecho "net.ipv4.ipfrag_time = 15" | sudo tee -a /etc/sysctl.conf # View fragment reassembly statisticscat /proc/net/snmp | grep -i frag# Ip: ... ReasmTimeout ReasmReqds ReasmOKs ReasmFails ... # Monitor for fragment reassembly timeout ICMPtcpdump -i eth0 'icmp[0]=11 and icmp[1]=1' -nn -v # View memory used for fragment reassemblycat /proc/sys/net/ipv4/ipfrag_high_thresh # High water markcat /proc/sys/net/ipv4/ipfrag_low_thresh # Low water marktraceroute (or tracert on Windows) is one of the most ingenious applications of ICMP Time Exceeded messages. It exploits the TTL mechanism to discover every router along the path between two hosts—without any special cooperation from those routers.
The key realization: When a router sends a Time Exceeded message, the ICMP packet's source IP address is that router's interface IP. By deliberately sending packets with incrementing TTL values (1, 2, 3, ...), we can force each router along the path to reveal itself one by one.
Traceroute Algorithm:
1. Send probe packet with TTL=1
→ First router decrements to 0, sends Time Exceeded
→ Source records Router 1's IP address
2. Send probe packet with TTL=2
→ First router decrements to 1, forwards
→ Second router decrements to 0, sends Time Exceeded
→ Source records Router 2's IP address
3. Continue incrementing TTL...
→ Each hop reveals itself
4. When destination is reached:
→ No Time Exceeded (TTL didn't expire)
→ Destination responds (ICMP Echo Reply, Port Unreachable, etc.)
→ Traceroute terminates
Probe Packet Variations:
Different traceroute implementations use different probe packet types:
| Implementation | Probe Type | Destination Signal |
|---|---|---|
| Unix traceroute | UDP to high port (33434+) | ICMP Port Unreachable |
| Windows tracert | ICMP Echo Request | ICMP Echo Reply |
| traceroute -I | ICMP Echo Request | ICMP Echo Reply |
| traceroute -T | TCP SYN to port 80/443 | TCP SYN-ACK or RST |
| Paris traceroute | Various, flow-aware | Multiple methods |
Why UDP by Default?
UDP probes to unused high ports (33434+) guarantee that reaching the destination triggers an ICMP Port Unreachable response—a clear "I arrived" signal. ICMP echo might be blocked by firewalls, but the Port Unreachable mechanism typically works.
Understanding traceroute output is essential for network troubleshooting. Each line represents one hop, and the three timing values reveal round-trip latencies to that hop.
1234567891011121314151617181920212223242526272829303132
$ traceroute google.comtraceroute to google.com (142.250.189.174), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 1.234 ms 1.101 ms 1.089 ms └── Home router (gateway) 2 10.0.0.1 (10.0.0.1) 8.234 ms 9.012 ms 7.891 ms └── ISP's first router 3 core-rtr.isp.net (203.0.113.5) 12.345 ms 11.234 ms 12.890 ms └── ISP core router (has reverse DNS name) 4 * * * └── No response (firewall blocking ICMP or rate limiting) 5 72.14.215.85 (72.14.215.85) 15.234 ms 14.567 ms 15.012 ms └── Entry into Google's network 6 142.250.189.174 (142.250.189.174) 16.789 ms 15.234 ms 16.012 ms └── Destination reached! INTERPRETING THE OUTPUT:─────────────────────────• Hop number: Position along the path• IP address: Router interface that sent Time Exceeded• Hostname: Reverse DNS lookup (if available)• Three times: RTT for each of 3 probe packets (ms) ASTERISKS (* * *):• Router didn't respond to that probe• Could be: firewall blocking, rate limiting, asymmetric routing• Next hop responds = path continues; just this hop is silentTraceroute shows the forward path, but ICMP responses take the reverse path—which may differ. Latency measurements include both directions. Also, routers may rate-limit ICMP responses, causing artificial asterisks. Don't assume asterisks always indicate problems.
12345678910111213141516171819202122232425262728293031
# Basic traceroute (UDP probes)traceroute google.com # ICMP probes (like Windows tracert)traceroute -I google.com# Or on some systems:traceroute --icmp google.com # TCP probes (bypasses many firewalls)traceroute -T -p 443 google.comsudo traceroute --tcp -p 80 google.com # Don't resolve hostnames (faster)traceroute -n google.com # Set max hopstraceroute -m 15 google.com # Set number of probes per hoptraceroute -q 1 google.com # Just 1 probe (faster)traceroute -q 5 google.com # 5 probes (more data) # Set initial TTL (skip first N hops)traceroute -f 5 google.com # Start at hop 5 # Wait time for responsetraceroute -w 2 google.com # Wait 2 seconds per probe # Windows equivalenttracert google.comtracert -d google.com # No DNS resolutionTime Exceeded messages provide concrete evidence about network problems. Here's how to use them diagnostically.
Using Packet Captures for Time Exceeded Analysis:
When troubleshooting, capturing Time Exceeded messages reveals critical information:
1234567891011121314151617181920212223242526
# Capture all Time Exceeded messagessudo tcpdump -i any 'icmp[0]=11' -nn -v # Sample output:# 10:15:32.123456 IP 10.0.0.5 > 192.168.1.100: # ICMP time exceeded in-transit, length 56 # The detailed view shows:# - Source IP (10.0.0.5): The router that discarded the packet # - Destination IP (192.168.1.100): Original packet's source (your host)# - "in-transit": Code 0 (TTL expired)# - Original datagram included for identification # Capture with full packet detailssudo tcpdump -i any 'icmp[0]=11' -nn -vv -X # Wireshark filter for Time Exceeded# icmp.type == 11 # Wireshark filter for specific codes# icmp.type == 11 && icmp.code == 0 (TTL exceeded)# icmp.type == 11 && icmp.code == 1 (Fragment reassembly timeout) # Check for routing loops (repeated source IPs in Time Exceeded)traceroute -n problematic.destination.com | awk '{print $2}' | sort | uniq -d# If output shows IPs, those routers appear multiple times (loop!)If you receive Time Exceeded from an IP address you didn't expect in the path, it could indicate: (1) Your packets are being routed through an unexpected path, (2) A tunnel or VPN is adding hops, (3) Traffic is being redirected (possibly by an attacker). Always verify that Time Exceeded sources match expected network topology.
Time Exceeded messages, while essential for network diagnostics, have security implications that network defenders must understand.
Defensive Measures:
| Measure | Implementation | Trade-off |
|---|---|---|
| Block outbound ICMP | Firewall rule: DROP ICMP type 11 | Breaks own traceroute capability |
| Rate-limit ICMP | Limit responses per second | Diagnostic accuracy reduced |
| Don't decrement TTL | Interface config (rare) | Violates RFC, causes loops |
| Edge-only responses | Only edge routers reply | Internal topology hidden |
| Source-validate ICMP | Check if original packet was legitimate | Minimal impact |
The Balance:
Completely blocking Time Exceeded breaks legitimate diagnostics (including your own troubleshooting). Most organizations accept the reconnaissance risk to maintain operational visibility. Security-critical environments may block Time Exceeded at perimeter boundaries while allowing it internally.
Most modern operating systems and routers rate-limit ICMP generation (e.g., Linux defaults to 1000 ICMP messages per second). This prevents ICMP from being used in amplification attacks and limits reconnaissance efficiency. When you see asterisks in traceroute, rate limiting may be the cause—not necessarily a firewall.
The ICMP Time Exceeded message transforms the TTL loop-prevention mechanism into a powerful diagnostic tool. Its elegant application in traceroute demonstrates how fundamental protocol features can be leveraged for network visibility.
You now understand ICMP Time Exceeded messages at a professional level. You can explain how TTL works, interpret both code values, leverage traceroute for network analysis, and consider security trade-offs. Next, we'll explore ICMP Redirect messages—how networks dynamically optimize routing paths.