From van@helios.ee.lbl.gov Tue Dec 20 05:14:46 1988 Posted-Date: Tue, 20 Dec 88 05:13:28 PST Received-Date: Tue, 20 Dec 88 05:14:46 PST Received: from helios.ee.lbl.gov by venera.isi.edu (5.54/5.51) id AA25560; Tue, 20 Dec 88 05:14:46 PST Received: by helios.ee.lbl.gov (5.59/s2.2) id AA03127; Tue, 20 Dec 88 05:13:30 PST Message-Id: <8812201313.AA03127@helios.ee.lbl.gov> To: ietf@venera.isi.edu, end2end-interest@venera.isi.edu Subject: 4BSD routing diagnostic tool available for ftp Date: Tue, 20 Dec 88 05:13:28 PST From: Van Jacobson Status: R After a frustrating week of trying to figure out "where the !?*! are the packets going?", I cobbled up a program to trace out the route to a host. It works by sending a udp packet with a ttl of one & listening for an icmp "time exceeded" message. If it gets one, it prints the source address from the icmp message, then bumps the ttl by one & etc. (As usual, I didn't come up with this clever idea -- I heard Steve Deering mention it at an end-to-end task force meeting.) The use and printout looks like the following: % 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) 0 ms 0 ms 19 ms 2: lbl-csam.arpa (128.3.254.6) 10 ms 0 ms 10 ms 3: lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms 4: ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 39 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) 39 ms 39 ms 40 ms 7: 131.119.2.5 (131.119.2.5) 59 ms 39 ms 40 ms 8: 129.140.70.13 (129.140.70.13) 99 ms 99 ms 99 ms 9: 129.140.71.6 (129.140.71.6) 139 ms 139 ms 139 ms 10: 129.140.81.7 (129.140.81.7) 180 ms 199 ms 199 ms 11: nic.merit.edu (35.1.1.48) 259 ms 219 ms 219 ms (I typed the stuff after the "%" on the first line; the rest is trace output.) The first field is # hops, the second is the gateway used at that hop, the three remaining fields are the time it took the gateway to respond (three probe packets are sent at each ttl setting). [There's no manual entry yet but there's more documentation at the front of the source.] The (good?) news is you're welcome to ftp the source of this program from ftp.ee.lbl.gov (128.3.254.68), file traceroute.tar.Z. The bad news is that you'll have to hack your kernel to use it: You need to fix the raw IP output routine to allow a user program to set ip ttl. I've put my version of rip_output (raw ip output) in the README file of the tar. This works on our system but our system is rather non-standard. If you have source and are comfortable with kernel hacking, this should be the example you need to fix up your netinet/raw_ip.c (if you don't have source or aren't comfortable in the kernel, I'm afraid I can't help). Hope this is useful to someone. Good luck. Merry Christmas. - Van From van@helios.ee.lbl.gov Wed Dec 28 04:43:06 1988 Posted-Date: Wed, 28 Dec 88 04:43:53 PST Received-Date: Wed, 28 Dec 88 04:43:06 PST Received: from [128.3.112.2] by venera.isi.edu (5.54/5.51) id AA01411; Wed, 28 Dec 88 04:43:06 PST Received: by helios.ee.lbl.gov (5.59/s2.2) id AA09097; Wed, 28 Dec 88 04:43:57 PST Message-Id: <8812281243.AA09097@helios.ee.lbl.gov> To: ietf@venera.isi.edu, end2end-interest@venera.isi.edu Subject: updated traceroute (v1.13) available for ftp Date: Wed, 28 Dec 88 04:43:53 PST From: Van Jacobson Status: R An updated version of traceroute is available for anonymous ftp from ftp.ee.lbl.gov (128.3.254.68), file traceroute.tar.Z. I incorporated the bug fixes & suggestions from Tim Seaver, Ken Adelman and Phil Wood. I added a description of some 4.2/4.3 differences in raw ip and icmp input to the README file and added some #ifdefs to, hopefully, make it easier for people to bring the thing up on different systems. The probes are now sequence numbered so the trace doesn't get confused if the wait time is too small. Anomalies like an icmp reply with a ttl of 1 or a host/net unreachable are noted. The round trip time computation is now rounded, not truncated. Any size probe packet up to 64K can be sent (sending probes that fragment is a massively stupid idea & I debated this change but decided "what the heck; it's a debugging tool & the users are responsible and know what they're doing.") There's a flag to change the number of probe packets sent at each ttl. I included a couple of awk scripts to munch on the output. One prints the hop number vs median time to that hop. The other is similar but prints mean instead of median. On a non-trivial path, something like traceroute foo | awk -f median.awk | graph can help to quickly locate the bad spots. And some interesting mysteries surface (like: why is the nsfnet backbone 45ms/hop, essentially independent of distance?). Anyway, help yourself. I think I'm all done hacking on the thing now (famous last words). - Van