18.3 Ping / Traceroute

Understanding Ping and Traceroute

Ping and traceroute are two of the most useful tools for checking network connectivity and paths. They are simple to run, available on almost every operating system, and give you quick insight into whether packets can travel between two points and how they get there.

In this chapter you focus on what ping and traceroute actually do, how to read their output, and how to apply them during troubleshooting, without re-explaining ICMP or routing protocols in detail since those have their own chapters.

What Ping Actually Does

Ping is a basic connectivity test between your device and another IP address. When you run ping, your device sends special test messages and waits to see whether a response comes back and how long it takes.

On most systems ping sends ICMP Echo Request messages and waits for ICMP Echo Reply messages. If replies arrive, you know the target is reachable at the network level and you get timing information for each reply.

From a troubleshooting perspective, ping answers a few key questions.

First, "Can I reach this IP at all?" If there is no reply, that might indicate a local problem on your device, a problem with the network, or that the target is down or blocking ping. Second, "How long does it take for packets to go there and back?" The time is usually shown as round trip time, often written as RTT, which measures delay. Third, "Are packets getting lost along the way?" Ping sends multiple test packets. If some do not get replies, you see packet loss, which may indicate congestion or unreliable links.

Ping operates at the network layer from a logical point of view, since it targets IP addresses and uses IP routing, and it uses ICMP as its transport mechanism. It does not test whether an application is working, such as a web server, only whether basic IP connectivity is present.

Basic Ping Usage on Different Systems

Although the concept is the same, the exact command syntax for ping differs slightly between operating systems. The core idea is always: specify a destination, optionally tweak how many packets you send, and then read the output.

A simple ping example looks like this:

On Windows:

ping 8.8.8.8

On Linux or macOS:

ping 8.8.8.8

The main difference is that on Windows ping sends a small fixed number of packets by default, while on Linux or macOS ping continues to send packets until you stop it with a key combination, often Ctrl+C.

Here is a general comparison of some common ping options you will see:

You do not need to memorize every option, but you should recognize that there is almost always an option to limit the number of packets, to set timeouts, and often to change the packet size.

Reading Ping Output

Ping output focuses on three kinds of information: replies for each packet, summary statistics, and sometimes hostname information.

A typical successful ping on a Linux system might look like this:

`PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=11.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=12.1 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=11.8 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 11.800/12.025/12.300/0.187 ms`

Each reply line tells you how large the reply was, which sequence number it corresponds to, the TTL value when it arrived, and the round trip time in milliseconds.

The key part of the summary is the number of packets transmitted and received, the percentage of packet loss, and the timing statistics. The minimum, average, and maximum values give you a small picture of how stable or unstable the path is for that test.

On Windows you might see output like this:

`Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=15ms TTL=115
Reply from 8.8.8.8: bytes=32 time=14ms TTL=115
Reply from 8.8.8.8: bytes=32 time=14ms TTL=115
Reply from 8.8.8.8: bytes=32 time=15ms TTL=115

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms`

The ideas are the same, just formatted slightly differently.

Ping Latency and Packet Loss

Two numbers in ping output matter a lot during troubleshooting: round trip time and packet loss percentage.

Round trip time shows how long it took the test packet to go from your device to the destination and back. Values depend on physical distance, number of hops through routers, and current load. For example, pinging a device in the same local network might give times like 1 ms to 5 ms. Pinging a device on another continent might give times like 100 ms to 200 ms.

When you see occasional spikes, such as one reply at 300 ms while others are at 20 ms, that can indicate temporary congestion or a router briefly busy with other tasks. If you consistently see high times, users may experience lag in interactive applications, such as voice calls or online games.

Packet loss is the percentage of test packets that never receive a reply. In the ping summary it is usually shown as a percentage:

10 packets transmitted, 9 received, 10% packet loss

Small packet loss, such as 1% to 2%, might not be noticeable for some applications, but it can still harm real time services. High packet loss often indicates a serious issue, such as a bad link, strong congestion, or a misconfigured or failing device.

It is important to remember that ping uses ICMP. Some devices treat ICMP as low priority traffic. For this reason, a bit of packet loss in ping does not always mean user applications are failing, but it is almost always a useful warning sign to investigate further.

Common Ping Problems and Their Meanings

During troubleshooting you will see a few common failure messages when using ping. Each suggests a different kind of problem.

If you see something like "Destination host unreachable" from your own device or from a router along the way, that usually means there is no valid route to the destination from that point. You can then focus on routing configuration and network paths, not on the application.

If you see "Request timed out" or "100% packet loss" with no replies at all, there are several possibilities. The target might be powered off or disconnected. A firewall might drop ICMP packets. There might be a break somewhere along the path. In this situation it is useful to try pinging closer devices, such as your default gateway, to see how far you can reach.

If you see mixed results, such as some replies and some timeouts, that can mean intermittent connectivity problems, congestion, or a device that is overloaded and sometimes too busy to respond.

Some devices and networks intentionally ignore ping to reduce exposure or resource use. In that case, ping alone cannot prove that the destination is down. You may need to test with other tools, such as application specific checks, for example, a web request to a web server.

