Ping is the first command every engineer types and the last one they stop trusting. It is deceptively simple: one ICMP echo request out, one echo reply back, a round-trip time on the screen. But that single line of output encodes a surprising amount of information about the path, and every way ping can fail points at a specific, different problem. This guide is the complete reference for ping as a working tool, from what it actually sends on the wire to extended ping on Cisco IOS XE, MTU hunting with the DF bit, and subnet sweeps. Every command and every scrap of output on this page and across the cluster was captured live from a real lab: a Linux host wired through three Cisco IOS XE routers running OSPF in Cisco Modeling Labs, not copied from documentation.
This guide covers what ping is and how the ICMP echo exchange works, how to read every field of the output, the two families of failure and the message that names each one, the full extended ping toolkit on Cisco IOS, using ping to find path MTU, the Linux iputils flags worth memorizing, and how to sweep a subnet for live hosts. Whether you are studying for CCNA/CCNP or troubleshooting a live outage at 2 a.m., this is meant to be the page you keep open.
What Ping Solves
Ping answers exactly one question: can an ICMP echo reach a destination and come back, right now. That narrow question is the foundation of network troubleshooting because it isolates the network layer from everything above it. If ping succeeds but your application fails, the problem is above Layer 3 (a service, a port filter, DNS, TLS). If ping fails, the problem is at or below Layer 3, and the way it fails tells you how far down and where. Ping is the wedge that splits "the network is broken" into a specific, answerable question.
What ping does not do is equally important. A successful ping does not prove your application works, does not prove the path is symmetric, and does not measure the latency your real traffic sees (routers frequently process ICMP addressed to themselves in a slower path than transit traffic). Treat ping as the first data point in a diagnosis, never the last word.
How Ping Works, From the Top
Ping runs on ICMP, which sits directly on top of IP as protocol number 1. There is no TCP, no UDP, and no port number anywhere in the exchange. Your host sends an ICMP Echo Request (type 8, code 0) carrying a small payload; a willing, reachable destination returns an ICMP Echo Reply (type 0, code 0) echoing that payload back. The ping utility wraps local bookkeeping around this pair: sequence numbers to detect loss and reordering, timestamps to compute round-trip time, and a summary of loss and latency at the end.
Here is the whole thing against a target three routed hops away in the lab:
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 msFour ICMP message types account for nearly everything you will encounter in practice. The reference below is worth committing to memory, because every ping outcome is one of these.
The ICMP Messages Behind Every Ping
The deep dive on the echo exchange, header math, and what each output field means is in how ping works: the ICMP echo exchange explained.
Reading the Output: TTL, RTT, and the Statistics Line
Three parts of the output carry almost all the signal. The TTL in the reply is the most misread: it belongs to the reply, created by the destination with its own initial value (64 on Linux, 128 on Windows, 255 on Cisco IOS) and decremented once per router on the way back. A reply showing ttl=253 from a Cisco device started at 255 and crossed two routers returning, which is how you infer return-path hop count from a single line.
The RTT (time=) is round-trip, not one-way, and includes the target's processing time. The final statistics line is where operational health lives: 0% loss is the only healthy number, and mdev (mean deviation) is effectively jitter. A path with a low average but high mdev has a queueing problem that will hurt voice and video long before bulk transfers notice, which is the entire reason QoS exists.
The Two Families of Failure
Every ping failure is either silent (the packet was dropped and nobody told you; you see only 100% loss) or loud (a device on the path sent an ICMP error whose From address names exactly where to look). Loud failures are gifts. The table below is the field decoder; the full walkthrough with a live capture of each one is in ping timeout vs destination unreachable: decoding every failure.
Extended Ping on Cisco IOS XE
A plain ping 3.3.3.3 from a router tests only the path from its egress interface. Extended ping lets you control the source address, size, DF bit, repeat count, and timeout, which is what makes it a real diagnostic instrument. The single most valuable option is sourcing from a loopback, because it forces the far end to have a working return route:
R1#ping 3.3.3.3 source Loopback0
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/4 msIOS also compresses each probe's result into a single character. The essential ones:
A pattern like U.U.U is not flapping; it is IOS rate-limiting ICMP unreachables to one per 500 ms. The full toolkit, including one-line syntax, the interactive dialog, sweep, data patterns, and extended traceroute, is in Cisco extended ping and response characters.
Using Ping to Find Path MTU
Ping plus the DF bit is the standard way to locate an MTU bottleneck, the usual culprit behind "small pings work but large transfers hang." Set the DF bit, push a large packet, and a router at the narrow link answers back with the limiting MTU:
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 one piece of math to internalize: Linux -s sets the ICMP payload, and payload + 8 (ICMP) + 20 (IP) is the wire size, so a 1372 payload is a 1400-byte packet. Cisco's size keyword sets the full packet instead. This distinction, plus binary-searching for the MTU ceiling and the PMTUD black holes that break TCP silently, gets a full treatment in testing MTU with ping and the DF bit. If those 1400-byte links look familiar, it is because tunnels create them; see the GRE guide.
The Linux Ping Flags Worth Knowing
The iputils ping is far richer than -c. A one-second link-quality sample (-c 100 -i 0.01 -q) gives you loss and jitter at a glance; -w bounds total runtime so a scripted ping can never hang; -D stamps each reply with an epoch time for correlating overnight captures against logs; and -6 -I <iface> saves you from the classic IPv6 "Address unreachable" that is really just the kernel sourcing from the wrong interface on a multi-homed host. The full field reference is in Linux ping options for network engineers.
Sweeping a Subnet for Live Hosts
To inventory what is alive on a subnet, a bash loop with -c 1 -W 1 is instant and needs nothing installed, while nmap -sn is more accurate because on the local segment it uses ARP, which live hosts cannot firewall:
j@lab:~$ nmap -sn 192.168.99.0/24
Nmap scan report for 192.168.99.1
Host is up (0.0027s latency).
Nmap scan report for 192.168.99.100
Host is up (0.00030s latency).
Nmap done: 256 IP addresses (2 hosts up) scanned in 3.03 secondsThe catch worth remembering: a ping sweep only sees hosts that answer ICMP, so "down" never means "definitely absent." When and why to use each approach is in ping sweep: finding live hosts with bash and nmap, and the offensive-security dimension continues in the Nmap guide. And once a host answers ping but the path still feels slow, reachability is no longer the question - throughput is, and that is a job for the iPerf guide.
Should You Block ICMP? The Filtering Debate
Security teams often reflexively block all ICMP at the edge. Done bluntly, that is a mistake, because two ICMP messages are load-bearing for a working network. Fragmentation Needed (type 3, code 4) is what makes Path MTU Discovery function; filter it and you create black holes where TCP connections hang for no visible reason. Time Exceeded (type 11) is what makes traceroute work. A sound policy rate-limits echo and blocks what you don't need while explicitly permitting frag-needed and, ideally, time-exceeded. Blanket "deny icmp any any" is how well-meaning hardening turns into next quarter's mystery outage. On Cisco gear, note that no ip unreachables on an interface suppresses the very messages that would have told a user why their traffic was dropped, trading diagnosability for a marginal security gain.
The Full Ping Cluster, in Reading Order
Read start to finish for a complete grounding, or jump to the one that matches the problem in front of you.
Frequently Asked Questions
Does ping use TCP or UDP?
Neither. Ping uses ICMP, which rides directly on IP as protocol 1. There is no port number involved, which is why "what port does ping use?" is a trick question, it doesn't use one. (The Windows and Linux tracert/traceroute tools differ: Linux traceroute defaults to UDP, Windows tracert uses ICMP.)
Why is the TTL in my ping reply 253 and not 255?
The TTL shown belongs to the reply, which the destination created with its own initial value and each router on the return path decremented by one. A Cisco device starts at 255, so 253 means two routers sat between it and you on the way back. Linux starts at 64 and Windows at 128, so a reply of 64 or 128 usually means the target is on your local segment with no routers in between.
What does "Request timed out" or 100% packet loss with no error mean?
It means nothing answered your echo within the timeout, and crucially, no device sent back an error explaining why. That points to a silent drop: a firewall configured to deny without sending unreachables, a broken return path, or a host that is down behind a stateless device. Run a traceroute to find the hop where replies stop. This is different from an explicit "unreachable," which names the responsible device.
Why does ping work but the website or application won't load?
Because ping only tests ICMP reachability at Layer 3. The application depends on higher layers: a listening service, an open TCP port (often 443), working DNS, and valid TLS. A firewall can permit ICMP while blocking TCP 443, or DNS can be broken while the IP is perfectly reachable. A successful ping narrows the problem to "above Layer 3," which is genuinely useful, but it is not proof the service works.
Is it safe to block all ICMP for security?
No, not blanketly. Blocking ICMP Fragmentation Needed (type 3 code 4) breaks Path MTU Discovery and creates connections that hang mysteriously, and blocking Time Exceeded (type 11) breaks traceroute. Rate-limit echo requests and block what you genuinely don't need, but always permit fragmentation-needed messages. Blunt "deny all ICMP" rules are a common source of self-inflicted outages.
How do I ping an IPv6 link-local address?
You must specify the interface, because link-local addresses (fe80::/10) are not globally unique and the kernel cannot know which interface you mean. Use ping -6 fe80::1%ens224 or ping -6 -I ens224 fe80::1. The same interface-selection issue causes confusing "Address unreachable" errors on multi-homed hosts even for global addresses, as shown in the Linux options article.
Key Takeaways
- Ping is ICMP echo request (type 8) out, echo reply (type 0) back. No TCP, no UDP, no ports.
- The reply's TTL, counted down from 64/128/255, tells you the return-path hop count; mdev in the stats line is your jitter reading.
- Failures split into silent (100% loss, no message) and loud (an ICMP error whose From address locates the fault). The failure mode is the diagnosis.
- Extended ping's
sourceoption tests the return path; IOS response characters (!.UM) compress the outcome, andU.U.Uis rate-limiting, not flapping. - Ping with the DF bit finds path MTU; remember Linux
-sis payload (+28 for the wire) while Ciscosizeis the whole packet. - Sweep with a bash loop for speed or
nmap -snfor accuracy, and never read "down" as "absent." - Don't blanket-block ICMP: fragmentation-needed and time-exceeded keep the network working.
Start with how ping works, or browse all fourteen concept guides in the PingLabz guide library.