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.