Traceroute and Ping

Ping and traceroute are common commands used for trouble shooting network problems. Ping is a simple command that can test the reachability of a device on the network. Traceroute is a command used to 'trace' the route that a packet takes when traveling to its destination. It's useful for tracing network problems, discovering where connections fail, and tracking down latency problems.

How does ping work?

Ping uses ICMP (Internet Control Message Protocol) Echo messages to see if a remote host is active or inactive, how long a round trip message takes to reach the target host and return, and any packet loss. It sends a request and waits for a reply (which it receives if the destination responds back within the timeout period). It's basically a quick, easy way to verify that you can reach a destination on the internet. If you can, great! If not, you can use traceroute to investigate what's happening at every step between your device and the destination.


hostname ~ % ping -c 5

PING ( 56 data bytes

The ping command, set to send 5 packets to

64 bytes from icmp_seq=0 ttl=113 time=42.262 ms

64 bytes from icmp_seq=1 ttl=113 time=34.796 ms

64 bytes from icmp_seq=2 ttl=113 time=35.805 ms

64 bytes from icmp_seq=3 ttl=113 time=45.299 ms

64 bytes from icmp_seq=4 ttl=113 time=150.292 ms

This shows the results from each individual ping, with their round trip time in milliseconds.

--- ping statistics ---

5 packets transmitted, 5 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 34.796/61.691/150.292/44.474 ms

The stats from the entire test - the minimum time it took to reach the destination, the average, the maximum, and the standard deviation.

How does traceroute work?

By default, traceroute sends three packets of data to test each 'hop' (when a packet is passed between routers it is called a 'hop'). It will first send 3 packets (by default, Windows uses ICMP while Linux uses UDP), to an unreachable port on the target host, each with a Time-To-Live (TTL) value of 1. This means that as soon as it hits the first router in the path (within your local network), it will timeout. The first router will respond with an ICMP Time Exceeded Message (TEM), as the datagram has expired.

Then another 3 datagrams are sent, with the TTL set to 2, causing the second router (likely your ISP) in the path to respond with an ICMP TEM. This continues until the datagrams eventually have a TTL long enough to reach the destination. When it does, as the messages are being sent to an invalid port, an ICMP port unreachable message is returned, signaling that the traceroute is finished. In this case, an error message is actually expected behavior, not a sign that something has gone wrong.

The most important part of a traceroute is usually the round trip times. Ideally you're looking for consistent times over the course of the trace. If you see times suddenly increase on a specific hop, and continue to increase as the trace approaches the target, this may indicate a problem starting with the sudden increase. However, if there is elevated latency in the middle, but it remains consistent toward the end, or if the elevated latency decreases toward the end, that doesn't necessarily indicate a problem. If you see high latency at the beginning of the trace, it may indicate a problem with your local network.

An example:

hostname ~ % traceroute

traceroute to (, 64 hops max, 52 byte packets

The command to traceroute to google.

1  homerouter.cpe (  10.129 ms  1.528 ms  1.373 ms

The first hop is within a local network. Here, we have the hop number (1), the domain name/IP address (in this case a home router), then RTT1, RTT2, and RTT3 (Round Trip Time - the time it takes for a packet to get to the hop and back to the computer, in milliseconds). This is the latency of the hop. There are three numbers because, by default, the command sends three data packets. In general, times over 150ms are unusual for a trip within the continental US, though signals crossing an ocean may exceed this time.

2  * * *

Hop 2: There are two possibilities for stars like this - either ICMP/UDP was not configured on the receiving device and it did not respond, or the packets were dropped due to a network issue (such as a firewall or packet timeouts). In this case, as it's very close to the beginning of the trace, it's likely that this is due to the device not being configured to send responses to a traceroute.

3 (  26.641 ms  31.671 ms  26.824 ms

4 (  20.294 ms  22.496 ms  19.922 ms

5  * * *

6  * * *

These stars, further along in the trace, are more likely to be due to a target's firewall  blocking requests (though HTTP requests should still be able to be processed in most cases - meaning that while you may be able to reach a hosted site (HTTP/HTTPS), the target may not respond to an ICMP/UDP packet), a possible connection problem, or a return path issue (i.e. the signal is reaching the router, but isn't getting a response).

The trace will then continue until it reaches the target.

Show Comments
As seen in: