TraceRoute started life as a small utility developed by Van Jacobson in 1988. Originally developed for various flavours of Unix, and distributed as compilable C source code, there are now versions of the utility for VMS, Mac OS, Mac OS X, OS/2 and the various flavours of Windows.

Windows 95/98/Me and Windows NT/2000/XP all include a TraceRoute application, called tracert, as part of each OS's collection of TCP/IP utilities. In each case the application is available from a DOS prompt.

There are also Windows applications with TraceRoute functionality for folks uncomfortable with the DOS prompt, including Holger Lembke's 3d Traceroute and Visual Trace Route from IT Lights Software.

OS/2 includes a TraceRoute utility as part of the OS and like its Windows counterparts, the OS/2 TraceRoute tool is available from the OS/2 command line.

I understand, but have not specifically confirmed, Windows 3.11 users are catered for by the presence of a DOS-based TraceRoute utility with almost every WinSock-based TCP/IP stack.

Mac OS X, Linux and other Unix and Unix-like operating systems (eg *BSD, Solaris and Irix) all come with TraceRoute available at any shell prompt.

There is an X-Windows implementation of TraceRoute available -- Xtraceroute -- but it hasn't been updated since 1999 and has only been tested on a few Unix implementations (old versions of Solaris and Irix and a single Linux release).

On pre-OS X versions of the Mac OS, Brian Christianson's freeware WhatRoute provides Ping, Whois, Query, Monitor and Finger services as well as acting as a TraceRoute utilitiy. Alternatively, version 6.3 of Interarchy (the last version which runs on Mac OS 8.5 through 9.1) from Stairways Software includes a TraceRoute function in that application's Watch menu.

Both WhatRoute and Interarchy are also available in OS X-only versions and these versions provide TraceRoute functionality for Mac OS X-using folks uncomfortable with opening a shell prompt.

Usage

To create a traceroute log under Unix, Linux or Mac OS X simply type 'traceroute [destination]' (where '[destination]' is the IP number or domain name of the machine you wish to trace to) at any shell prompt and hit Enter or Return.

The process is similar under the CLI-based/DOS-based traceroute applications available under Windows or OS/2: fire up a DOS prompt and type 'tracert [destination]' (without the quotes and with the appropriate numbers or words in place of '[destination]') and hit Return.

WhatRoute and Interarchy for Mac OS both provide a text box in which you simply type the IP number or domain name you are heading for. Likewise with 3d Traceroute and Visual Trace Route under Windows. In all these cases, hit the Return key after you are done typing. (In WhatRoute also check the pop-up menu (which allows you to choose which service you want to access) is set to TraceRoute.)

Once TraceRoute has a machine name or IP number in hand it goes out and does its simple but rather nifty thing.

TraceRoute sends out very small (typically 40 byte) UDP datagrams with even shorter Time To Live (TTL) counters in the packet header. The TTL value in a packet header is the number of routers the packet is set to travel through before a router is allowed to throw it away (presuming it doesn't reach its stated destination beforehand of course).

Examples are always easier so, presume you are setting out to create a traceroute log for the router path between your machine and the ZDU home page at welcome.zdu.com. TraceRoute sends out a UDP datagram with its destination set to welcome.zdu.com and its TTL set to one.

The router at your ISP receives the packet and reduces the TTL value by 1. Since this reduces the TTL to 0, the router promptly discards the packet. At the same time it also creates an Internet Control Message Protocol (ICMP) error message (TIME_XCEEDED_INTRANSIT, to be precise) and sends this error to the sender address on the packet (ie, your machine).

TraceRoute receives this error message and does several clever things with it. First it pulls the IP number of the issuing router out of the ICMP, then it does a DNS reverse look-up on that router. Finally, it logs the time it took for the packet to make what is, in effect, the round trip.

TraceRoute sends out three such packets for each value of TTL specified. Almost invariably TTL=30 is the maximum number used, although it is possible to change that if you wish.

TraceRoute continues to send out its little three packet bursts (each burst with a TTL one higher than the previous) until it reaches the router marked as the destination in the IP packet header. TraceRoute's last trick is played here. The destination router un-wraps the packet to see what to do with it only to discover that the little datagram is aimed at port 33434, a ludicrously high port number with no known use. (By way of example, HTTP services -- ie web sites -- are commonly served up on port 80.) This also generates an ICMP error message, but not a TIME_XCEEDED_INTRANSIT error. Instead the final routers sends an invalid port error message, which traceroute interprets as the end of the line.

The end result is the TraceRoute log: a table of IP numbers, domain names (if they are returned by the reverse DNS look-up) and times. There are three times per router (ie per IP number/domain name) and said times are normally given in milliseconds.

Logs

To put this in concrete, consider the traceroute log I generated below from an HP-UX machine in Victoria, Australia to welcome.zdu.com.

The HP-UX box gets its TTL=1 packet back from its uplink router (cbl-gw.cpl.com.au) in about 4.27ms (averaging the three times logged). The round trip time for the TTL=2 packets varies rather wildly, with two packets taking about 85ms to make the trip and one taking only 28ms.

It's important to note that these times are not cumulative. The numbers returned are the round trip times taken for the packet to go from the originating machine all the way to the machine which kills the packet and returns the error message and back again.

Things go along pretty smoothly until we hit router 5, the first router outside Australia. Suddenly the round-trip is taking about six times as long as the trip to router 4. Moreover, I'm losing packets with monotonous regularity (the '*' entries in the table are packets which didn't make it back at all). Solid evidence that the Telstra to MCI link across the Pacific ocean is in dire need of an upgrade (as if more evidence was needed, but that's a whole political story for elsewhere).

More generally this points to the usefulness of traceroute logs for rooting out bottlenecks between you and your target. Any sudden increase in the round-trip time when hopping from one router to the next is a strong indicator of the latter router being a bottleneck. Lots of lost packets after a particular router are another indicator of problems, although lost packets are probably best investigated with Ping.

In the case above it's the Telstra-to-MCI gateway, which is why I personally use an ISP which doesn't use Telstra's US link at all (they have their own gateways to San Diego, London and several South-East Asian countries).

Connection Quality

Finally, traceroute can help get a sense of the quality of your personal Internet connection.

Run TraceRoute to the hostname of your ISP. So, traceroute to earthlink.com if you are an EarthLink subscriber; aol.com if you use AOL; telstra.com if you're stuck with Telstra; internode.com if you're with Internode and so on. (NB, you don't have to TraceRoute to your ISP's main host, but it does makes for a short trip, which gets results back to you quicker.)

Take note of the round-trip times for the second machine on the resultant list of computers between you and your ISP's main host. This second machine will likely be the router directing traffic between you and the outside world. (Especially if you have broadband, the first machine is almost certainly your own router, routing traffic from your home LAN or computer up the link to your ISP.)

If you have dial-up connectivity, a 300ms or so round-trip to this router is a sign of decent connectivity. Anything much over this and there is something slowing things down.

If you have broadband connectivity (eg a DSL, ADSL or cable connection), a round-trip to this 2nd machine shouldn't take more than 50ms or so.

It's important to note a single slow round-trip isn't automatically a sign there is something wrong. Even having all three packets take 'too long' to get back isn't a reason to call tech support. If, however, you get consistent slow returns over time, it's worth looking for a cause (remembering, of course, the problem may well be at your end: don't assume slow returns from your ISP's main router are your ISP's problem).