Network Computingwww.networkcomputing.com

• Part I
• Part II

Just as ping allows you to verify connectivity between different devices, traceroute allows you to identify the route that datagrams are taking on their way to a remote device. This is achieved by sending a series of packets with incrementally larger Time-to-Live values, and then monitoring for ICMP Time Exceeded error messages as the packets expire on the way to the destination system.

The first packet sent by traceroute will have a Time-to-Live value of 1. When the packet is received by the first-hop router on the local network, the router will be unable to forward the datagram without the Time-to-Live value reaching zero, so the router will discard the datagram and send an ICMP Time Exceeded error message back to the sender.

traceroute records the IP address of the router that returned the datagram, and then sends another datagram with the Time-to-Live field set to 2. This time the datagram makes it past the first-hop router to the next router in the path. However, since the Time-to-Live value will have been set to 1 by the first-hop router during the forwarding process, the next-hop router will reject the packet and send an ICMP Time Exceeded error message back to the sending system.

This process is repeated over and over, until the final destination system has been reached. Once that occurs, the local system will have received ICMP Time Exceeded error messages from every router between itself and the final destination system, and will therefore have a complete map of the intermediary network.

It is important to note that different versions of traceroute use different types of data for the "seed" datagrams, and the responses you get will probably vary according to the version you use. The original version of traceroute was written by Van Jacobsen at the Lawrence Berkeley Labs in Berkeley, California, and is the default version that ships with most Unix systems. Other vendors and TCP/IP implementations ship versions of traceroute that work somewhat differently

Van Jacobsen's version of traceroute sends three UDP messages for every "send" effort, allowing average latencies to be determined for each hop along the path. In addition, this version of traceroute increments the destination UDP port number of each datagram that it sends, allowing the latency times for each datagram to be tracked individually (this is important in case one or more packets gets sidetracked somewhere, and ends up getting returned later than other datagrams sent afterwards).

For example, Figure 5-36 shows a capture of a traceroute session between Greywolf and www.ora.com. This version of traceroute uses the Van Jacobsen model, which sends three UDP datagrams to the destination system in a batch, with each of the datagrams having an incrementally higher destination port number. As the Time-to-Live values of the IP datagrams expire, they are rejected by intermediary routers along the way. This information is then used to display summary data about the latencies of the networks in between the sender and the destination system.

Figure 5-36
traceroute using UDP datagrams

Once the seed UDP datagrams reach the destination system, they may be rejected with ICMP Destination Unreachable: Port Unreachable error messages, although it is also possible that some form of response may come back to the sender via UDP (if one of the target port numbers were active). Regardless, some sort of event should happen that will indicate the complete path has been discovered.

However, that was not the case in this example. Indeed, the last-hop from the traceroute shown in this test failed on a continuous basis, due to no response coming back from the remote system, as is shown in Figure 5-37.

Figure 5-37
UDP traceroute failing, due to firewall blocking

This could be a result of a number of factors, although most likely it is due to a firewall on the ora.com network blocking the unsolicited UDP messages from entering the network, meaning they will never be seen by the target system. This scenario is quite common, and is discussed in detail in "Firewalls Blocking UDP Messages" in Chapter 6, The User Datagram Protocol. It could also be that a firewall is blocking the ICMP response messages, preventing the local system from seeing the resulting messages. This is also quite common and is discussed in detail later in "Troubleshooting ICMP."

The output from the traceroute session shown in Figure 5-36 can be seen in Figure 5-38. As can be seen, the last-hop is shown as unknown (the "*" indicates that the request timed out), since traceroute is not receiving any responses from either the destination system or any intermediary routers. As such, it continues to increment the Time-To-Live value of the outgoing IP packets, until the process is terminated by the user.

Figure 5-38
Visual output of the traceroute from Figure 5-36

There have been some problems with the Van Jacobsen version of traceroute. For one thing, many firewalls block unsolicited UDP datagrams (as discussed above). In addition, the use of incremental UDP port numbers can make these messages appear to be port scans on the destination system, which can trigger false alarms for security-conscious sites.

For these reasons, there are a variety of other traceroute programs that use ICMP Echo Request query messages for the seed data, instead of UDP datagrams. Another advantage to using ICMP Echo Request messages is that these messages contain built-in Identifier and Sequence Number fields, which provide better packet-tracking mechanisms for traceroute to use in its per-hop calculations than UDP port numbers do.

Figure 5-39 shows a traceroute session between Arachnid and www.ora.com, using ICMP Echo Request query messages as the seed. Three ICMP Echo Request query messages are sent to the destination system in a batch, with each of the messages having incrementally higher Sequence Numbers (although the Identifier stays the same for all of them). As the Time-to-Live values of the IP datagrams expire, they are rejected by intermediary routers along the way. This information is then used to display summary data about the networks between the sender and the destination system.

Figure 5-39
traceroute using ICMP Echo Request query messages

Once the seed ICMP Echo Request query messages have reached the destination system, they should be responded to with ICMP Echo Reply query messages, indicating that the complete path has been discovered.

The output from the traceroute session shown in Figure 5-39 can be seen in Figure 5-40. This time traceroute runs to completion.

Figure 5-40
Visual output of the traceroute from Figure 5-39

There are problems with using ICMP Echo Request messages too, of course. One major problem is that many firewalls also block all forms of ICMP traffic, just as many firewalls will block unsolicited UDP datagrams.

The other big problem with this model is that not all TCP/IP implementations return ICMP error messages in response to an ICMP query message. RFC 1122 states that ICMP error messages should not be generated in response to other ICMP error messages. However, devices can (and should) generate ICMP error messages in response to ICMP query messages that fail. Unfortunately, not all vendors have made this distinction, and there are some implementations that do not return ICMP error messages in response to any ICMP traffic whatsoever.

RFC 1393 proposed yet another mechanism for traceroute programs to use, although this proposal has not been widely accepted. Essentially, RFC 1393 proposed that a device send a single IP datagram that contained an experimental Traceroute IP Option. As the datagram wound its way through the network, routers would issue an experimental ICMP Traceroute message back to the sending system, showing their IP address. By the time the original request datagram gets to the destination system, the sender would have a full map of all the devices on the path.

Although there are benefits to this model (only one seed datagram is required, and the return path could also be discovered independently of the seed path), there are also major problems with it, including the use of the experimental Traceroute IP Option and the experimental ICMP Traceroute message, neither of which have been standardized. For these reasons, this model is not widely supported.[_Fi_]