ICMP Destination Unreachable

What is ICMP Destination Unreachable

ICMP Destination Unreachable (Type 3) is an error message that notifies the sender that a transmitted IP packet could not be delivered to its destination. It is defined in RFC 792.

The reason a packet “could not be delivered” varies depending on where along the path the problem occurred, and this difference is expressed in the Code field. Beyond simply reporting that delivery failed, it carries information useful for isolating the cause — whether the network doesn’t exist, the destination host isn’t responding, or the destination host’s port is closed.

Packet Format

The “Rest of Header” of a Destination Unreachable message is unused (zero-filled) for most Codes, but for Code 4 (Fragmentation Needed and DF Set) it is used as a Next-Hop MTU field. The Data field contains a portion of the original IP packet that was discarded.

Field Name	Size	Description
Type	1 byte	Fixed at `3`.
Code	1 byte	A value indicating the reason delivery failed. See the table below for details.
Checksum	2 bytes	An error-detection value covering the entire ICMP message.
Unused / Next-Hop MTU	4 bytes	Unused (zero-filled) for Codes other than 4. For Code 4, the upper 2 bytes are unused and the lower 2 bytes hold the maximum MTU that can be forwarded to the next hop (used for Path MTU Discovery).
Data	Variable	A portion of the discarded original IP packet (typically the IP header plus the first 8 bytes).

List of Codes

A summary of the common Code values and where each typically originates.

Code	Name	Example Source
0	Network Unreachable	A router that has no route information to the destination network
1	Host Unreachable	A router within the destination network that cannot find a route to that specific host (e.g. when ARP resolution fails)
2	Protocol Unreachable	The destination host does not support the specified upper-layer protocol (the Protocol field in the IP header)
3	Port Unreachable	No process is listening on the specified UDP port on the destination host
4	Fragmentation Needed and DF Set	A router where the packet size exceeds the link MTU, but the DF bit in the IP header prevents fragmentation
5	Source Route Failed	A router that cannot forward the packet according to the source route specified in an IP option
13	Communication Administratively Prohibited	Explicitly blocked by a firewall or ACL

Code 3 (Port Unreachable) is UDP-specific behavior. For TCP, a connection request (SYN) to a closed port is normally answered with a TCP RST (reset) packet rather than ICMP. traceroute is able to detect that it has reached the destination using UDP probes precisely because it relies on this Port Unreachable mechanism.

Example Scenario

An example where R1 (192.168.0.1) sends a packet to a nonexistent host R9 (192.168.9.9), and R1’s default gateway GW has no route to that network.

sequenceDiagram
    participant R1 as R1
192.168.0.1
    participant GW as GW
Default Gateway

    R1->>GW: Packet destined for 192.168.9.9
    Note over GW: No route information
for 192.168.9.0/24
    GW-->>R1: ICMP Destination Unreachable
Type: 3, Code: 0 (Network Unreachable)
Source: GW's IP address

As shown here, a Destination Unreachable message is returned not by the destination host itself, but by whichever router or host along the path gave up on forwarding the packet, using its own address as the source. Checking the source address of the response lets you isolate where along the path the problem occurred.

Relationship with Path MTU Discovery

Code 4 (Fragmentation Needed and DF Set) is a special Code related to IPv4 fragmentation. When a packet with the DF bit (Don’t Fragment) set exceeds the MTU of the outgoing link and a router cannot fragment it, the router discards the packet and returns this message to the sender.

The mechanism where the sender reads the Next-Hop MTU value returned in this message and adjusts subsequent packets to be no larger than that MTU is called Path MTU Discovery (PMTUD).

If a firewall along the path blanket-blocks ICMP, this Code 4 message never reaches the sender and PMTUD stops working correctly (the so-called PMTUD black hole). This can lead to a hard-to-diagnose failure where larger packets with the DF bit set are silently dropped only on specific paths.

The full list of Code values is maintained by IANA.

IANA - ICMP Type 3 Codes

Verification on Real Hardware

