How Ping Works: The ICMP Echo Exchange Explained

You type ping, you get replies, the network is fine. Every engineer runs this loop dozens of times a day, but far fewer can explain what actually happens between pressing Enter and seeing 64 bytes from 3.3.3.3. That gap matters, because every field in the ping output line is telling you something specific about the path, and reading it correctly is the difference between "the ping works" and actually understanding what you just proved. This article is part of the PingLabz ping guide, and every capture in it comes from a live lab: a Debian host connected through three Cisco IOS XE routers running OSPF.

What Ping Actually Sends

Ping uses ICMP (Internet Control Message Protocol), which rides directly on top of IP as protocol number 1. There is no TCP, no UDP, and no port number anywhere in the exchange (a common interview trap: ping does not use a port). The tool sends an ICMP Echo Request (type 8, code 0) to the target. If the target is up, reachable, and willing to answer, it returns an ICMP Echo Reply (type 0, code 0) with the same payload it received.

Only four ICMP message types account for nearly everything you will see in day-to-day ping work:

Everything else, the sequence numbers, the timing, the statistics, is bookkeeping the ping utility does locally around this simple request/reply pair.

The Lab Behind These Captures

All output below comes from a Debian 13 host (iputils ping) attached to a three-router Cisco IOS XE chain in Cisco Modeling Labs: host to R1 (192.168.99.1), R1 to R2, R2 to R3, with loopbacks 1.1.1.1, 2.2.2.2, and 3.3.3.3 advertised in OSPF. Pinging 3.3.3.3 from the host crosses two intermediate routers before reaching R3.

Reading the Output Line by Line

Here is a ping to R3's loopback, three routed hops away:

j@lab:~$ ping -c 4 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.
64 bytes from 3.3.3.3: icmp_seq=1 ttl=253 time=3.93 ms
64 bytes from 3.3.3.3: icmp_seq=2 ttl=253 time=4.43 ms
64 bytes from 3.3.3.3: icmp_seq=3 ttl=253 time=4.79 ms
64 bytes from 3.3.3.3: icmp_seq=4 ttl=253 time=4.61 ms

--- 3.3.3.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.928/4.440/4.793/0.322 ms

Working through each field:

56(84) bytes of data. The default payload is 56 bytes. Add the 8-byte ICMP header and the 20-byte IPv4 header and you get 84 bytes on the wire. This 28-byte overhead becomes important when you use ping to test MTU with the DF bit.

64 bytes from 3.3.3.3. The reply size: your 56-byte payload plus the 8-byte ICMP header. The reply came back from the address you targeted, which confirms two-way reachability (the request found a path there AND the reply found a path back).

icmp_seq=1. A sequence number ping increments per probe. Gaps in the sequence mean individual packets were lost; replies arriving out of order mean something on the path is reordering traffic.

ttl=253. The most misread field in the output, covered next.

time=3.93 ms. Round-trip time (RTT): request out plus reply back plus the target's processing time. Not one-way latency, and not a guaranteed measure of what your application traffic experiences (routers often process ICMP addressed to themselves in the slow path, so pinging a router interface can show worse numbers than traffic through that router would see).

What the TTL Really Tells You

The TTL you see belongs to the echo reply, not to your request. The destination creates the reply with its own initial TTL, and every router on the return path decrements it by one. Common initial values: Linux uses 64, Windows uses 128, and Cisco IOS uses 255.

In the capture above, ttl=253 means the reply started at 255 (Cisco) and was decremented twice, by R2 and then R1, on its way back. Two intermediate routers, exactly matching the topology. Ping the first-hop router directly and there is nothing in between to decrement it:

j@lab:~$ ping -c 4 192.168.99.1
64 bytes from 192.168.99.1: icmp_seq=1 ttl=255 time=1.65 ms

You can invert this trick and cap the TTL of your own outgoing request with -t. The packet dies in transit, and the router where it died reports back with an ICMP Time Exceeded:

j@lab:~$ ping -c 3 -t 1 3.3.3.3
PING 3.3.3.3 (3.3.3.3) 56(84) bytes of data.
From 192.168.99.1 icmp_seq=1 Time to live exceeded
From 192.168.99.1 icmp_seq=2 Time to live exceeded
From 192.168.99.1 icmp_seq=3 Time to live exceeded

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

TTL 1 dies at the first router (192.168.99.1), TTL 2 dies at the second (10.0.12.2). Increment the TTL one hop at a time and you have manually reinvented traceroute, which is literally how that tool works under the hood.

The Statistics Block

The summary at the end is where the operational signal lives:

Packet loss. 0% is the only healthy number on a stable path. Consistent low-grade loss (1-5%) usually points at congestion, a duplex mismatch, or a dirty link; 100% loss with no error messages means something is silently eating your packets (a very different failure from an unreachable, as explained in timeout vs destination unreachable).

rtt min/avg/max/mdev. The last value, mdev (mean deviation), is effectively jitter. A path with avg 4 ms and mdev 0.3 ms is stable. A path with avg 4 ms and mdev 40 ms has a queueing or buffering problem that will hurt voice and video long before it hurts a file transfer, which is exactly the kind of thing QoS exists to manage.

What a Successful Ping Does Not Prove

Ping answers one question: can an ICMP echo make it there and back right now. It does not prove the application works (TCP port 443 can be filtered while ICMP passes), it does not prove the path is symmetric (the reply may return over a different link than the request took), and it does not measure your data traffic's real latency (ICMP is commonly deprioritized or rate-limited on router control planes). A failed ping is not proof of an outage either: plenty of firewalls drop ICMP by policy while happily forwarding everything else.

Treat ping as the first data point, not the verdict. When it fails, the specific way it fails tells you where to look next, and when it succeeds, the TTL and RTT patterns tell you what path you likely took.

Key Takeaways

• Ping is ICMP Echo Request (type 8) out, Echo Reply (type 0) back. No TCP, no UDP, no ports.
• The default 56-byte payload becomes 84 bytes on the wire: payload + 8 ICMP + 20 IPv4.
• The TTL shown is the reply's remaining TTL. Subtract it from the sender's initial value (64 Linux, 128 Windows, 255 Cisco) to count return-path hops.
• ping -t N caps your outgoing TTL and gets you a Time Exceeded from hop N. That mechanism is the foundation of traceroute.
• mdev in the statistics line is jitter. Watch it as closely as loss.
• A successful ping proves two-way ICMP reachability at this moment, nothing more.

Next in the cluster: decoding every ping failure message, or head back to the complete ping guide for the full reading order.