How to trace network route?

Traceroute is a simple yet clever command-line tool for tracing the path an IP packet takes across one or many networks. It was originally developed for UNIX-based platforms, but is now included in most operating systems, with the Windows implementation being known as “tracert”. The output of these commands is also frequently referred to as a traceroute. Ask for help with poor streaming video performance, for example, and your ISP might ask you for a traceroute.

Traceroute is used primarily for diagnostic purposes, but it can be a fun tool to learn about networking or simply to satisfy some nerdy curiosity. System administrators and network engineers can use traceroute to see how traffic flows within an organization, and identify any irregular or sub-optimal paths. Externally, traceroute can display the path of a packet as it traverses many different networks, and in some cases even reveal the different cities or geographic regions traffic flows through. Attackers could potentially use traceroute to map out a target’s network, which is why the types of packets used by traceroute are frequently blocked or filtered at the perimeter of corporate networks.

Most implementations of traceroute also display the time it takes to reach each “hop” between the source and destination. This is extremely useful when hunting down the root cause of dropped traffic or performance issues. During one episode of sporadic connectivity from my home office, I was able to see from traceroute results that my ISP was dropping many packets and inconsistently routing others through strange, geographically distant paths. Hours later, the ISP announced a regional fiber optic cable had been cut by a contractor.

Traceroute is actually a bit of a hack, in that it leverages a field in Internet Protocol (IP) packet headers that was never really intended for path or route tracing. The IP standard mandates a Time-to-Live (TTL) value for each IP packet, which acts as a kind of self-destruct mechanism to keep undeliverable packets from endlessly circulating around the Internet. Each router in a path is expected to decrement the TTL value by one before sending it further down the line. Once the TTL hits zero, the routing process comes to a screeching halt, and the last router to have processed the packet will send back a “Time to live exceeded” message.

Exceeding a TTL value isn’t desirable for normal data packets, which is why a typical packet will have a value ranging from 64 all the way to 255. But what would otherwise be a frustrating error message is actually a key part of how traceroute works. By manipulating the TTL field, traceroute and similar programs can trigger TTL exceeded messages from each hop along a given path. Here’s how it works:

By default, traceroute will send three packets to each hop in the path. The exact type of packet varies between implementations, and can also be changed with different flags, but this same basic methodology is used in all cases.

Traceroute is available on a wide variety of platforms, from consumer operating systems to large enterprise routers. There’s not much variation in how traceroute works across these different platforms, but the syntax of the command can be a little different. Here’s how to run traceroute from several popular platforms:

Microsoft’s implementation of the traceroute tool is slightly different from what you’ll find on Mac/Linux/Unix platforms. The most glaring difference is in the command itself: On Windows PCs, you’ll use the “tracert” command instead of typing the whole word. Here’s a step-by-step guide:

The example above shows how to run a traceroute on Windows 10, but the process should be no different for other versions of Windows.

Many flavors of Linux come with traceroute pre-installed, although some distributions opt for similar tools like mtr and tracepath. In any case, you can generally obtain the “classic” traceroute using the yum (yum install traceroute) or APT (apt-get install traceroute) package managers. From there, the steps aren’t too dissimilar from Windows:

Here’s an example of a traceroute run from Kali Linux:

Running a traceroute on Mac is virtually the same as running it on a Linux platform:

You might notice that some of the defaults are a little different; a max of 64 hops, for example, instead of 30. You can easily change these settings using command line flags. Just check the official traceroute documentation using the “man traceroute” command.

Now that we know a little more about how traceroute works, it’s time to start using it! If you’ve never used traceroute before, things might look a little intimidating at first. Once you learn how to read a traceroute output, though, you can quickly make sense of the results.

Each line of the traceroute output represents one “hop” in the path to a given destination. These hops might be listed as either an IP address or a hostname; traceroute will attempt to resolve the IP address of each hop back to a hostname and display that, if possible. The list begins with the closest router to your computer and ends at either the destination or the last point the traceroute made it to before hitting a maximum number of hops. To the right of each entry is a series of times measured in milliseconds (ms). This is the Round-Trip Time or the amount of time it took for the traceroute packets to reach that hop and receive a reply.

You might notice one or more lines of your traceroute output is listed only with an asterisk (*). This means that the program did not receive any response from the router at that hop. Some organizations choose to block or discard the type of packets that traceroute relies on, either by blocking them with a firewall or configuring routers to discard the packets instead of replying. Traceroute traffic is also considered low-priority; a busy router may process standard data packets rather than reply to your traceroute request.

For a traceroute taking place over the Internet, it’s likely you’ll see a path that traverses multiple networks, service providers, and geographic regions. Let’s look at a traceroute that runs from the East Coast of the United States all the way to Nepal in South Asia:

There’s a lot of interesting information that we can gather from this traceroute. Our first hop - 10.28.0.1 - doesn’t tell us too much because it’s just the local gateway for our subnet. But we can start to really dig into the path our packets take on their round-the-world trip with the second result: “vlan156.as06.mia1.us.m247.com”.

