Most implementations of “trace” will send several probe packets at each TTL and display the round-trip time for each. For example, Cisco IOS and MS Windows do three probes per hop by default. The display then resembles a table with a row for each hop, and the columns are hop number, the round-trip times, and the router address at that hop. If DNS or host table info is available, the trace program can also supply the hostname of the device at each hop. Doing our previous trace from H1 to H2 with the default settings might look something like this:
H1#trace ip 188.8.131.52
Type escape sequence to abort.
Tracing the route to 184.108.40.206
1 R1 (220.127.116.11) 1 msec 2 msec 1 msec
2 R2 (18.104.22.168) 2 msec 2 msec 2 msec
3 R3 (22.214.171.124) 4 msec 3 msec 3 msec
4 H2 (126.96.36.199) 5 msec 4 msec 5 msec
The Cisco “traceroute” program offers many other options as well, but you have to run it from privileged mode to use them. These include the ability to specify:
- DNS resolution of IP addresses
- Source address or interface
- Number of probe packets at each hop
- UDP port number
- Reply timeout
- Range of TTLs
Now, here’s a “tracert” from a Microsoft Windows 7 host, using the default options:
Tracing route to 188.8.131.52 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 184.108.40.206
2 1 ms 1 ms 1 ms 220.127.116.11
3 2 ms 1 ms 1 ms 18.104.22.168
4 2 ms 1 ms 1 ms 22.214.171.124
As you can see, aside from the ordering of the columns, the Microsoft “tracert” displays pretty much the same information as the Cisco “traceroute”. What’s not apparent from the display is that there is one *BIG* difference between the implementations, which is that the Cisco “traceroute” program uses UDP probe packets, while Microsoft’s “tracert” uses ICMP echo requests (“pings”). This could yield dramatically different results when tracing through firewalls or routers with access control lists.
For this reason, there are also utilities that support tracing using TCP probe packets, such as “tcptraceroute”. With this, you could do your traces using TCP port 80, or some other port that matches that used by an allowed application. By the way, Unix implementations of “traceroute” also use UDP probe packets. There are other related utilities, such as Microsoft’s “pathping” and the open-source “MTR”, which trace to the destination and then ping each hop repeatedly in an effort to gather sufficient timing information to calculate more reliable timing statistics than does “tracert”.
One more thing … on a Cisco, of course, you can shortcut “traceroute” to “trace” or even “tr”. Annoyingly, typing “tr”, “trace” or “traceroute” on a Microsoft machine will give you an error and likewise for typing “tracert” on a Cisco. How aggravating! On the Cisco, you could set up an alias for “tracert” like this:
Router(config)#alias exec tracert traceroute
Now you could use “tracert” on the Cisco, as well. Maybe a better plan is to keep using “tr” (or whatever) on the Cisco and instead create the alias on the Windows machine. For example, you could create a file containing the lines:
Save the file with the name “trace.bat” to the C:\Windows\System32 directory (or save it to another directory, and add that directory to the system’s PATH statement). Now you can use “trace” on the Windows machine (you could also create batch files with the same contents named “tr.bat” or “traceroute.bat”, if you like).
Okay, that’s it for now. Next time, we’ll talk about directionality and load sharing when it comes to trace utilities.