Ping asks whether a host answers and how long the round trip took. Traceroute lists the routers between you and it. Ping tells you whether the path works. Traceroute tells you where it stops working. Most alarming traceroute output is a router deprioritizing ICMP rather than a fault, and neither command shows the return path.
- A ping reply proves ICMP is answered, not that a service runs
- Asterisks mid trace are normal, and hops after them prove it
- One slow hop is a busy router, not a busy path
- Windows probes with ICMP, Linux with UDP, which explains disagreements
- mtr is both commands at once, and the one to send a provider
On this page
PingHow ping actually works
Ping and traceroute are two commands built on the same idea, and the first of them is the simpler. The ping command sends ICMP echo requests and waits for echo replies. That is the entire mechanism, and its simplicity is why the output is so often misread.
A successful reply proves three things and no more: a route exists to the remote host, a route exists back, and the device's network stack is answering ICMP requests. It proves nothing about whether the service you care about is running. A server can answer ping perfectly while the web server process on it is dead.
The time reported is the round trip, out and back together. It is not the one way latency, and halving it is only a rough guess because the two directions can take different paths.
The output is worth reading field by field.
The reply time is the round trip in milliseconds. Consistency matters more than the number: a steady 40 ms to a remote server is healthier than a figure jumping between 5 and 300.
TTL in the reply is what remains of the time to live counter, and it hints at the hop count. Most devices start at 64 or 128, so a TTL of 57 suggests seven hops.
Packet loss, on the summary line, is the number that matters most. Consistent loss above a percent or two on a wired network is a fault. Occasional loss of packets to one busy internet host often is not.
Request timed out means no reply arrived. That is not the same as unreachable, because plenty of devices are configured not to answer ICMP requests at all.
TracerouteHow traceroute actually works
The traceroute command is a clever trick rather than a protocol, and understanding the trick explains every strange thing in its output.
Every IP packet carries a time to live field, decremented by one at each router. A router that decrements it to zero discards the packet and sends back an ICMP time exceeded message, which necessarily comes from that router's own address.
The traceroute command exploits that. It sends packets with TTL 1, and the first router announces itself by discarding one. Then TTL 2, and the second router does. It walks outward one hop at a time, until a packet survives to the remote host and that host answers differently, which is how the command knows to stop.
Three probe packets are sent per hop, which is why each line shows three times. Different values across those three are normal and reflect ordinary queuing on the network.
The probe packets are not the same on every platform, and this is a real source of confusion. The Windows tracert command uses ICMP.
The Linux and macOS traceroute command uses UDP to high numbered ports by default, and traceroute -I switches to ICMP. If two people trace the same path and get different results, this is usually why: firewalls treat those protocols differently.
Reading the outputReading traceroute output without panicking
This section is the reason most people misdiagnose with this tool.
Asterisks in the middle, with the trace continuing, are almost always fine. A router that does not answer probe requests still forwards data perfectly well. Many deliberately do not answer. If hop 7 shows three asterisks and hops 8 through 15 respond normally, that device is not the problem.
Asterisks all the way to the end mean the trace stopped. Either network connectivity genuinely breaks there, or a firewall closer to the remote host is dropping the probes. Both are common and they look identical.
A latency spike at one hop that does not persist is not a problem. Routers generate ICMP replies as a low priority background task, so a busy core device can take 80 ms to answer a probe while forwarding real data in under a millisecond. Only a spike that continues through every subsequent hop indicates something real.
The return path is invisible. The traceroute command maps the outbound direction. Replies may come back a different way entirely, and asymmetric routing is normal on the internet. A one sided trace explains half the picture, which is why serious diagnosis asks for a trace from both ends.
Hostnames are hints, not facts. Router names often encode a city or a carrier and they are frequently stale. A hostname suggesting Frankfurt does not prove the packets went to Frankfurt.
Private addresses appearing partway through are normal inside a carrier network and mean nothing on their own.
| What you see | What it usually means | What to do next |
|---|---|---|
| Reply from the gateway, nothing beyond | Routing or the internet link | Trace outward from the gateway |
| Address works, hostname does not | DNS, not the network | Check the resolver, not the cable |
| Asterisks mid trace, then normal hops | A router declining to answer | Nothing, it is forwarding fine |
| Asterisks from one hop to the end | A break, or a firewall near the far end | Trace from the other side |
| One slow hop, fast hops after it | Low priority ICMP on a busy router | Nothing, it is not the fault |
| Latency rising and staying high | Congestion at that hop onward | Run mtr, then send it to the provider |
| Loss at every hop equally | The measurement, not the path | Trust the destination figure only |
| 169.254 address on the machine | No DHCP answer, before any of this | Fix addressing first |
The last three rows are the ones that save the most time. Loss reported at every hop is an artifact of how the probes are answered rather than a path losing packets, and a machine that gave itself an address never reached the network at all.
The commandsThe commands worth knowing
The command options that turn a rough check into a useful measurement.
# Keep pinging, to see whether loss is constant or bursty
ping -t 8.8.8.8 # Windows
ping 8.8.8.8 # Linux and macOS, runs until stopped
# A count and a larger payload, to test for MTU problems
ping -n 20 -l 1472 -f 10.2.0.10 # Windows, do not fragment
ping -c 20 -s 1472 -M do 10.2.0.10 # Linux
# Trace with ICMP instead of UDP, matching Windows behavior
traceroute -I example.com
# Trace to a specific TCP port, which gets through firewalls that drop the rest
traceroute -T -p 443 example.com
# Both tools at once, continuously, which is what you actually want
mtr example.comThe last command deserves the attention. mtr runs the traceroute repeatedly and shows running loss and latency statistics for every hop at once.
A single traceroute is one sample of a changing network path. mtr over a minute distinguishes a genuine connectivity problem from a moment of congestion, and it is the command to reach for before reporting anything to a provider.
MethodA diagnostic order that works
Working outward from the local device finds the fault faster than starting at the remote end.
Ping the loopback address. If 127.0.0.1 fails, the network stack on the device is broken and nothing else you test will mean anything.
Ping your own address, then the default gateway. A gateway that does not answer means a local connectivity problem: cable, switch port, VLAN, or an address the device should not have.
Ping a server on the internet by address, such as 1.1.1.1 or a Google DNS address. Success here with failure by name is a DNS problem, and that distinction is worth two minutes of anybody's time.
Run the same command with a hostname, such as ping google.com. If the address works and the name does not, the fault is DNS and the network is fine.
Run traceroute to the remote host, and read the output with the rules above.
Run mtr for a minute if the traceroute looked suspicious, because one sample proves very little.
PitfallsWhere people go wrong
Concluding a server is down because the ping command times out. Many hosts and most cloud firewalls drop ICMP requests by default. Test the actual service on its port before declaring anything down.
Blaming the hop with the asterisks. A non responding router in the middle of an otherwise healthy trace is a configuration choice, not a fault.
Blaming the hop with high latency. ICMP replies are generated at low priority. Only latency that persists through every following hop is real.
Diagnosing from one direction. Asymmetric routing means a clean outbound trace can coexist with a broken return path. Ask for a trace from the far end.
Using the default packet size to test throughput. The ping command sends 32 or 64 bytes of data. That says nothing about the behavior of full sized packets, which is a separate test with the do not fragment flag set.
Sending a single traceroute to a provider as evidence. They will ask for continuous data from both directions, because one sample of a network path that changes is not evidence of anything. Send mtr output instead.
ComparisonPing, traceroute and mtr, on what each one can actually tell you
| Criterion | Ping | Traceroute | mtr |
|---|---|---|---|
| Answers "is it reachable" | Yes | Yes | Yes |
| Shows the path | No | Yes | Yes |
| Shows loss per hop | No | No | Yes |
| Distinguishes a blip from a fault | Over time | No | Yes |
| Available everywhere by default | Yes | Yes | No, install it |
| Good enough for a provider ticket | No | No | Yes |
| Shows the return path | No | No | No |
The last row applies to all three, and it is the limitation to remember. Nothing in this family shows you the way back.
FAQFrequently asked questions
What is the difference between ping and traceroute?
Ping asks whether a host answers and how long the round trip took. Traceroute lists the routers between you and it. Ping tells you whether the path works, traceroute tells you where it stops.
Why does ping fail when the website works?
Because many hosts and firewalls drop ICMP while still serving traffic on their real ports. A timeout is not proof of anything being down.
What do the asterisks in traceroute mean?
That a hop did not reply to the probes. If the trace continues past it, the hop is forwarding traffic normally and simply declines to answer.
Why is one hop slow but the ones after it are fast?
Because generating an ICMP reply is a low priority task for a busy router. Only latency that persists through all following hops is a real problem.
What is the difference between tracert and traceroute?
The same idea on different platforms. Windows tracert probes with ICMP. Linux and macOS traceroute probe with UDP by default, and -I switches to ICMP.
Does traceroute show the return path?
No. It maps the outbound direction only. The replies may travel a different route entirely, which is why diagnosis needs a trace from both ends.
What is a good ping time?
On a local network, under a millisecond. Across a country, 10 to 40 ms. Across an ocean, 80 to 200. Consistency matters more than the number.
What does TTL mean in ping output?
What remains of the packet's time to live counter. Since most systems start at 64 or 128, the difference indicates roughly how many routers it crossed.
What is mtr and why is it better?
It runs traceroute continuously and reports loss and latency per hop over time. That distinguishes a moment of congestion from a persistent fault, which a single trace cannot do.
How do I test whether a specific port is open?
Not with ping. Use Test-NetConnection -Port 443 host on Windows, or nc -zv host 443 on Linux and macOS.
Why do I get different results than a colleague?
Different probe protocols, different paths, or different treatment by firewalls along the way. Compare like with like before drawing conclusions.
Can I use ping to test bandwidth?
No. It measures round trip time and loss for small packets. Bandwidth needs a real transfer or a tool such as iperf.
How do ping and traceroute help with network latency troubleshooting?
For network latency troubleshooting, ping shows the round trip time and whether it is steady, and traceroute shows where along the path the delay begins. A jump in latency that persists through every later hop marks the problem link. A single slow hop that later hops do not inherit is only a router deprioritizing its replies.
What is the trace route command on Windows, Linux and macOS?
The trace route command is tracert on Windows, so the traceroute cmd line is tracert followed by a host name or address. On Linux and macOS it is traceroute. Both print each router on the path with three round trip times, and an asterisk where a hop did not answer.
What is the continuous ping command?
On Windows the continuous ping command is ping -t followed by the address, and Ctrl and C stops it. On Linux and macOS ping runs continuously by default, and -c sets a count instead. A continuous ping is the quickest way to watch a link drop and recover while you change something.
Keep readingRelated concepts
Read next · Protocols TCP vs UDP Traceroute probes with UDP on Linux and ICMP on Windows, which is why two people get different results. Open this next10 min- Addressing · 9 min What Is DHCP? A machine that gave itself a 169.254 address never reached the network, and no amount of tracing will help.
- Ports · 12 min What Is a Port Number? Ping cannot tell you whether a port is open, and that is a different test entirely.
- Windows administration · 10 min CMD Commands Grouped by Job, With the Ones That Can Destroy Data The Windows commands for files, network, disks and accounts, grouped by the job they do.
- Switching · 11 min Spanning Tree Protocol The protocol behind loss that appears across the whole network at once for a second.
- Routing · 12 min OSPF Explained The protocol behind a path that changed between one trace and the next.
- DNS · 14 min DNS Not Resolving What to check once ping has proved the network is fine and names still fail.
- Addressing · 10 min Default Gateway The route being traced, and the first hop in every trace you will run.
- Protocols · 11 min What Is ICMP? The protocol underneath both of these commands, and the types they depend on.
- Diagnostics · 12 min Reading a Wireshark Capture Without Drowning in Packets The two commands worth running before you reach for a capture at all.
- Cabling and connectivity · 11 min T568A vs T568B, and Why the Answer Is Almost Never Both The first commands to run when a cable links but the connection is wrong.
- Diagnostics · 11 min Packet Loss vs Latency, and Why They Feel the Same to Users How to run the test this page is about reading.
- Diagnostics · 11 min A Network Troubleshooting Checklist, in the Order That Saves Time How to run the tests the middle of this checklist depends on.