Ping Variations and Useful Options

Beyond the simplest use, ping has several options that can help you see different aspects of the connection.

You can increase the packet count to observe behavior over a longer period, which is helpful for intermittent issues. On Linux or macOS you might use ping -c 100 8.8.8.8 to send 100 pings in a row. On Windows you might use ping -n 100 8.8.8.8.

You can change the packet size to test how the network handles larger packets. For example, on Windows ping -l 1400 8.8.8.8 sends 1400 byte payloads in each requested packet. This can help reveal problems with maximum transmission unit when combined with additional options that prevent fragmentation on platforms that support them.

You can set a longer wait time if you expect slow replies, such as when pinging very distant networks. For instance, ping -W 5 on Linux lets the tool wait up to 5 seconds for a reply.

In everyday troubleshooting, you will most often change only the count and occasionally the packet size, but it is worth knowing that ping can be tuned to match specific tests.

What Traceroute Actually Does

Traceroute shows the path that packets take from your device to a destination, step by step, through the network. Instead of only telling you whether you can reach the target, it lists each router, often called a hop, along the way and how long it takes to reach each one.

This is very useful when there is a problem somewhere in the middle of the network. Ping tells you that the end-to-end path is failing or slow. Traceroute helps you see where the problem might be located.

Traceroute works by sending packets with intentionally small values for the time to live field, often written as TTL. TTL is a field in the IP header that decreases by 1 at each router. When TTL reaches 0, the router discards the packet and sends back an ICMP Time Exceeded message. Traceroute uses this behavior to discover each hop.

Here is the basic idea.

First, traceroute sends a probe packet to the destination with TTL set to 1. The first router reduces TTL to 0, discards the packet, and sends back an ICMP Time Exceeded message. Traceroute records the address of that router as hop 1. Next, traceroute sends another probe with TTL set to 2. That packet reaches the second router, where TTL becomes 0. That router discards it and sends back its own ICMP Time Exceeded message. Traceroute records that as hop 2. This continues, with TTL increasing by 1 each time, until the packet finally reaches the destination. The destination typically responds with a different ICMP message or with a response from the destination application, depending on the implementation.

In this way, traceroute gradually discovers the chain of routers between you and the target, and measures the round trip time for each hop.

Traceroute Implementations on Different Systems

There are two common user commands that provide traceroute functionality, one mostly used on Windows and one on Unix-like systems.

On Windows the command is usually tracert, for example:

tracert 8.8.8.8

On Linux and macOS the command is usually traceroute, for example:

traceroute 8.8.8.8

The underlying behavior can differ a bit between implementations, such as whether they use ICMP or UDP packets as probes, but the principle is always the same: increase TTL step by step and watch the responses.

On some modern systems there is a tool called mtr that combines ping and traceroute behavior into a continuous view, but the basic traceroute concepts still apply.

Reading Traceroute Output

A typical traceroute output lists hops in order, along with up to three timing measurements for each hop. For example, on Linux:

`traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 1.123 ms 0.987 ms 1.045 ms
2 10.0.0.1 5.321 ms 5.287 ms 5.300 ms
3 203.0.113.5 10.456 ms 10.412 ms 10.398 ms
4 203.0.113.9 15.765 ms 15.712 ms 15.701 ms
5 8.8.8.8 20.987 ms 20.954 ms 20.932 ms`

Each line begins with the hop number, then the IP address or hostname of the router, then several timing values. These timings are separate probes to the same hop, often three probes, to show variation.

On Windows, a tracert output might look like this:

`Tracing route to 8.8.8.8 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.1.1
2 5 ms 5 ms 5 ms 10.0.0.1
3 11 ms 10 ms 10 ms 203.0.113.5
4 16 ms 16 ms 15 ms 203.0.113.9
5 21 ms 21 ms 21 ms 8.8.8.8

Trace complete.`

The interpretation is similar. Each hop corresponds roughly to a router or a layer 3 device along the path.

You may see hostnames instead of IP addresses if reverse DNS is enabled and working. While hostnames can be useful, they can also slow down traceroute if lookups are slow, and sometimes they can be turned off with an option such as -n to show only numeric addresses.

Interpreting Missing Hops and Asterisks

In real networks, traceroute output is not always perfect and clean. Often you will see asterisks, timeouts, or missing information for some hops.

Many traceroute tools show asterisks * when there is no response from a probe. For example:

` 5 *
6 198.51.100.12 45.321 ms 45.288 ms 45.310 ms`

A line like this means that none of the probes to hop 5 received a visible response in time. This does not always mean the hop is broken. It might be configured to not send ICMP Time Exceeded messages, or it might rate limit them. Traffic still could pass through the hop successfully.

Sometimes you see one or two of the three probes respond, with one or more asterisks in the same line, such as:

7 198.51.100.20 60.111 ms * 60.345 ms

This suggests that the router at hop 7 is reachable, but sometimes it does not answer the probes. It might be busy or rate limiting.

It is important to look at the pattern for the whole trace. If later hops respond normally, then packets are likely flowing through the earlier hops even if those hops themselves do not respond to traceroute probes.

