Quote from rt.com:

A more interesting example is:

       [yak 72]% traceroute allspice.lcs.mit.edu.
       traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
        1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
        2  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  19 ms  19 ms
        3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  19 ms
        4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  19 ms  39 ms  39 ms
        5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  20 ms  39 ms  39 ms
        6  128.32.197.4 (128.32.197.4)  59 ms  119 ms  39 ms
        7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  39 ms
        8  129.140.70.13 (129.140.70.13)  80 ms  79 ms  99 ms
        9  129.140.71.6 (129.140.71.6)  139 ms  139 ms  159 ms
       10  129.140.81.7 (129.140.81.7)  199 ms  180 ms  300 ms
       11  129.140.72.17 (129.140.72.17)  300 ms  239 ms  239 ms
       12  * * *
       13  128.121.54.72 (128.121.54.72)  259 ms  499 ms  279 ms
       14  * * *
       15  * * *
       16  * * *
       17  * * *
       18  ALLSPICE.LCS.MIT.EDU (18.26.0.115)  339 ms  279 ms  279 ms

Note  that  the  gateways  12,  14,  15, 16 & 17 hops away
either don't send ICMP "time exceeded"  messages  or  send
them  with  a ttl too small to reach us.  14 - 17 are run-
ning the MIT  C  Gateway  code  that  doesn't  send  "time
exceeded"s.  God only knows what's going on with 12.

The  silent gateway 12 in the above may be the result of a
bug in the 4.[23]BSD network code (and  its  derivatives):
4.x  (x  <= 3) sends an unreachable message using whatever
ttl remains in the original datagram.   Since,  for  gate-
ways,  the remaining ttl is zero, the ICMP "time exceeded"
is guaranteed to not make it back to us.  The behavior  of
this  bug  is slightly more interesting when it appears on
the destination system:

        1  helios.ee.lbl.gov (128.3.112.1)  0 ms  0 ms  0 ms
        2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  19 ms  39 ms
        3  lilac-dmc.Berkeley.EDU (128.32.216.1)  19 ms  39 ms  19 ms
        4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  19 ms
        5  ccn-nerif35.Berkeley.EDU (128.32.168.35)  39 ms  39 ms  39 ms
        6  csgw.Berkeley.EDU (128.32.133.254)  39 ms  59 ms  39 ms
        7  * * *
        8  * * *
        9  * * *
       10  * * *
       11  * * *
       12  * * *
       13  rip.Berkeley.EDU (128.32.131.22)  59 ms !  39 ms !  39 ms !

Notice that there are 12 "gateways" (13 is the final  des-
tination) and exactly the last half of them are "missing".
What's really happening is that rip (a Sun-3  running  Sun
OS3.5)  is using the ttl from our arriving datagram as the
ttl in its ICMP reply.  So, the reply will time out on the
return  path  (with  no notice sent to anyone since ICMP's
aren't sent for ICMP's) until we probe with a  ttl  that's
at  least twice the path length.  I.e., rip is really only
7 hops away.  A reply that returns with a ttl of  1  is  a
clue  this  problem exists.  Traceroute prints a "!" after
the time if the ttl is <= 1.  Since vendors ship a lot  of
obsolete  (DEC's  Ultrix,  Sun 3.x) or non-standard (HPUX)
software, expect to see  this  problem  frequently  and/or
take care picking the target host of your probes.