Ping and Traceroute: Network Troubleshooting Tools

Ping and Traceroute

Ping and traceroute are two of the most fundamental network diagnostic tools available to anyone troubleshooting connectivity problems. Ping tells you whether a remote host is reachable and how long packets take to travel there and back. Traceroute maps the path those packets take through the network, revealing every router hop along the way and where delays or failures are occurring. Together they form the starting point for almost every network investigation.

What Is Ping

Ping is a command-line tool that tests whether a specific host on a network is reachable from your device and measures the round-trip time for packets to travel to that host and back. It works by sending ICMP Echo Request packets to the target host and listening for ICMP Echo Reply packets in response. If replies arrive, the host is reachable. If they do not, something between your device and the destination is preventing communication.

ICMP stands for Internet Control Message Protocol. It is a network-layer protocol used by devices to send error messages and operational information about network conditions. Ping uses the specific ICMP message types designed for connectivity testing: the Echo Request sent by the sender and the Echo Reply sent back by the recipient. These messages are lightweight and do not use TCP or UDP, operating directly at the IP layer.

Ping was written by Mike Muuss in 1983 and named after the sound of sonar, which similarly sends out a pulse and listens for its return. It remains one of the most universally available network tools, built into every major operating system including Windows, macOS, Linux, and most network device firmware. Despite its simplicity, it reveals a surprising amount of useful diagnostic information in its output.

Reading Ping Output

Understanding what ping's output tells you is essential for using it effectively. Each line of output corresponds to one ICMP Echo Request and its reply, providing timing information and sequence numbers that reveal patterns in the connection.

ping google.com

PING google.com (142.250.179.46): 56 data bytes
64 bytes from 142.250.179.46: icmp_seq=0 ttl=117 time=12.4 ms
64 bytes from 142.250.179.46: icmp_seq=1 ttl=117 time=11.8 ms
64 bytes from 142.250.179.46: icmp_seq=2 ttl=117 time=12.1 ms
64 bytes from 142.250.179.46: icmp_seq=3 ttl=117 time=13.0 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.8/12.3/13.0/0.4 ms

ping google.com

Pinging google.com [142.250.179.46] with 32 bytes of data:
Reply from 142.250.179.46: bytes=32 time=12ms TTL=117
Reply from 142.250.179.46: bytes=32 time=11ms TTL=117
Reply from 142.250.179.46: bytes=32 time=12ms TTL=117
Reply from 142.250.179.46: bytes=32 time=13ms TTL=117

Ping statistics for 142.250.179.46:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 11ms, Maximum = 13ms, Average = 12ms

Each field in the output carries diagnostic meaning. The resolved IP address confirms that DNS resolution is working correctly. The TTL value shows how many hops the packet traversed before reaching your device, calculated by subtracting the received TTL from the starting TTL of the remote operating system, which is typically 64, 128, or 255 depending on the OS. The time value is the round-trip latency in milliseconds. The summary statistics show packet loss percentage and minimum, average, and maximum round-trip times, which together reveal whether the connection is stable or experiencing intermittent problems.

Common Ping Options

What Is Traceroute

Traceroute is a network diagnostic tool that maps the path packets take from your device to a destination host, showing every router hop along the way and the latency at each one. While ping tells you whether a host is reachable and how long it takes, traceroute shows you exactly where in the network path any slowness or failure is occurring. This makes it the essential next step when ping reveals a problem but does not explain where it is happening.

Traceroute works by exploiting the IP Time-to-Live field. Every IP packet carries a TTL value that decrements by one at each router hop. When a packet's TTL reaches zero, the router that decremented it to zero drops the packet and sends an ICMP Time Exceeded message back to the original sender, including its own IP address in the response. Traceroute sends packets with progressively increasing TTL values, starting at one. The first packet expires at the first router, which reveals its address. The second packet expires at the second router, and so on, until the destination is reached.

On Linux and macOS, traceroute uses UDP packets by default, sending them to high-numbered destination ports that are unlikely to be in use on the target. On Windows, the equivalent command is tracert and uses ICMP Echo Requests by default, the same message type as ping. Both approaches achieve the same result of provoking TTL Exceeded responses from intermediate routers, though some routers and firewalls respond differently to ICMP versus UDP probes.

Reading Traceroute Output

