Using Tracert
Tracert is a Windows based command-line tool that you can use to trace the path that an Internet Protocol (IP) packet takes to its destination from a source. Tracert will determine the path taken to a destination. It does this by sending Internet Control Message Protocol (ICMP) Echo Request messages to the destination. When sending traffic to the destination, it will incrementally increase the Time to Live (TTL) field values to aid in finding the path taken to that destination address. The path is outlined from this process.
Using the following illustration, let’s take a look at how tracert would function in a production network.
As you saw in the last illustration, we will be sending traffic from a test workstation from Site B to a server at another site (Site A). The packets will traverse the wide area network (WAN) that separates the two sites over a T1 with a backup link via Integrated Services Digital Network (ISDN). To use the tracert utility, you simply need to know what your destination IP address is and how to use the tracert utility correctly as well as what to look for within the results.
Tracert works by manipulating the Time to Live (TTL). By increasing the TTL and then each router decrementing as it sends it along to the next router, you will have a hop count from your source to your destination. A router hop would be a packet sent from one router to another router – that’s a hop. When the TTL on the packet reaches zero (0), the router sends an ICMP “Time Exceeded” message back to the source computer. You can see an example of our sample network here in the next illustration; with a source and destination IP address… we will be using the workstation on Site B and a server at Site A for our test.
From this illustration you can see that the source IP will be 10.1.2.4 and the destination (for this example) will be 10.1.1.6. The normal route the packets should take would be from Site B to Site A over the higher capacity link, the T1 (1.544 Mbps). The ISDN link is 128 Kbps and is used as a backup if the primary link fails. Tracert once fired up and used will be able to show you that the packets sent will start from Site B, the PC at 10.1.2.4 and then traverse the T1 to 10.1.1.1. That router will know how to send the packets to its local LAN (10.1.1.0) and ultimately to 10.1.1.6.
As the packets are sent, tracert will use the first interface on the router that it sees to report back your router hops, so let’s take a look at our complete path before we send the test packets.
The path displayed is the list of routers in the path between a source host and a destination. One thing that is very important to remember is that near-side interfaces are used when reporting. The near-side interface is the interface of the router that is closest to the sending host in the path. In this example, you can see that the path is the T1 from Site B to Site A. Lets see now why it’s important to know this.
The way tracert works is, once launched and utilized, tracert will report (print out) a list in the order in which it heard back from each host that it passed on its way to its intended destination. This is good because you can learn much from this path. If you are getting ‘near side’ interfaces, then you would see a new set of IP addresses in the next illustration (192.168.10.1 and 192.168.11.1) 10.1 is used for the ISDN link and 11.1 is used for the T1 link. Why is this important?
When you get results back from tracert, this could be confusing to some who are not adept with working with this tool, you will see WAN addressing instead of Site A’s default gateway router which is 10.1.1.1. It’s the same router, but it’s a different interface. This is imperative for you to know when testing with tracert, because if you confuse this, you will not know what you are reading.
For example, the path as you see in the last illustration is from 10.1.2.4 and then to 10.1.2.1 (the LAN’s default gateway), and then it will traverse the WAN to 10.1.1.1. The only problem here is that you will not see that address come up. Since the T1 has an interface on Site A’s router (11.1), and so does the ISDN link (10.1), these are the two IP address that are most important in the results of tracert – this is because in this example, the T1 may be down and now the path is over the ISDN link. This is working ‘as advertised’, but what happens when you bring the T1 back online – aside from feeling your network crawl from moving from a T1 at 1.544 Mbps to a 128 Kbps – is that you should not be using the ISDN link anymore. This is what we are going to test…
Now, to use tracert, you simply need to open a command prompt. To do this, go to
Start => Run => CMD => tracert
(note – you must type tracert, as you can see traceroute only works on UNIX/Linux and other systems such as Cisco, etc)
In the following example of the tracert command and its output, the packet travels through two routers (as seen in the last illustration) to get to host 10.1.1.6. In this example, the default gateway from Site B is 10.1.2.1 and the IP address of the router on the WAN via the T1 and ISDN links (respectively) are 192.168.11.1 and 192.168.10.1.
Lets first see what it should look like using the T1.
C:\>tracert 10.1.1.6
Tracing route to 10.1.1.6 over a maximum of 30 hops
—————————————————
1 2 ms 3 ms 2 ms 10.1.2.1
2 25 ms 83 ms 88 ms 192.168.11.1
3 25 ms 79 ms 93 ms 10.1.1.6Trace complete.
Now, if the T1 was down and you were using the ISDN link, you can see that there is a different ‘path’ and you can also see that it takes ‘longer’ to get there.
C:\>tracert 10.1.1.6
Tracing route to 10.1.1.6 over a maximum of 30 hops
—————————————————
1 2 ms 3 ms 2 ms 10.1.2.1
2 75 ms 83 ms 88 ms 192.168.10.1
3 75 ms 79 ms 93 ms 10.1.1.6Trace complete.
As you can see now, using tracert will help you to determine the network path as it is laid out through the network – AND – most importantly, how data traverses that path.
There may be times where the output you get isn’t so clear to you. For example, what if you get an asterisk? As just mentioned in the last section, an asterisk can be a false positive, because the ICMP packet may be traveling through, but something is stopping the report from coming back, most likely a firewall rule or access control list.
You can use tracert to find out where a packet stopped on the network. In the following example, the default gateway has found that there is no valid path for any host. This would mean that both links are down – the T1 and the ISDN and there is no destination available.
C:\>tracert 10.1.1.6
Tracing route to 22.110.0.1 over a maximum of 30 hops
—————————————————–
1 10.1.2.1 reports: Destination net unreachable.Trace complete.
From this example, you can see that when you sent the tracert test to 10.1.1.6, the LAN default gateway reported that it could not find a path – to see this in graphical format may help you to understand it better.