If traceroute stops completely before reaching the destination and later hops never appear, that is more serious. It can indicate a routing problem, a firewall blocking traffic beyond a certain point, or a failure on that or a later hop.

Traceroute and Latency Changes Along the Path

One of traceroute’s strengths in troubleshooting is showing where delay increases. By comparing timings between consecutive hops, you see where latency jumps. For example:

` 1 192.168.1.1 1 ms 1 ms 1 ms
2 10.0.0.1 5 ms 5 ms 5 ms
3 203.0.113.5 10 ms 11 ms 10 ms
4 203.0.113.9 120 ms 121 ms 119 ms
5 8.8.8.8 122 ms 123 ms 121 ms`

In this trace, notice how the timing between hop 3 and hop 4 increases by about 100 ms. That is often a clue that the link or network segment around hop 4 is where significant delay is being introduced. The final hop has a similar high delay, which is expected, because overall delay includes that segment.

In contrast, some hops might show high times, but later hops are low and stable. That can happen because some routers de-prioritize or slow down replies to traceroute probes, without affecting normal forwarded traffic. For example:

` 3 203.0.113.5 90 ms 100 ms 95 ms
4 203.0.113.9 15 ms 16 ms 17 ms
5 8.8.8.8 16 ms 16 ms 16 ms`

In this case, hop 3 looks slow, but later hops including the destination are fast, so user traffic probably does not suffer. The delay is likely only affecting the router’s replies to traceroute itself.

For this reason, the most useful latency information in traceroute is often the delay at the final destination and any large jump that persists from a certain hop onwards.

Using Ping and Traceroute Together

Ping and traceroute complement each other when you diagnose network problems.

You can use ping as a quick reachability test. If ping to a destination succeeds with low loss and reasonable times, there is usually no need to run traceroute unless you are doing deeper analysis or capacity planning. If ping fails, traceroute can show where the path breaks.

You can also use ping to test reachability of intermediate devices that traceroute reveals. For example, if traceroute shows that traffic stops responding after hop 7, you can try pinging hop 7 itself to see if that router still answers. If hop 7 pings fine but later hops never appear, the issue is likely beyond hop 7. If hop 7 itself is unreachable, then the problem may be at or before hop 7.

A typical troubleshooting flow might look like this in practice, without going into overall methodology from the parent chapter. First, ping your own default gateway to check local network connectivity. Next, ping a known external address, such as a public DNS server, to see if you can reach the wider network or internet. If that ping fails, run traceroute to that address to see how far traffic goes and where it stops. Based on that information, decide whether the issue is local, at the edge of your network, or somewhere upstream.

Ping tells you "if" and "how well" you can reach something. Traceroute tells you "where" packets travel. Together, they give a powerful picture of connectivity issues.

Limitations and Caveats of Ping and Traceroute

While ping and traceroute are invaluable, they have limitations that you must keep in mind.

Both tools depend on ICMP or special probe packets. Firewalls may block or restrict these, routers may rate limit them, and some hosts may ignore them. As a result, failure or delay recorded by these tools does not always equal failure for real user traffic, but it is usually a strong indication that needs correlation.

Routers are often optimized for forwarding normal traffic, not responding to diagnostic probes. That means that the timings to intermediate hops can be misleading. High values at one hop do not always mean that hop slows user traffic. You must always compare with timings at later hops and at the destination.

Traceroute does not always show the exact path for all flows. Load balancing in modern networks may send different packets along different paths, especially if multiple equal cost routes are available. Traceroute can sometimes show different paths in repeated runs, which can be confusing but is normal behavior in some designs.

Neither ping nor traceroute tests application level behavior directly. A web server could be reachable from ping but still return errors when users browse it. Ping and traceroute are mainly for the lower layers that focus on connectivity and path.

Finally, because these tools send repeated probes, they should be used sensibly. Very aggressive testing with large packets or very frequent pings can add unnecessary load, especially on constrained networks or devices.

Practical Tips for Beginners

When you start working with ping and traceroute in practice, it helps to follow a few simple habits.

Always test from the simplest and closest point first. For example, confirm you can ping your default gateway before you worry about distant servers. Save the traceroute output when you investigate a problem, since having a record helps compare with future behavior and with what others see from different locations.

Use numeric options, like disabling name resolution, when DNS might be part of the problem. For instance, on many traceroute tools the -n option shows only IP addresses, which makes the tool faster and avoids confusion caused by DNS delays.

Look for patterns across multiple runs, rather than reacting to a single ping failure or a single traceroute line with asterisks. Networks can have temporary blips. Persistent loss or consistently high latency is more meaningful.

Most importantly, treat ping and traceroute as clues, not as absolute truth. Combine their results with logs, application checks, and other tools covered in this section of the course to form a full picture of what is happening in the network.

Key Concepts to Remember

To end, it is useful to summarize the most important conceptual rules about ping and traceroute that you should internalize.

If you can confidently run ping and traceroute, read their outputs, and understand where they fit in the troubleshooting process, you have gained two essential skills for working with networks of any size.