Linux1 (192.168.1.1/24) — R1 — R2 — R3 — Linux2 (192.168.2.2/24) are connected in series as shown below, with each router configured with a static route pointing toward its neighbor. R2 only has routes to 192.168.1.0/24 and 192.168.2.0/24 and has no default route, so when it receives a packet for any other destination (e.g. 172.16.1.1), it has nowhere to forward it and returns an ICMP Destination Unreachable. In this environment we reproduced two patterns, Host Unreachable and Port Unreachable, and confirmed each with a packet capture.

Verifying Host Unreachable

R2’s Routing Table

R2 show ip route
R2#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.1.2.0/24 is directly connected, GigabitEthernet1
L        10.1.2.2/32 is directly connected, GigabitEthernet1
C        10.2.3.0/24 is directly connected, GigabitEthernet2
L        10.2.3.2/32 is directly connected, GigabitEthernet2
S     192.168.1.0/24 [1/0] via 10.1.2.1, GigabitEthernet1
S     192.168.2.0/24 [1/0] via 10.2.3.3, GigabitEthernet2

As shown by “Gateway of last resort is not set,” R2 has no default route, and its routing table contains only the directly connected 10.1.2.0/24 and 10.2.3.0/24, plus the static routes for 192.168.1.0/24 and 192.168.2.0/24. A packet destined for 172.16.1.1 matches none of these routes, so R2 determines it cannot be routed and returns an ICMP Destination Unreachable.

ping Command Output

Linux1 ping -c 5 172.16.1.1
$ ping -c 5 172.16.1.1
PING 172.16.1.1 (172.16.1.1) 56(84) bytes of data.
From 10.1.2.2 icmp_seq=1 Destination Host Unreachable
From 10.1.2.2 icmp_seq=2 Destination Host Unreachable
From 10.1.2.2 icmp_seq=3 Destination Host Unreachable
From 10.1.2.2 icmp_seq=4 Destination Host Unreachable
From 10.1.2.2 icmp_seq=5 Destination Host Unreachable

--- 172.16.1.1 ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4008ms

All 5 probes received a “Destination Host Unreachable” reply — not from the destination 172.16.1.1 itself, but from R2 (10.1.2.2) along the path.

Packet Capture

The capture of the first probe (Sequence Number 1):

