Definition of Traceroute
Traceroute is a network diagnostic tool originally written by Van Jacobson to determine whether routing problems exist on the network. Traceroute can be used to determine which path IP packets are taking to get from your computer to the remote computer. Traceroute shouldn't be used on a network without routers. It is not really useful unless there are at least two routers in the network. The Internet has thousands (dare we say millions?) of routers so traceroute is perfect for the Internet. Traceroute was designed to reveal when network failures such as routing loops and black holes occur and shows roughly where those failures exist.
How Traceroute Works
Traceroute Implementations
Windows uses an ICMP-only traceroute-like utility called 'tracert'.
UNIX, Linux and BSD based systems use a UDP-based traceroute.
Why is this difference important? Because there is a difference how these tools work and in how networks will handle the packets these different tools produce. It can be argued that the Windows tool isn't traceroute at all.
Windows 'tracert'
- The user sitting in front of the computer BINKY runs the tracert command at the command line. The command line is the MS-DOS prompt in Windows.
- The user types the word tracert followed by the destination
address, which can be either a name or an IP
address, and presses the enter or return key on the
keyboard.
For example:
Windows / MS-DOS
c:\> tracert login.oscar.aol.com
- Binky, running tracert on a Windows computer creates 3 ICMP echo (ICMP type '8') messages with the time to live in the IP Header set to 1 and addresses the packets set to the destination computer's IP address (we'll call the destination computer clown).
- Binky starts a timer.
- Binky sends the three messages destined for clown out to the network.
- Binky waits for a response. This response will be:
- The computer on which the messages die because the time to live expired (somewhere between Binky and clown ) sends back ICMP Time Exceeded (ICMP Type '11') responses. These messages indicate to Binky that the traceroute messages have not yet reached the destination clown.
- Binky receives those Time Exceeded messages, notes the time they arrived, compares that to the time the ICMP Echo Request was sent and shows the results of that round trip on the screen.
- Binky increments the TTL in the IP Header by one, then repeats steps the previous six steps (creates 3 packets, sets the Time to Live to the next highest number, starts a timer, transmits the packets, waits for a response). This process is repeated until the packets reach the destination computer (clown) which Binky is tracing the route to.
- When the destination computer (clown) receives the packets, it sends back an ICMP Reply (ICMP type '0') and the traceroute program stops.
UNIX, Linux, Cisco and BSD 'traceroute'
The *NIX process is a bit different because it uses the Van Jacobson modification of using a UDP port number and relying on port unreachable errors to signify the end of the traceroute.
Only the outbound packets are sent to UDP ports starting with 33434. The returning packets are ICMP and the UDP port number on the outbound packet usually increments upwards from UDP 33434 to match the TTL set in the IP Header. This is why some firewalls block UNIX/Linux/BSD traceroute but let Windows traceroute through.
Regarding Routers and Traceroute
If a router finds a TTL value of 1 or 0, it drops the datagram and sends back an Internet Control Message Protocol (ICMP) Time-Exceeded message to the sender. Traceroute determines the IP address of the first hop by examining the source address field of the ICMP Time-Exceeded message.
To identify the next hop, traceroute sends a UDP packet with a TTL value of 2. The first router decrements the TTL field by 1 and sends the datagram to the next router. The second router sees a TTL value of 1, discards the datagram, and returns the Time-Exceeded message to the source. This process continues until the TTL is incremented to a value large enough for the datagram to reach the destination host or until the maximum TTL is reached or the destniation host replies with an ICMP Echo Reply.
Van Jacobson's Traceroute
The Traceroute command didn't actually work very well originally because of the interpretation of RFC 791 by routing equipment vendors. Thus, to fix this, Van Jacobson wrote a variant to Traceroute that worked so well and reliably, it was ported to all systems and used as the default. Many college textbooks still refer to this application when describing the functionality inside traceroute.
The Van Jacobson version used outbound UDP datagrams from the host running traceroute instead of ICMP. This was the default on any system using the Van Jacobson version of Traceroute including most BSD and UNIX type systems.
To determine when a datagram reached its final destination, traceroute set the UDP destination port in the datagram to a very large value (33434 or higher) that the destination host is unlikely to be using. When a host receives a datagram with an unrecognized port number, it sends an ICMP Port Unreachable error message to the source. The Port Unreachable error message indicates to traceroute that the destination has been reached.
A FOOTNOTE
The first version of Traceroute used ICMP but not all routers responded properly to the ICMP echo requests due to the strict interpretation of RFC 791. Thus, VanJacobson wrote a UDP version which was widely used on UNIX and Linux systems and was the only functional version of traceroute at the time this tutorial was originally written. Here is Mr. Jacobson's answer to the question of why he used UDP 33434-33535:
The original ip spec (rfc791) said that you should never send an
icmp error in reponse to an icmp packet. Several years later
this was amended to "... in response to an icmp *error* packet" but,
at the time that traceroute was written, most router vendors had
implemented according to the original spec & wouldn't send an
icmp time exceeded in response to an icmp echo or echo reply. I
then tried using an unassigned ip protocol instead of udp but it
turned out that crashed HPUX systems (remember this was ten
years ago, IP was new & there were lots of flakey implementations).
The only thing that worked & didn't appear to do damage was
udp to a port range that wasn't (& still isn't) used very often.
See also: Traceroute Messages, Traceroute example