When dealing with hostnames it’s sometimes more helpful to start from the right and work your way left. Using that tactic, we can google “m247” to discover that it is a United Kingdom-based service provider with locations around the world. We can also deduce that this particular router is located in the US, and specifically in the Miami, Florida area, by looking at the two components of the hostname immediately to the left of m247.com. Note the three-letter abbreviation “mia”. Although there is no requirement to do so, many companies label the geographic location of routers using the three-letter airport codes from the International Air Transport Association (IATA). The final two portions of the hostname detail the router’s place within the service provider’s network, with the “as06” likely an abbreviation for the autonomous system number and “vlan156” referring to the VLAN that our packets found themselves traveling through.

You might notice that the third line actually lists two different IP addresses. Remember that by default, the traceroute will send three packets to each hop. There’s no guarantee that each packet will be routed in exactly the same way. In this example, the second and third packets ended up taking a slightly different path. This could be due to load balancing, temporary network congestion, or a number of other factors.

By the fourth line, we can see that our packet is still in Miami, but the end of the hostname shows that it’s now moving through the network of Cogent Communications instead of m247.  Cogent is a large ISP with a global network. Lines 4 through 11 illustrate the path through various cities in the US - remember those IATA codes - before ending up at a Cogent node in Los Angeles.

Something interesting happens between line 12 and 13. We can see that the round trip times begin to greatly increase at this point. There are no hostnames, but a variety of sites and “whois” databases can help gather information about IP addresses in their absence. Using this technique, I was able to discover that all three of the IP addresses on line 13 (remember that routing decision are made on a per-packet basis) are assigned to Bharti Airtel, a telecom service provider in India. That means that in-between lines 12 and 13, our packets are traveling from the west coast of the United States to India, likely through one of the many undersea cables that now criss-cross the Pacific Ocean.

By line 15, we can see that our traceroute packets are hitting the network of Nepal Telecom based on the “ntc.net.np” hostname, and finally at 24 to the server hosting the official website for the Nepalese government. It’s worth pointing out that while the round-trip times are higher than they would be for a closer target, our data is still traveling halfway around the world in less than half a second. Hopefully, our little trip helped you understand how to read a traceroute!

A: Ping and traceroute are both network diagnostic tools, but traceroute is a little more complex. Ping will test connectivity between two hosts but gives no information on the path between those two hosts. The traceroute tool, on the other hand, displays all of the intermediate hops between source and destination. This can be useful during intermittent connectivity episodes, for example, if only 50% of the pings between two points are successful.

A: Tracert and traceroute perform virtually identical functions, but the underlying code between the two tools is different. Tracert was created by Microsoft for Windows operating systems, while the earlier traceroute is for Unix-based systems. There are slight differences in the default parameters between the two tools, such as the type of packets used.

A: The original traceroute tool, which dates all the way back to 1987, isn’t always able to produce accurate results. Load Balancing, Network Address Translation (NAT), firewalls, and other factors can result in inaccurate or incomplete results. A number of similar tools, such as mtr, and Paris Traceroute, implement the same basic idea as traceroute but attempt to address the classic tool’s shortcomings through various means. Some tools also sought to build on the output and streamline configuration vs the original.

A: You’re in luck! The traceroute6 and tracert6 commands provide the same functionality as traceroute but for IPv6 networks. Many of the similar tools (see above) also have support for IPv6.

Note: To be effective, the traceroute MUST be run during a time when you are experiencing the problem, from a computer that is experiencing the problem. A trace when you are able to connect, or one from another computer, is not helpful. Therefore, you should try to connect to your site again just before you run it. If the problem is no longer occurring, you will have to wait until the next time the problem occurs (if there is a next time) before running your traceroute.

This article includes instructions for Windows, Mac and Linux. There is also brief information on how to read the traceroute results.

If you have difficulty copying the traceroute information, or if it runs off the screen, you can type this command instead:tracert hostname > C:\trace1.txtThis writes the command results to a text file named trace1.txt in the root of your C:\ drive. You can then open this file and paste the contents into your email message to Support.

Hostname is the name of the server connection you are testing. See the section Determining hostname  below for help with the hostname.

Determining hostname:

Note: the hostname should be replaced with whatever site is not working for you.

Please also note that even if the problem seems to occur closer to Intermedia's end, it may actually be a problem at your ISP. This is why it is imperative that we see the entire traceroute ourselves.

Number: This column is simply the number of the hop.Round Trip Time (RTT): This value also called latency and displays the time (in milliseconds) which packet takes to get to a hop and back. Asterisk (*) under RTT means that the packet did not return. This does not necessarily mean packet loss as many Internet routers may intentionally discard ping commands.

Name: The fully qualified domain name (FQDN) of the system. Many times the FQDN may provide an indication of where the hop is physically located. Sometimes the FQDN can't be found and only IP address displayed. It is a common thing and also does not mean there is trouble with connectivity.IP Address: The IP address associated with the Name.

Request timed out means that the host you're pinging might be: down or unreachable behind a firewall that drops your ICMP echo request packets. Also. the command may be disabled for that network by the sysadmin.

If "Request timed out" appearing at the beginning (usually on hop 2) it can be ignored as it's a common hop.

You can do this by typing “command” from the Start menu, or by pressing the Windows Key+R and typing in “cmd” From the command-line prompt, type “tracert” followed by the hostname or IP address you'd like to trace to. To see the path to varonis.com, for example, we'd type “tracert varonis.com”.

• Press Windows key + R to open the Run window.
• Enter cmd and press Enter to open a Command Prompt.
• Enter tracert, a space, then the IP address or web address for the destination site (for example: tracert www.lexis.com).
• Press Enter.