Impossible tri-bar

Digital Phenomena - Your first stop for internet consultancy 
Examine Your Network with Ping and Traceroute

Page 3 — Let's Go to Finland

Here is a more complicated example, trying to traceroute a host in Finland:

    % traceroute
    traceroute to (, 30 hops max, 40-byte packets
    1 ( 6 ms 5 ms 6 ms 
    2 ( 33 ms 33 ms 33 ms
    3 ( 39 ms 36 ms 38 ms 
    4 ( 39 ms 50 ms 37 ms
    5 ( 38 ms 46 ms 39 ms 
    6 * ( 43 ms 41 ms 
    7 ( 164 ms 161 ms (ttl=248!) 127 ms
    8 ( 118 ms (ttl=246!) 122 ms (ttl=246!) 103 ms (ttl=246!)
    9 ( 101 ms (ttl=245!) 102 ms (ttl=245!) 101 ms (ttl=245!) 
    10 icm-pen-1-H1/ ( 107 ms (ttl=244!) 107 ms (ttl=244!) 115 ms (ttl=244!) 
    11 icm-pen-11-P4/ ( 107 ms 110 ms 107 ms
    12 icm-tl2-10-P1/ ( 198 ms 240 ms 198 ms 
    13 ( 280 ms 218 ms * 
    14 ( 222 ms 230 ms 224 ms 
    15 * * *
    16 ( 216 ms (ttl=241!) 224 ms (ttl=241!) 217 ms (ttl=241!) 
    17 ( 237 ms (ttl=238!) 220 ms (ttl=238!) 226 ms (ttl=238!)
    18 ( 220 ms 237 ms 223 ms
    19 ( 291 ms (ttl=46!) 227 ms (ttl=46!) 267 ms (ttl=46!) 

OK, so it's a bit long. The first line just summarizes what traceroute is going to do: trace the route to (which is actually called 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 If you have a Unix or Linux platform to run it on, I'd recommend checking it out.

|Home|About Us|Services|Search|
W3C validatedW3C validated CSSCompatible with all browsers