OK, so it's a bit long. The first line just summarizes what traceroute is going to do: trace the route to www.hut.fi (which is actually called info-e.hut.fi) for a maximum of 30 hops, using 40-byte packets.
The trip then goes through 19 routers, or 19 hops. The first one, which takes 5 to 6 milliseconds, is to my router at home and the second hops across my ISDN line, which takes 30 or so milliseconds. It then winds its way through our corporate LAN to BBNplanet. The seventh and twelfth hops are interesting, 'cause that's where times increase dramatically as it is going across the country and then across the Atlantic Ocean.
Sometimes times increase dramatically because the packet is crossing long distances, and other times the increases come from network congestion. You should be suspicious of a radical increase in one or two of the probes. If this happens, you can check things out by pinging the router a couple of times to see if packets are being dropped or if there is a great variance in times.
Also, starting at the seventh hop, we start seeing (ttl=number!) next to the times. This is an indication from traceroute that the TTLs it sees coming back don't match what it sent. This is an indication that there may be an asymmetric path. An asymmetric path is one in which a packet takes one route going in one direction and a different route coming back. This is common nowadays.
Note the asterisks on lines 6, 13, and 15. They indicate that a response wasn't received. Because there was no response from router 15, an educated guess would be that that router doesn't issue TTL-expired ICMP messages. The asterisks on line 6 and 13 are probably the result of dropped packets.
Combined with ping, traceroute makes a good network troubleshooting tool. By looking at traceroute output and looking for hops that have excessive times or dropped packets, one can find potential trouble spots in the path. Then by pinging the suspected hop, plus the hop before it, a larger sample of data can be accrued to determine if there is a problem.
A note of caution: Traceroute was designed for network testing. It should be used manually. Using it from scripts could adversely affect network performance.
Coda: Traceroute was written by Van Jacobson. Van heads up the Network Research Group at Lawrence Berkeley National Labs. His group has contributed greatly to the state of the TCP/IP protocols we use today. One of the cool things that NRG is currently working on is a program called pathchar, a tool that infers the characteristics of Internet paths. It infers the available bandwidth and size of the pipe per hop. Currently pathchar is in testing and only available for select Unix and Linux platforms. Test copies of the pathchar binary are available at ftp://ftp.ee.lbl.gov/pathchar. If you have a Unix or Linux platform to run it on, I'd recommend checking it out.
