How to Troubleshoot Your Connections with Ping and Traceroute

The PING utility is one of the most famous and most helpful networking commands. It’s the first command that comes to mind when facing network reachability problems. It’s also the first command that needs to be issued when there is a need to find out whether a certain host is “alive” or not.
The ping command uses the services of the Internet Control Message Protocol (ICMP), the latter being encapsulated in the IP header. Therefore, the ping utility operates basically on layer 3 (the Network layer) of the OSI model. It does not use the services of the Transport layer, and the reason for that is that traffic reliability issues are not the case here. Ping performs a simple host lookup.
TRACEROUTE is another very helpful utility that operates similarly to ping and also uses the services of the ICMP protocol. Traceroute, as the name implies, is used to trace the path between the sender and the destination host. It is a one-way trace, meaning that it traces the route from the source to destination and not the other way around, which by the way, may follow a different path. Traceroute also uses the services of User Datagram Protocol (UDP), in specific implementations, as the transport layer for a specific reason that we’ll go into further on.
So first, lets start with an overview of ICMP protocol and then we can get into the details of how ping and traceroute use this protocol to perform their tasks.

Internet Control Message Protocol (ICMP)

ICMP is a Network layer protocol that belongs to the group of control protocols similar to ARP and RARP. ICMP protocol has been designed with the unreliable characteristics of the IP protocol in mind. Due to this unreliability and connectionless behavior of IP, there was no way of informing the originator host that something went wrong during data transmission. ICMP has been designed to provide this function.
ICMP messages report back to the sender when something unexpected occurs, giving the person a clue of what might have gone wrong. I want to remind you that ICMP does not solve the reliability issues of IP; that is up to the upper layer (the Transport layer) to perform. ICMP messages are encapsulated in IP packets as seen below:


Image 1: ICMP Encapsulation

ICMP messages use the following format:

Image 2: ICMP Message Format

The most important ICMP message types are listed below:

Image 3: Important ICMP Message Types

Troubleshooting with PING

Lets take a look at the behavior of the ping command with the help of Ethereal application. First, to launch the ping command the simplest way is to open a command prompt window and type in PING [ip address of the host to reach], or if DNS service is running type in PING [URL of the destination host]. Sometimes, the extended ping command, which issues continuous echo request messages, is very helpful. The format of this command is PING –t [IP address of the host]. The ping command operates the same way in Windows, Unix, Cisco machines and in every other networking device. The principle is the same, even though variations on the extended functions of the command may exist.
In the next image you can see a ping command towards the URL of Trainsignal.com. DNS query is performed first to translate the URL to an IP address, and then four echo request message types are transmitted. Transmit packets are time stamped. When the remote host receives these echo requests, inside the echo reply messages it includes the timestamp enclosed in the echo request. Upon receiving the reply message and performing simple calculations, the round trip delay time is revealed and noted:


Image 4: Executing the Ping Command

Looking at the Ethereal trace, you can see that the echo request ICMP message has the type field value set to 8. This is the standard value for echo request messages. Also notice that the TTL field has the value of 128 (Common value for Windows platforms). This value indicates the number of hops the packet is allowed to traverse before getting dropped. This value, due to scattering of networks, should have a great value — anything above 64. Cisco machines use a TTL value of 256.


Image 5: Echo Request Message Encapsulation

Below you can see one of the echo reply messages as captured by Ethereal tool. It can be seen that the ICMP echo reply message has a type value 0 (zero):


Image 6: Echo Reply Message Encapsulation

Troubleshooting with TRACEROUTE

The traceroute command operates similarly to ping. On Cisco routers and Unix platforms the layout of the command is: TRACEROUTE [destination IP address] or TRACEROUTE [URL of the destination host]. On Windows machines the function of traceroute comes with the command TRACERT (short for trace route), which operates in a slightly different manner than in Cisco and Unix platforms (details on this are below). Traceroute uses a clever way to capture the footprint of a packet’s journey. We will use an imaginary example (see the next image) to help us investigate how traceroute achieves its purpose:

• RouterA prepares an ICMP echo request message, encapsulates it in an IP packet having Source address=172.16.1.1, Destination address=192.168.7.2 with Time-To-Live (TTL) value=1, Destination UDP port= anything not used (usually greater than 30000) and forwards it.
• RouterB, upon receiving this packet, decrements one unit from TTL value, hence TTL becomes 0, which means that it has to drop this packet. It replies back to the sender with an ICMP Time exceeded message, including its source address in the SA field of the IP header (SA=172.16.1.2).
• RouterA receives the response and prints out on the screen the first hop (IP address=172.16.1.2).
• Afterwars, RouterA sends the same echo request message with TTL value=2.
• RouterB decrements it by one and forwards it to RouterC which decrements by one again (TTL=0), forcing it to return an ICMP time exceeded message with SA=192.168.1.2.
• RouterA now prints out the second hop on screen (IP address=192.168.1.2).
• Finally RouterA sends an ICMP echo request with TTL value=3 which is terminated on RouterD. The latter passes the packet to the transport layer where the wrong UDP port number causes RouterD to issue an ICMP Port Unreachable message.
• RouterA upon receiving this message from RouterD knows that it has reached the final hop which prints out on screen and stops sending any more messages.

Image 7: Traceroute Example

A Real Example of Traceroute

Now that we understand how traceroute works, lets see how it behaves in a real situation. Using command prompt under Windows host, TRACERT to www.trainsignal.com is issued. The result is shown in the image below:

Image 8: Printout of TRACERT Command

By looking at the image above, you can see that each ICMP echo request message is repeated three times before the sender increments the TTL value and resend the request message. The three round trip delay times for all three messages are included at the beginning of each hop. A couple of request timed out messages come from routers that are configured not to respond to ICMP echo request messages.
The image below shows the content of the echo reply message received from trainsignal.com (message number 20 as shown on figure 8). Although we would expect an ICMP message with type value=3 (Port Unreachable), a TTL exceeded message (type=11) is received. This difference comes from the fact that in Windows platforms UDP ports are not used.


Image 9: Time Exceeded Message from Destination Host

The Windows platforms, upon receiving an echo reply message from the final destination, issue three more echo request messages to that host; hence the last noted echo reply message on in the iamge above.

What Can Ping and Traceroute Do for You?

Ping and traceroute commands can be very helpful — if used appropriately. Use the PING command when the existence of a host is what interests you. Use TRACEROUTE in Cinsco and Unix or TRACERT in Windows to get an idea of what route your packets take to reach their destination.
Do NOT rely on traceroute to give you the exact route path of your packets. Keep in mind that ICMP operates on top of IP. Also, remember that IP is unreliable, meaning that not every packet towards the same destination always takes the same path. Moreover, received messages may follow different paths each time, so make sure to treat traceroute results cautiously.
Both ping and traceroute are extremely important in exposing hidden network malfunctions besides basic troubleshooting. Talking from personal experience, extended ping utility has once exposed a hardware glitch which had the symptom of dropping packets randomly during peak hour traffic. Therefore, don’t forget to take advantage of ping’s special capabilities.