Traceroute: Trace IP packets
traceroute, written by Van Jacobson, lets you discover the sequence of gateways that an IP packet travels through to reach its destination. Almost all modern operating systems come with some version of traceroute.
The syntax is simply
traceroute hostname
There are a variety of options, most of which are not important in daily use. As usual, the hostname can be specified either symbolically or numerically. The output is simply a list of hosts, starting with the first gateway and ending at the destination.
For example, a traceroute from the host jaguar to the host drevil produces the following output:
% traceroute drevil
traceroute to drevil (192.225.55.137), 30 hops max, 38 byte packets
1 xor-gw2 (192.108.21.254) 0.840 ms 0.693 ms 0.671 ms
2 xor-gw4 (192.225.56.10) 4.642 ms 4.582 ms 4.674 ms
3 drevil (192.225.55.137) 7.959 ms 5.949 ms 5.908 ms
From this output we can tell that jaguar is exactly three hops away from drevil, and we can see which gateways are involved in the connection. The round trip time for each gateway is also shown--three samples for each hop are measured and displayed. A typical traceroute between Internet hosts can include ten or twenty hops. traceroute works by setting the time-to-live (TTL, actually -hop count to live") field of an outbound packet to an artificially low number. As packets arrive at a gateway, their TTL is decreased. When a gateway decreases the TTL to 0, it discards the packet and sends an ICMP -time exceeded" message back to the originating host.
The first few traceroute packets have their TTL set to 1. The first gateway to see such a packet (xor-gw2 in this case) determines that the TTL has been exceeded and notifies jaguar of the dropped packet by sending back an ICMP message. The sender's IP address in the header of the error packet identifies the gateway; traceroute looks up this address in DNS to find the gateway's hostname.
To identify the second-hop gateway, a second round of packets with TTL fields set to 2 are sent out. The first gateway routes the packets and decreases their TTL by 1. At the second gateway, the packets are then dropped and ICMP error messages generated as before. This process continues until the TTL is equal to the number of hops to the destination host and the packets reach their destination successfully.
Most routers send their ICMP messages from the interface -closest" to your host. If you run traceroute backwards from the destination host, you will probably see different IP addresses being used to identify the same set of routers.
Since traceroute sends three packets for each value of the TTL field, you may sometimes observe an interesting artifact. If an intervening gateway multiplexes traffic across several routes, the packets might be returned by different hosts; in this case, traceroute simply prints them all. Let's look at a more interesting example from a host at colourado.edu to xor.com:
rupertsberg% traceroute xor.com
traceroute: Warning: xor.com has multiple addresses; using 192.225.33.1
traceroute to xor.com (192.225.33.1), 30 hops max, 40 byte packets
1 cs-gw3-faculty.cs.colorado.edu (128.138.236.3) 1.362 ms 2.144 ms
2.76 ms
2 cs-gw-dmz.cs.colorado.edu (128.138.243.193) 2.720 ms 4.378 ms 5.052
ms
3 engr-cs.Colorado.EDU (128.138.80.141) 5.587 ms 2.454 ms 2.773 ms
4 hut-engr.Colorado.EDU (128.138.80.201) 2.743 ms 5.643 ms 2.772 ms
5 cuatm-gw.Colorado.EDU (128.138.80.2) 5.587 ms 2.784 ms 2.777 ms
6 204.131.62.6 (204.131.62.6) 5.585 ms 3.464 ms 2.761 ms
7 border-from-BRAN.coop.net (199.45.134.81) 5.593 ms 6.433 ms 5.521
ms
8 core-gw-eth-2-5.coop.net (199.45.137.14) 53.806 ms * 19.202 ms
9 xor.com (192.225.33.1) 16.838 ms 15.972 ms 11.204 ms
This output shows that packets must traverse five of our internal gateways before leaving the colourado.edu network (cs-gw3-faculty to cuatm-gw). The next-hop gateway on the BRAN network (204.131.62.6) doesn't have a name in DNS. After two hops in coop.net, we arrive at xor.com.
At hop 8, we see a star in place of one of the round trip times. This notation indicates that no response (error packet) was received in response to the probe. In this case, the cause is probably congestion, but that is not the only possibility. traceroute relies on low-priority ICMP packets, which many routers are smart enough to drop in preference to -real" traffic. A few stars shouldn't send you into a panic.
If you see stars in all of the round trip time fields for a given gateway, no -time exceeded" messages are arriving from that machine. Perhaps the gateway is simply down. Sometimes, a gateway will be configured to silently discard packets with expired TTLs. In this case, you will still be able to see through the silent host to the gateways beyond. Another possibility is that the gateway's error packets are slow to return and that traceroute has stopped waiting for them by the time they arrive.
Some firewalls block ICMP -time exceeded" messages entirely. If there's one of these firewalls along the path, you won't get information about any of the gateways beyond it. However, you can still determine the total number of hops to the destination because the probe packets will eventually get all the way there. Also, some firewalls may block the outbound UDP datagrams that traceroute sends to trigger the ICMP responses. This problem causes traceroute to report no useful information at all.
A slow link does not necessarily indicate a malfunction. Some physical networks have a naturally high latency. Sluggishness can also be a sign of congestion on the receiving network, especially if the network uses a CSMA/CD technology that makes repeated attempts to transmit a packet (Ethernet is one example). Inconsistent round trip times would support such a hypothesis, since collisions increase the randomness of the network's behavior.
Sometimes, you may see the notation !N instead of a star or round trip time. It indicates that the current gateway sent back a -network unreachable" error, meaning that it doesn't know how to route your packet. Other possibilities include !H for -host unreachable" and !P for -protocol unreachable." A gateway that gives you any of these error messages will usually be the last hop you can get to. That host usually has a routing problem (possibly caused by a broken link): either its static routes are wrong or dynamic protocols have failed to propagate a usable route to the destination.
If traceroute doesn't seem to be working for you (or is working incredibly slowly), it may be timing out while trying to resolve the hostnames of gateways by using DNS. If DNS is broken on the host you are tracing from, use traceroute -n to request numeric output. This option prevents the use of DNS; it may be the only way to get traceroute to function on a crippled network.
15%
7%