Traceroute output shows one line per hop, numbered sequentially from your device to the destination. Each line includes the hostname and IP address of the router at that hop if available, and three latency measurements representing three separate probe packets sent to that hop.

traceroute google.com

traceroute to google.com (142.250.179.46), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)          1.2 ms   1.1 ms   1.0 ms
 2  10.0.0.1 (10.0.0.1)                8.3 ms   8.1 ms   8.4 ms
 3  isp-router.net (203.0.113.1)       12.4 ms  12.2 ms  12.5 ms
 4  * * *
 5  core-router.net (198.51.100.5)     18.7 ms  18.9 ms  18.6 ms
 6  74.125.242.49 (74.125.242.49)      20.1 ms  20.3 ms  20.0 ms
 7  142.250.179.46 (142.250.179.46)    12.3 ms  12.1 ms  12.4 ms

tracert google.com

Tracing route to google.com [142.250.179.46]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  192.168.1.1
  2     8 ms     8 ms     8 ms  10.0.0.1
  3    12 ms    12 ms    12 ms  isp-router.net [203.0.113.1]
  4     *        *        *     Request timed out.
  5    18 ms    19 ms    18 ms  core-router.net [198.51.100.5]
  6    20 ms    20 ms    20 ms  74.125.242.49
  7    12 ms    12 ms    12 ms  142.250.179.46

Trace complete.

Hop 1 is always your local router or gateway. The latency values at each hop are the round-trip times from your device to that specific router, not the time between consecutive hops. Latency generally increases with each hop as the packet travels further. Hop 4 showing three asterisks means that router did not respond to the traceroute probe, either because it is configured to silently drop TTL Exceeded messages or because a firewall blocks them. This does not mean the path is broken. If subsequent hops respond normally, the silent hop is simply not revealing itself.

Interpreting Traceroute Results

Reading traceroute output correctly requires understanding several patterns that indicate different network conditions. Raw numbers alone are not enough without context about what they mean.

Ping vs Traceroute

Ping and traceroute complement each other and are most useful when used together as part of a systematic diagnostic process. Understanding what each one is best suited for helps you reach conclusions faster when troubleshooting.

A Practical Diagnostic Workflow

Ping and traceroute are most effective when used as part of a structured diagnostic approach rather than run once and interpreted in isolation. The following workflow covers the most common connectivity problems systematically.

1. Ping the local gateway first: Run ping 192.168.1.1 or whatever your router's IP address is. If this fails, the problem is between your device and your router, which is a local network issue rather than an internet issue.
2. Ping a public IP address: Run ping 8.8.8.8 to test basic internet connectivity without involving DNS. If this succeeds but domain names do not resolve, the problem is DNS rather than connectivity.
3. Ping a domain name: Run ping google.com to confirm DNS resolution is working. If the IP resolves but the ping fails or is very slow, there may be a routing or firewall issue with that specific destination.
4. Run traceroute to a failing destination: If ping to a destination fails or shows high latency, run traceroute to that same destination. Look for where in the path the asterisks begin or where latency jumps significantly.
5. Compare traceroute to a working destination: Run traceroute to a destination that is working normally and compare the paths. If both paths share the same slow hop, the problem is upstream of your network. If only one path is affected, the issue is specific to that destination or the route to it.
6. Run extended ping to measure packet loss: Run ping -c 100 destination to send enough packets to get a statistically meaningful packet loss percentage. Occasional single packet loss is normal. Consistent loss above one percent indicates a real problem.

Limitations of Ping and Traceroute

Both tools have well-known limitations that are important to understand when interpreting their results. Taking output at face value without accounting for these limitations leads to incorrect conclusions.

Many servers, firewalls, and network devices are configured to block or deprioritise ICMP traffic. A host that does not respond to ping is not necessarily offline. Many busy web servers silently drop ping requests to prevent their ICMP handling from consuming resources under load. Google's servers respond to ping, but many production servers do not. Similarly, routers that silently drop TTL Exceeded messages appear as asterisks in traceroute output even though they are forwarding traffic correctly.

Traceroute measures the latency of ICMP or UDP probe packets, which many routers handle at lower priority than regular forwarding traffic. A router that shows 50ms latency in traceroute output may be forwarding actual data traffic through its hardware fast path at a fraction of that latency. This means high per-hop latency in traceroute does not always indicate congestion on the forwarding path. The pattern that matters is whether latency at subsequent hops remains elevated, which would confirm a real bottleneck rather than just deprioritised probe handling.

