Ping Timeout vs Destination Unreachable: Decoding Every Failure

Two pings fail. One prints nothing and reports 100% packet loss. The other prints Destination Host Unreachable on every line. Most people treat them as the same thing ("ping doesn't work"), but they are completely different failures pointing at completely different parts of the network. This article decodes every failure message you will see from Linux ping and Cisco IOS ping, using real captures from a live lab, and is part of the PingLabz ping guide.

The lab: a Debian host behind three IOS XE routers (R1, R2, R3) running OSPF, with R3's loopback 3.3.3.3 as the usual target. Each failure below was deliberately engineered, so you can see exactly which fault produces which message.

The Two Families of Failure

Every ping failure falls into one of two families, and identifying the family is your first triage step:

Silent failures. The packet (or its reply) was dropped and nobody told you. You see nothing until the summary line reports loss. The evidence is the absence of information.

Loud failures. Some device on the path sent you an ICMP error message explaining the problem. The message names the device that generated it (the From address), which immediately localizes the fault.

Loud failures are gifts. The From address is a device telling you "the problem is at or after me."

Silent Loss: 100% Packet Loss, No Errors

Here the path to 3.3.3.3 has a filter that drops ICMP without generating errors (an ACL on R3 combined with no ip unreachables, a common hardening configuration):

j@lab:~$ ping -c 3 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.

--- 3.3.3.3 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2029ms

No error lines at all. This pattern means one of: a firewall or ACL silently dropping (deny without unreachables), the destination is down but a stateless device in front of it eats the evidence, the reply path is broken (request arrives, reply cannot return), or ICMP is deprioritized/rate-limited somewhere. Silent loss localizes to nothing by itself; you need traceroute to find where the path goes dark:

j@lab:~$ traceroute -n 3.3.3.3
traceroute to 3.3.3.3 (3.3.3.3), 30 hops max, 60 byte packets
 1  192.168.99.1  2.793 ms  2.764 ms  2.685 ms
 2  10.0.12.2  3.525 ms  3.487 ms  3.439 ms
 3  * * *
 4  * * *

Hops 1 and 2 answer, hop 3 is a wall of asterisks. The fault sits between 10.0.12.2 and the next device. That is a real diagnosis, extracted from a silent failure.

Destination Host Unreachable (From Your Own IP)

j@lab:~$ ping -c 3 192.168.99.77
PING 192.168.99.77 (192.168.99.77) 56(84) bytes of data.
From 192.168.99.100 icmp_seq=1 Destination Host Unreachable
From 192.168.99.100 icmp_seq=2 Destination Host Unreachable
From 192.168.99.100 icmp_seq=3 Destination Host Unreachable

Look at the From address: 192.168.99.100 is the sender's own IP. The target is on the local subnet, so the host tried to ARP for it, got no answer, and gave up. The packet never left the NIC. This failure is Layer 2 adjacent: wrong IP, host powered off, wrong VLAN, or a switching problem (start with VLAN and Layer 2 troubleshooting rather than routing).

When the same message arrives From a router's address instead, that router has a route to the subnet but cannot ARP the final host on its connected segment. Same L2 diagnosis, different location: the far-end segment.

Packet Filtered (Administratively Prohibited)

With an ACL on R3 denying ICMP echo (but with unreachables left enabled), the router honestly reports the policy drop:

j@lab:~$ ping -c 3 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.
From 10.0.23.1 icmp_seq=1 Packet filtered
From 10.0.23.1 icmp_seq=2 Packet filtered
From 10.0.23.1 icmp_seq=3 Packet filtered

This is ICMP type 3 code 13, "communication administratively prohibited." The device at 10.0.23.1 is telling you an ACL or firewall rule matched a deny. Nothing is broken; policy is doing its job (whether the policy is correct is a separate conversation, often with whoever manages the firewall).

Time to Live Exceeded

j@lab:~$ ping -c 3 -t 1 3.3.3.3
From 192.168.99.1 icmp_seq=1 Time to live exceeded

The TTL ran out in transit (here forced deliberately with -t 1). If you see this without forcing a low TTL, it almost always means a routing loop: the packet bounced between routers until the TTL burned down. Confirm with traceroute and expect to see the same pair of addresses alternating. Loops usually trace back to a redistribution or default-route mistake in your OSPF or BGP design.

Frag Needed and DF Set

j@lab:~$ ping -c 3 -s 1400 -M do 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 1400(1428) bytes of data.
From 10.0.12.2 icmp_seq=1 Frag needed and DF set (mtu = 1400)

The packet was too big for a link on the path, and the DF (Don't Fragment) bit forbade the router from fragmenting it. The router even reports the MTU that would fit (1400). Small pings succeed while large transfers hang: this is the classic MTU black hole signature, and it gets a full treatment in testing MTU with ping and the DF bit.

The Same Failures in Cisco IOS Ping

IOS compresses all of this into single response characters. The same ACL scenario, seen from R1 instead of the Linux host:

R1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)

And a destination with no route at all just times out silently:

R1#ping 10.99.99.99
Sending 5, 100-byte ICMP Echos to 10.99.99.99, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The U.U.U alternation is not random: IOS rate-limits ICMP unreachables (one per 500 ms by default), so between the U replies the probe just times out as a dot. Full character decoding lives in the extended ping article.

The Failure Decoder

A 60-Second Triage Workflow

When a ping to a remote target fails, run these three probes and you will localize most faults before opening a single config: ping your default gateway (proves L2 and the first hop), ping the far-side router interface or a known-good host near the target (proves the routed path), then traceroute the original target (finds the exact hop where behavior changes). Match whatever messages you get against the decoder above, and pay attention to the From address in every error line: it is the network telling you where to look.

Key Takeaways

• Silent loss and unreachable messages are different families of failure: no messenger vs a named messenger.
• Destination Host Unreachable from your own IP = local ARP failure = Layer 2 problem.
• Packet filtered = ICMP type 3 code 13 = an ACL or firewall matched a deny and told you about it.
• Unforced Time to live exceeded = suspect a routing loop.
• IOS compresses these into characters: . timeout, U unreachable, M could not fragment, and rate-limits unreachables into patterns like U.U.U.
• The From address in every error is your fault locator. Use it.

Continue with Cisco extended ping and response characters, or return to the complete ping guide.