Traceroute Tool Provides Powerful Insight
By Patrick Hunter
For even the less experienced engineer or technician, there is a tool that can be employed for learning about a network, or even many networks, that is often undervalued. It’s actually very powerful in what it can teach us and requires very little in terms of high priced technology. I am of course referring to the “Traceroute” utility that is available on nearly every computer and networking device sold today. It is a great way to understand the IP path from one source to different destinations with relative ease. But, it is also often a misunderstood tool. Learning how it works and why it works in the way it does provides engineers and technicians with even more powerful information, right at their fingertips.
First, let’s start our chat by discussing Internet Messaging Control Protocol, or ICMP. ICMP is a very useful protocol for sending messages from one network adapter on a computer or other device to any other computer or network device. But, it is very important to note that it is not a protocol used to send and receive application information that a typical application would use. It is really intended to help gather information about the state of interfaces, networks, or devices or the path across many networks. It has a number of useful features that are examined briefly here.
You may be aware that ICMP is the protocol that is used in the commonly known “ping” utility. When a computer or network device is instructed by a user, like you or me, to “ping” an IP address, a special IP packet is constructed to perform this task. For grins, you might try to ping the IP address 8.8.8.8 from your home computer or laptop. If all is in working order, you should see information showing a series of responses to a series of “ping” messages generated by your computer, which include a round trip delay time in milliseconds. While this task is very familiar to nearly all our readers, let’s dig in a little deeper to see what the mechanics are under the hood.
When the command “ping 8.8.8.8” is typed into the console of a computer or network device, the device constructs an IP packet with a special payload, the ICMP header. Recall our prior discussions in earlier “IP Address” columns regarding the process of “encapsulation” in network communications; the idea that the ICMP header is encapsulated should ring familiar to you. (If not, feel free to peruse the back issues on BroadbandLibrary.com). The ICMP header contains various bits of data, but for our discussion, the most important pieces are the ICMP “Type” field, which contains a value indicating what the intended message is for the ICMP information, and the “Time to Live” (TTL) field. If the Type = 8, then the message is called an ICMP “Echo Request.” If Type = 0, then it is an “Echo Reply.” So, as you might imagine, when you tell your computer to “ping 8.8.8.8”, an ICMP echo request is constructed, packaged up into an IP packet with your computer’s IP address as the source address, and 8.8.8.8 as the destination address.
What’s really cool here, though, is what can happen as this packet makes its way toward the destination. Lots of neat things can be relayed back to your computer via the ICMP control messages. If, for some reason, the packet makes it part of the way there, but something goes wrong, the router or gateway that is handling the ICMP echo request you sent will reply with an ICMP type 3 message like “destination unreachable” or “host unreachable.” Now, this is pretty slick because you can get a sense of “who” is telling you this information. That’s because the IP packet used to reply back to your original echo request will have the IP address of the responding router or gateway as the source address, and of course your IP address as the destination! If everything works correctly, then as we described earlier, the ICMP echo reply will successfully make its way back to your computer, with the original source and destination address switched, since as the responder to your echo request, the remote device will know to send the reply to the return address for your original echo request.
But, that’s only a piece of the puzzle here. Just because you get a successful echo reply or perhaps a destination unreachable message, that doesn’t tell you much about how far your echo request had to travel to have a reply find its way back to you. If you want to manage IP networks, you certainly care very much about the path those packets take to get to and from the devices. How can we learn more about the networks here? I gave you a hint already….
The answer is the traceroute utility. It turns out that traceroute uses ICMP echo requests and replies in a very ingenious manner to tell us great information about the path from a source to a destination. If looking under the hood is my analogy for talking about how the ping utility works, then talking about the mechanics of traceroute is basically like opening the engine block and seeing the way the pistons and crankshaft move and the spark plugs fire. This is the fun stuff.
So, rather than just getting return information that tells us if an IP address is responding and how long it took for the round trip to get a successful response, we want to know the IP address of every device that our echo request passes through on its way to the destination. This is where it takes a very curious mind to reason through solving this problem. Before I learned how traceroute accomplishes this, I did try to imagine how I would make it work. The challenge is that we know our own IP address, and we know the IP address of our remote destination, but most likely we have no idea of the IP addresses of all the different network devices in between! So, we can’t send an echo request to all those intermediate network “hops” so that they can send an echo reply giving us that information. But, there is a way to use ICMP to get the information we want. I also gave you a hint earlier in the conversation about ICMP….
The secret is in the TTL field in the IP packet that encapsulates our ICMP echo request. According to Internet Protocol rules, as any IP packet is received by a network device, like a router or gateway, the TTL field should be decremented by 1. What value TTL starts at is dependent upon several factors, but suffice it to say, it’s certainly not 0 or 1. It is usually set at 64. So, by virtue of the fact that each network device must decrement TTL by 1, the value is essentially what we like to call a “hop limit.” Any network device that receives a packet with a TTL of 1, decreases TTL by 1, which means that TTL is now 0. In this case, the router or gateway drops the packet and constructs an ICMP type 11 “time exceeded” message. What is great about that is the source IP address of the time exceed message is in fact the IP address of that intermediate hop or router! Therein lies the genius of the traceroute utility.
When we instruct our computer to traceroute to an IP address like 8.8.8.8, the computer just sends a series of pings, or echo requests, not some special “traceroute” messages. The very first echo request is intentionally built with a TTL of 1 in the IP header. When it arrives at the first network device, our gateway for our network, the TTL is decremented to 0, the router discards that echo request, and sends back a time exceeded message to us. Now we know the IP address of the first hop on the way to our final destination! Then, our computer constructs a second echo request with a TTL of 2. That packet successfully routes through the first hop, with the TTL reduced to 1, then arrives at the second hop, which reduces it to 0, discards the echo request, and sends back a time exceeded message with its IP address as the source. The process repeats until either our final destination responds, or something prevents the echo requests from getting to the destination. Viola! Mission accomplished. As you can see in the accompanying screen shots, we have a nice list of all the IP addresses for each hop from our source to the remote destination.
Something as simple as the network diagnostic tools like ping and traceroute can have powerful implications about our ability to understand and manage our networks. More importantly, an engineer’s or technician’s ability to understand precisely how these tools work at a deep level is very important. In fact, one of my favorite interview questions is “tell me how the traceroute utility works, at a nuts and bolts level – take me under the hood.” You can bet that the candidates who cannot answer that question accurately are at a serious disadvantage in my eyes.
Patrick Hunter — “Hunter”
Director, IT Enterprise Network and Telecom,
Charter Communications
hunter.hunter@charter.com
Hunter has been employed with Charter since 2000 and has held numerous positions, from Installer, System Technician, Technical Operations management, Sales Engineer, and Network Engineer. His responsibilities include providing IP connectivity to all users in Charter’s approximately 4,000 facilities, including executive and regional offices, technical centers, call centers, stores, headends, hubsites, and data centers. Mr. Hunter has served on the SCTE Gateway Chapter Board of Directors since 2005. He spends his spare time mentoring, teaching, and speaking on IP and Ethernet networks as well as careers in the network field.
Credit: Shutterstock