Traceroute also assumes that all packets take the same path through the network, which is not always true. Modern networks use load balancing techniques that can distribute packets across multiple paths, and some packets may take completely different routes even within the same traceroute run. This can cause apparently inconsistent latency values at certain hops and make the output harder to interpret than it appears.

Frequently Asked Questions

1. Why does ping fail even though the website loads in my browser?
   Many web servers and firewalls are configured to block ICMP packets, which is what ping uses. The server may be fully operational and serving web pages over TCP port 443, but simultaneously blocking all ICMP traffic. This is a deliberate security and resource management decision. A failed ping does not mean the host is down. It means the host either is not reachable or is not responding to ICMP specifically. Always verify by attempting to connect through the actual service protocol before concluding a host is offline.
2. What do the three asterisks in traceroute output mean?
   Three asterisks at a hop mean that router did not send back an ICMP Time Exceeded response within the timeout period. This happens when a router is configured to silently drop TTL Exceeded messages rather than responding to them, when a firewall between you and that router blocks the response, or occasionally when probe packets are lost in transit. If the hops after the asterisks respond normally, the router at that hop is working correctly and simply not revealing itself. Only if asterisks persist through all remaining hops does it indicate a genuine break in the path.
3. What is a good ping time and what is considered high latency?
   Latency expectations depend entirely on the distance between your device and the destination. A ping to your local router should be under 5 milliseconds. A ping to a server in the same country typically falls between 10 and 50 milliseconds. Intercontinental connections are typically 100 to 200 milliseconds. Satellite internet connections commonly show 500 to 700 milliseconds due to the distance signals must travel. For real-time applications like online gaming and video calls, latency above 100 milliseconds becomes noticeable and above 200 milliseconds causes significant degradation in experience.
4. Why is traceroute called tracert on Windows?
   Windows uses the name tracert because of the 8.3 filename limitation that existed in earlier versions of DOS and Windows, which restricted executable names to eight characters before the extension. Traceroute exceeds that limit, so Microsoft shortened it to tracert when implementing the tool. The two commands perform the same basic function, though they differ in their default probe method. Linux and macOS traceroute uses UDP by default while Windows tracert uses ICMP Echo Requests, which means they may produce slightly different results at hops that treat the two protocols differently.
5. Can ping be used to test DNS resolution?
   Yes, indirectly. When you ping a domain name rather than an IP address, your device must first resolve that domain to an IP address before it can send the ICMP request. If ping resolves and displays the IP address in its output, DNS resolution is working for that domain. If ping fails with a name resolution error rather than a timeout, it means DNS resolution is failing. This makes ping a quick way to verify both DNS resolution and basic connectivity in a single command, which is why pinging a domain name is a common first step in connectivity troubleshooting.
6. What is the difference between traceroute and MTR?
   MTR, which stands for My Traceroute, is a tool that combines ping and traceroute into a single continuously updating display. While traceroute runs once and shows a static snapshot of the path, MTR continuously sends probes to every hop along the route and updates the display in real time, showing live packet loss percentages and latency statistics for each hop simultaneously. This makes it much easier to spot intermittent packet loss at a specific hop because you can watch it accumulate over time rather than relying on a single snapshot. MTR is available on Linux and macOS and is the preferred tool for detailed network path analysis when a problem is intermittent rather than constant.

Conclusion

Ping and traceroute are the first tools any network troubleshooter reaches for, and understanding them deeply makes every subsequent diagnostic step more focused and productive. Ping establishes whether a host is reachable and provides the baseline latency and packet loss statistics that characterise the connection. Traceroute maps the path and pinpoints exactly where in the network any problem is occurring. Used together in a systematic workflow, they can diagnose the vast majority of network connectivity problems from a single command line. Knowing their limitations, particularly around ICMP filtering and ICMP deprioritisation by routers, prevents misinterpretation of silent hops and non-responsive hosts. For intermittent problems that a single traceroute snapshot cannot capture, tools like MTR extend these capabilities with continuous monitoring. To go deeper, explore packet loss and TCP retransmission, the DNS lookup process, Network Address Translation, and how routing works.