Echo Request (Linux1 to 172.16.1.1, sent toward R1)
Ethernet II, Src: 52:54:00:51:26:a0, Dst: 52:54:00:01:c6:d0
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 172.16.1.1
    Time to Live: 64
    Flags: DF (Don't Fragment)
    Protocol: ICMP (1)
    Total Length: 84
Internet Control Message Protocol
    Type: 8 (Echo (ping) request)
    Code: 0
    Checksum: 0xb1d0
    Identifier: 0x053f (1343)
    Sequence Number: 0x0001 (1)

ICMP Destination Unreachable (R2 to Linux1, Host Unreachable)
Ethernet II, Src: 52:54:00:01:c6:d0, Dst: 52:54:00:51:26:a0
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 10.1.2.2, Dst: 192.168.1.1
    Time to Live: 254
    Protocol: ICMP (1)
    Total Length: 56
Internet Control Message Protocol
    Type: 3 (Destination Unreachable)
    Code: 1 (Host Unreachable)
    Checksum: 0x3dee
    Unused: 0x00000000
    [Original Datagram]
        Internet Protocol Version 4, Src: 192.168.1.1, Dst: 172.16.1.1, Time to Live: 62
        Internet Control Message Protocol, Type: 8, Code: 0, Identifier: 0x053f (1343), Sequence Number: 0x0001 (1)

Since this capture was taken on the Linux1-R1 link, the Ethernet header’s destination/source MAC addresses actually belong to Linux1 and R1 (Gi2). R2 cannot route the Echo Request toward Linux1’s destination, so it returns an ICMP Destination Unreachable with itself (10.1.2.2) as the source, relayed back to Linux1 via R1.

Based on the classification, Code 0 (Network Unreachable: no route to the destination network) might seem like the expected result here, but what Cisco IOS XE actually returned was Code 1 (Host Unreachable). On modern IOS, which assumes classless addressing (CIDR), when there is no matching entry at all in the routing table, the implementation uniformly returns Host Unreachable (“no route to the destination host”) — Network Unreachable is a holdover from pre-CIDR design and is rarely returned in practice. Even though the RFC distinguishes Code 0 and 1, be aware that a given implementation may only ever use one of the two.

Download icmp_host-unreachable.pcap

Verifying Port Unreachable

No process is listening on UDP for port 5000 on Linux2 (192.168.2.2). We sent UDP data from Linux1 to that port and confirmed the Port Unreachable behavior with a packet capture.

nc Command Output

Linux1 nc -u 192.168.2.2 5000
cisco@linux1:~$ echo "test" | nc -u -w1 192.168.2.2 5000
cisco@linux1:~$

nc shows no particular error — it simply waits until the -w1 timeout and exits, since UDP itself gives nc no way to detect whether a reply arrived. In fact, as shown below, an ICMP Port Unreachable is returned.

Packet Capture

UDP Datagram (Linux1 to Linux2, destination port 5000)
Ethernet II, Src: 52:54:00:51:26:a0, Dst: 52:54:00:01:c6:d0
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.2
    Time to Live: 64
    Flags: DF (Don't Fragment)
    Protocol: UDP (17)
    Total Length: 33
User Datagram Protocol, Src Port: 60717, Dst Port: 5000
    Length: 13 (5 bytes of data: "test\n")

ICMP Destination Unreachable (Linux2 to Linux1, Port Unreachable)
Ethernet II, Src: 52:54:00:01:c6:d0, Dst: 52:54:00:51:26:a0
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.2.2, Dst: 192.168.1.1
    Time to Live: 61
    Protocol: ICMP (1)
    Total Length: 61
Internet Control Message Protocol
    Type: 3 (Destination Unreachable)
    Code: 3 (Port Unreachable)
    Checksum: 0x816f
    Unused: 0x00000000
    [Original Datagram]
        Internet Protocol Version 4, Src: 192.168.1.1, Dst: 192.168.2.2, Time to Live: 61
        User Datagram Protocol, Src Port: 60717, Dst Port: 5000, Length: 13 (5 bytes of data: "test\n")

This capture was also taken on the Linux1-R1 link, so the Ethernet header’s destination/source MAC addresses belong to Linux1 and R1 (Gi2). Note the IP header’s TTL: both the outbound UDP datagram and the returning ICMP message show 61. Linux2 is 3 hops from Linux1 (R3, R2, R1), and 61 matches Linux’s default TTL (64) minus 3 — confirming that this ICMP message originated from the destination host, Linux2, itself.

Host Unreachable came from R2 (a router along the path), but Port Unreachable comes from the destination host, Linux2, itself. Port Unreachable indicates “the destination was reached, but no process is listening on the specified port” — this is a problem on the destination host’s side, not a routing problem, so the message originates from the destination host itself.

The quoted original datagram also includes the full IP header plus UDP header plus payload (“test\n”), which is more than the minimum described in the Packet Format table (“typically the IP header plus the first 8 bytes”). RFC 792 only defines a minimum requirement, and it’s common for implementations to quote more of the packet when it fits.

Download icmp-port_unreachable.pcap

Verification Configs

Download R1 config (r1_icmp-unreachable.cfg)

Download R2 config (r2_icmp-unreachable.cfg)

Download R3 config (r3_icmp-unreachable.cfg)

Test Environment and show Output

Download R1 show output (r1_icmp-unreachable_show.txt)

Download R2 show output (r2_icmp-unreachable_show.txt)

Download R3 show output (r3_icmp-unreachable_show.txt)

References

RFC	Title	Overview
RFC 792	Internet Control Message Protocol	The original ICMP specification, defining the basic Destination Unreachable format and Codes 0-5.
RFC 1191	Path MTU Discovery	Defines the PMTUD mechanism that uses Code 4 and the Next-Hop MTU field.

What is ICMP Destination Unreachable

Packet Format

List of Codes

Example Scenario

Relationship with Path MTU Discovery

Verification on Real Hardware

Verifying Host Unreachable

R2’s Routing Table

ping Command Output

Packet Capture

Verifying Port Unreachable

nc Command Output

Packet Capture

Verification Configs

Test Environment and show Output

References

Related Articles