Using Ping and Traceroute for Network Troubleshooting
There are a number of different tools that are available to help in the configuration and troubleshooting of networks. Many of these are included as part of the operating system which makes them even more useful because they are included on most computers automatically. This article takes a look at ping and traceroute (also known as “tracert“): two commands that are among the most commonly used tools used on Windows as well as their equivalents on other platforms. Their popularity has much to do with their basic simplicity: They offer a whole lot of output for very little input, and they can help in a number of different situations both during configuration and during troubleshooting.
What are the Ping and Traceroute Commands?
The Ping Primer
The ping command is used to determine whether a destination host is reachable. It does this by taking advantage of the Internet Control Message Protocol’s (ICMP) echo facility. An ICMP echo packet does exactly what it sounds like: It sends a packet out onto the network with the expectation of hearing a response. If the response comes back, then a host is reachable; if no response is received, then a problem has possibly occurred.
So why is this only a possibility and not a certainty? Because network security is such a big part of any modern Internet connection, ICMP echo packets are commonly not allowed through firewalls, whether host- or network-based. So if an ICMP echo is not received, it could mean either that the host is not reachable or that the device sits behind a firewall that does not allow this kind of packet. However, when the ping command is used for configuration or troubleshooting, it is typically used by a professional who is responsible for some part of an internal network; this means that if a firewall is the cause of an ICMP reply failure then it can be modified to allow the traffic temporarily for configuration and/or troubleshooting purposes.
The Traceroute Tutorial
The traceroute (or tracert) command is used to trace the path between a source and a specific destination. It does this by using the ICMP echo facility, but in a different way. To understand this, it is important to know what the Time to Live (TTL) value of the IP header is used for. The TTL value, at its simplest, is an allowed hop counter — if the TTL is set to 2, then the traffic is only allowed to pass through two different routing devices before being dropped. Now take this and combine it with an ICMP Echo packet. The first ICMP Echo packet will be sent with a TTL of 1, when the traffic will reach the first routing device and be dropped; the device that drops the traffic also sends a “TTL exceeded” message back to the source device, which is then used by the traceroute command to determine the first hops IP address (the source IP address of the TTL exceeded message). This process is then repeated until the destination is reached; e.g. the first TTL is 1, the second one is 2, then 3, etc.
How are the Ping and Traceroute Commands Used?
Both the ping and the traceroute commands are very simple to use. Below, Figure 1 shows the help that is offered with the ping command.
To set up a common situation where the ping command is used, let’s look at the IP configuration of our test machine, shown in Figure 2.
From this we can see that the device is configured with an IP address and a default gateway. To review, the default gateway is a device where traffic is sent for devices that are not on the same network (in this case, for those devices that don’t have an IP address from 192.168.1.1 through 192.168.1.254). What this means is that if this device tries to send traffic to, say, Google.com, the traffic must first travel through the device addressed with the IP address 192.168.1.2. It is common for a person troubleshooting a networking issue in which external devices are unreachable to start by testing the reachability of the configured default gateway. An example of this is shown in Figure 3.
It is, of course, possible to test the reachability of any device using the same syntax. Another task that the ping command is good at helping to resolve is intermittent networking problems, which are some of the hardest issues to troubleshoot. In the example shown below in Figure 4, the ping command is used with the -t option which tells the command to continually run until purposefully stopped. This can then be monitored for failures; it has the added benefit of increasing the amount of traffic sent over the network; often just the creation of consistent traffic aids in the ability to find a networking problem.
The traceroute command is just as easy to use. Below, figure 5 shows the help screen provided.
As stated above, the tracert command is used to trace traffic from its source to destination. In Figure 6, the path is traced from the test device to the IP address 188.8.131.52 (this is the public Google DNS server). As can be seen, from the test machine to the Google servers is at least 18 routing hops (I say “at least” 18 because some hops may be masked by network security measures). Without adding any additional options, the traceroute command will automatically attempt the DNS lookup of every IP address along the traced path.
Like the ping command, the traceroute command can be configured with a number of different options. One common one is the use of the -d option, which disables the automatic DNS naming lookups. This is commonly used because it can greatly increase the speed of the trace (as shown in Figure 7).
An example of why the traceroute command can be so important is shown in Figure 8: This is the exact same command which was issued in Figure 7 but entered a minute or so afterwards. What it shows is the change in the path between the test machine and the Google servers. Now, for the Google network this isn’t all that odd, as a single Google server name and address is answered by a number of different physical servers for optimal redundancy and efficiency.
The ping and traceroute commands are two of the most common utilities used by network engineers. Having a good handle on how they work and what they are used for is a big part of being a network engineer. The other advantage of these utilities is that they are very simple to use — this is quite handy for those attempting to troubleshoot issues remotely. Hopefully the contents of this article make the use of these utilities at least a little simpler and introduce those unfamiliar with these commands to them for their future use.