ICMP, Ping and Path Discovery

Learning objective

Use IPv4 ICMP evidence to explain what ping and traceroute show, distinguish a response from silence, and make conclusions that the packets actually support.

Why ICMP exists

IPv4 hosts and routers need a way to report network-layer conditions. The Internet Control Message Protocol, or ICMP, carries that control evidence inside IPv4 packets. It is not TCP or UDP application data. A message can confirm an authored exchange, report a forwarding problem, or reveal where a probe's lifetime ended.

ICMP message anatomy

An ICMP header begins with a type and code pair. The type identifies the broad message family; the code refines its meaning. A checksum protects the ICMP message. Error messages also include a quoted portion of the triggering IPv4 packet so the sender can associate the report with an earlier transmission.

Informational and error messages

Echo messages are informational: an Echo Request uses type 8, code 0, and an Echo Reply uses type 0, code 0. Curated error examples in this lesson include Destination Unreachable type 3 and Time Exceeded type 11, code 0. These examples are not an exhaustive ICMP registry. An error identifies its reporting device separately from the intended destination.

Echo Request and Echo Reply

IPv4 ping normally sends an Echo Request toward a destination and waits for a matching Echo Reply. The identifiers and sequence information associate replies with requests. Routers forward the IPv4 packets normally; ping does not reserve a special path or bypass routing policy.

Interactive ping evidence

Compare six outcomes: success, timeout, network unreachable, host unreachable, administratively prohibited, and TTL exceeded. Follow the request, any reporting device, the response type and code, and the evidence quoted from the triggering packet.

Follow ping and read the ICMP evidence

Choose a ping outcome

Successful echo exchangeTimeout with no responseDestination Network UnreachableDestination Host UnreachableCommunication Administratively ProhibitedTTL Exceeded before destination

1. Source Hostsending workstation
2. Gateway RouterIPv4 forwarding device
3. Destination Hostremote server

Step 1 of 3: Send Echo Request

Source Host sends an ICMP Echo Request toward Destination Host.

Echo Request (type 8, code 0)Outbound request

TTL: 64

Evidence for Send Echo Request

Field	Value	Layer
IPv4 destination	198.51.100.20	ip
ICMP	Echo Request — type 8, code 0	application

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

What successful ping proves

A matching reply proves that the authored Echo Request reached a responding endpoint and its Echo Reply returned to the source. It does not prove that an application port works, that every packet succeeds, or that forward and return traffic used the same route. Ping establishes limited reachability evidence, not complete service health or path symmetry.

Timeouts, loss, and round-trip time

A timeout means only that no reply was observed before the waiting deadline. The request, reply, or an intervening error may have been lost, filtered, rate-limited, or unable to return. Repeated probes can estimate observed loss. Their round-trip time measures the request-and-reply interval, not one-way delay, and can vary with congestion and device processing.

Destination Unreachable

Destination Unreachable type 3 reports that a device could not deliver the triggering packet. This lesson uses code 0 for network unreachable, code 1 for host unreachable, and code 13 for communication administratively prohibited. Read the reporter, type, code, and quoted packet together. The reporting router can be different from the destination that ping intended to reach.

TTL and Time Exceeded

Each IPv4 router decrements the packet's TTL once. A router that receives a packet whose TTL expires discards it and may return Time Exceeded type 11, code 0 with quoted trigger evidence. That response names where this probe expired; filtering, rate limiting, or an unavailable return route can also leave the sender with silence.

Interactive traceroute discovery

Watch conceptual ICMP-based, Windows-style path discovery increase the IPv4 TTL one probe at a time. Compare a stable path, a silent hop followed by later replies, changing paths, destination unreachable, and a trace that stops incomplete.

Discover the path one TTL at a time

Conceptual Windows-style ICMP traceroute; implementations may use different probe transports.

Choose a traceroute outcome

Complete stable pathSilent hop, then later repliesPath changes between probesDestination unreachableTrace ends incomplete

1. Source Host192.0.2.10
2. Router 1192.0.2.1
3. Router 2203.0.113.1
4. Alternate Router203.0.113.9
5. Destination Host198.51.100.20

Step 1 of 6: probe p1, TTL 1

Send probe p1 with TTL 1.

Probe	TTL	Observed responder	RTT	Meaning

PreviousPlayNextRestartPlayback speed 0.5×1×1.5×2×

Why traceroute can be incomplete

A * is a silent hop: no response was observed for that probe within the waiting period. It does not prove that router failed to forward, especially when later TTL probes receive replies. Devices may filter or rate-limit ICMP, and implementations can use different probe transports. Load balancing can change the observed forward path, while an asymmetric return path can change response timing and visibility.

Safe conclusions

Describe only what was observed: the source sent a probe, a named device responded with a specific type/code, a destination replied, or no response arrived before the deadline. Correlate several probes with routing and application evidence. Neither ping success nor a tidy traceroute proves application reachability, continuous loss-free service, or a symmetric end-to-end path.