1. The following command traces the route a packet takes from
       localhost to the host nis.nsf.net:

       localhost> traceroute nis.nsf.net

       traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet

        1  helios.ee.lbl.gov (128.3.112.1)  19 ms  19 ms  0 ms
        2  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms 19 ms
        3  lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms 19 ms
        4  ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
        5  ccn-nerif22.Berkeley.EDU (128.32.168.22)  39 ms  39 ms  39 ms
        6  128.32.197.4 (128.32.197.4)  40 ms  59 ms  59 ms
        7  131.119.2.5 (131.119.2.5)  59 ms  59 ms  59 ms
        8  129.140.70.13 (129.140.70.13)  99 ms  99 ms  80 ms
        9  129.140.71.6 (129.140.71.6)  139 ms  239 ms  319 ms
       10  129.140.81.7 (129.140.81.7)  220 ms  199 ms  199 ms
       11  nic.merit.edu (35.1.1.48)  239 ms  239 ms  239 ms
 Note that lines 2 and 3 are identical. This is due to a bug in the
 kernel on the 2nd hop system, lbl-csam.arpa, that forwards packets
 with a zero ttl (a bug in the distributed version of 4.3BSD). The
 NSFNet (129.140) does not supply address-to-name translations for
 its NSSes. Therefore, you cannot be certain of the path the packets
 take cross-country.

    2. The following is another example of output from the
       traceroute com mand. Packets from localhost to the host
       allspice.lcs.mit.edu are being traced:

       localhost> 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 and 17 hops away either
       do not send ICMP "time exceeded" messages or send them with
       a ttl too small to reach localhost. Further investigation is
       required to determine the cause. For example, by contacting
       the system administrators for gateways 14 through 17, you
       could discover that these gateways are running the MIT C
       Gateway code that does not send "time exceeded" messages.

       The silent gateway 12 in the example 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 gateways, the
       remaining ttl is zero, the ICMP "time exceeded" is guaranteed
       to not make it back to us.

       When this bug appears on the destination system it behaves as
       follows:

        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 !

       Note that there are 12 gateways (13 is the final destination
       and the last half of them are missing. What is happening is
       that the host rip (a Sun-3 running Sun OS3.5) is using the ttl
       from our arriving datagram as the ttl in its ICMP reply. The
       reply will time out on the return path (with no notice sent to
       anyone since ICMPs are not sent for ICMPs) until we probe with
       a ttl that is at least twice the path length. This means that
       the host rip is really only 7 hops away. A reply that returns
       with a ttl of 1 is a clue this problem exists. The traceroute
       command prints a ! after the time if the ttl is less than or
       equal to 1. Since many systems continue to run obsolete or
       non-standard software, expect to see this problem frequently.