NAME
na.ippath - print the path that packets take to a network host
DESCRIPTION
The na.ippath proxy agent attempts to trace an IP packet's path between the proxy system and the destination host.
The agent initially launches three 38-byte UDP probe packets with ttl (time to live) of 1, listens for an ICMP ``time exceeded'' reply from the nearest gateway, and then measures the round trip time of each probe/reply.
It then increments the ttl and sends three more probes, collecting time exceeded replies and measuring the round trip time. The agent continues to increment the ttl and send out three probes at a time until it receives an ICMP ``port unreachable'' reply, which means the probe reached the destination host, or until the maximum number of hops is reached. The destination port is set to an unlikely value, so that the destination host does not process the UDP probe packets.
The na.ippath agent returns a table. Each row in the table shows the ttl (as ``hop''), symbolic and numeric address of the gateway, and average round trip time of the probes. If the probe answers come from different gateways, only the first responding system is printed, but the round trip times are still measured to compute the average.
Each probe will wait up to 3 seconds for a reply. If none of the three probes are answered, the agent prints ``???'' for the system name and address.
This proxy agent should be used primarily for manual fault isolation. Because of the load it could impose on the network, you should use na.ippath via one-time (``Quick Dump'') operations only. It is unwise to use na.ippath from automated scripts or from ongoing data/event reports. If the proxy agent is instructed to report more than once and you do not specify a reporting interval, it will report every 10 minutes.
ATTRIBUTES
na.ippath has one attribute table, path . The attributes in the table are:
hop - number of hops away from proxy system (int) system - name of the system that is hop hops away (string) address - IP address of the system that is hop hops away (string) avgtrip - average trip time (in milliseconds) from the proxy system to the system that is hop hops away (gauge) note - an optional field that describes potential problems with the system that is hop hops away (string)
OPTIONS
The proxy agent operates with some default rules that can be overridden with options. Options accepted are:
Sat Oct 27 21:37:48 1990 [ nis.nsf.net ] : Quick Dump: ippath.path
hop system address avgtrip
1 helios.ee.lbl.gov 128.3.112.1 12 2 lilac-dmc.Berkeley.EDU 128.32.216.1 26 3 lilac-dmc.Berkeley.EDU 128.32.216.1 26 4 ccngw-ner-cc.Berkeley.EDU 128.32.136.23 39 5 ccn-nerif22.Berkeley.EDU 128.32.168.22 39 6 128.32.197.4 128.32.197.4 52 7 131.119.2.5 131.119.2.5 59 8 129.140.70.13 129.140.70.13 92 9 129.140.71.6 129.140.71.6 232 10 129.140.81.7 129.140.81.7 206 11 nis.nsf.net 35.1.1.48 239
In the output above, hops 2 & 3 are the same, due to a buggy kernel on the second hop system, lbl-csam.arpa. It forwards packets with a zero ttl (as a result of a bug in the distributed version of 4.3BSD). Note that you have to guess what path the packets are taking cross-country since the NSFNet (129.140) generally doesn't supply address-to-name translations for its NSSes.
A more interesting example is:
Sat Oct 27 21:51:01 1990 [ bluejay ] : Quick Dump: ippath.path
hop system address avgtrip
1 commserv 129.144.44.2 3 2 snu-ebb 129.144.1.43 6 3 ??? ???
4 bluejay 129.144.152.31 10
Note that the gateway three hops away either doesn't send ICMP ``time exceeded'' messages or sends them with a ttl too small to reach you.
The silent gateway 3 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 gateways, the remaining ttl is zero, the ICMP ``time exceeded'' is guaranteed to not make it back to you. The behavior of this bug is slightly more interesting when it appears on the destination system, as follows:
Sat Oct 27 21:54:20 1990 [ tweedle ] : Quick Dump: ippath.path
hop system address avgtrip note
1 commserv 129.144.44.2 3 2 nico-ebb 129.144.1.91 10 3 olala-bb 129.144.156.88 10 4 ??? ???
5 ??? ???
6 ??? ???
7 tweedle 129.144.145.5 3 TTL <= 1
In this output there are six ``gateways'' (7 is the final destination). Exactly the last half of them are ``missing.'' Actually, tweedle is using the ttl from the 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 aren't sent for ICMPs-until probed with a ttl at least twice the path length. So tweedle is really only four hops away. A reply that returns with a ttl of 1 is a clue that this problem exists. The agent prints a note after the time if the ttl is <= 1. Since there is still a lot of obsolete and non-standard software in the world, expect to see this problem frequently and/or take care picking the target host of your probes.
Other possible annotations after the time include: Host Unreachable , Net Unreachable , Protocol Unreachable (got a host, network, or protocol unreachable, respectively), Source Route Failed , or Frag Needed (source route failed or fragmentation needed). Neither of the last two annotations should ever occur; the associated gateway is busted if you see one. If almost all the probes result in some kind of unreachable annotation, the agent will give up and exit.
NOTES
The agent collects all the path information before reporting; thus, the report may take a few seconds to show up. The amount of time it takes depends on the number of hops in the path and the amount of time the agent has to wait for each probe response.
The na.ippath proxy agent was originally implemented as the command line program traceroute by Van Jacobson from a suggestion by Steve Deering. It was debugged by a cast of thousands, with particularly cogent suggestions or fixes from C. Philip Wood, Tim Seaver and Ken Adelman. The conversion to a SunNet Manager agent was done at Sun Microsystems.
SEE ALSO
netstat(1M), ping(1M)