This could be the traceroute faq.  It could be V1.00 dated 18-mar-1996,
but more like it's V1.01 dated 06-Aug-2001. (Yes, that would be more
than five years between updates...)

You could get it via
	ftp://ftp.aces.com/pub/software/traceroute/traceroute.faq

You could also send a six-pack of a microbrew beer to gavron@aces.com
(address available via WHOIS) and ask him to send you a snailmail copy.
That request has yielded zero beer in five years, so how about we
change it a request for single-malt Scotch or Cuban cigars.

You could also keep this copy.

It's up to you.

...

	Q: What is an FAQ?

	A: It is a series of notes designed to explain the best uses 
	   of Traceroute.


	Q: What's wrong with PING?

	A: Nothing's wrong with PING.  Unfortunately, today's networks
	   are a bit faster, more congested, and more dynamically routed
	   than the ARPAnet of yore for which PING was invented.  PING's
	   1 second resolution, it's unfailing ability to use ICMP echo
	   request/echo response which requires ICMP processing on both
	   hosts, and its lack of simultaneous multiple-probe functionality
	   make it a bit less than useful.


	Q: What's wrong with TRACEROUTE?

	A: Nothing.  Unfortunately, too many people aren't aware of how
	   to best use it.

	
	Q: How do you best use it?

	A: That depends.  Specifically it depends on whether you're using
	   it to determine 
		1. Routing paths
		2. Routing asymmetry
		3. Path loss or congestion


	Q: So tell us
	A: Glad you asked...
	
	1. Routing paths
	   Traceroute is a fantastic tool for discovering RFC-791 [p.12]
	   compliant routers along the way between you and your destination
	   host.  While RFC-791 means "IP" and this would conceivably mean
	   "all IP routers," some manufacturers are too stupid to do this.

	   To use traceroute in this fashion, type
		traceroute destination-host

	   Example:
		traceroute ns.internic.net

	   The resulting display will show all "hops" from your first
	   router down the line (hop 1) to the final host.  

	   If you see two consecutive hops with the same host IP address,
	   rest assured that the first one violated RFC-791.

	2. Routing Asymetry
	   At times, a destination's host's path back to the originating host
	   may go over different circuits than the original path.  This is
	   called routing asymetry (or asymetrical routing).  It's a good
	   thing because you're testing as much network hardware as possible
	   all at once.  It's a bad thing for similar reasons.  It also plays
	   havoc with NTP's (Network Time Protocol) abilities to judge path
	   time.

	   To find routing asymetry, one needs to do a traceroute from the
	   destination host back to the source host.  This is done using an
	   IP option called LSRR (Loose Source and Record Route).  As this
	   is an option, not all manufacturers support it.  Livingston is one
	   such bad guy.

	   Usage:	traceroute  specify-lsrr-host origin-host

	   Example: (VMS) traceroute/lsrr=remote-host-somewhere my.host.domain
		    (unix) traceroute -g remote-host-somewhere my.host.domain

	   These generate a route from you to the remote-host-somewhere and back
     	   to my.host.domain.


	3. Path congestion or loss
	   Ever since they let graduate students invent software, the Internet
	   has gone to hell in a handbasket.  (We're talking about Mosaic and
	   the Web here.)  This has left lots more people connected to a much
	   less reliable network.

	   To discover these, it's useful to send out lots and lots of packets,
	   time them all, and see how many are received.

	   Traceroute includes this ability.  It can send multiple probes...
	   and it can summarize loss and latency characteristics.

	   Usage:	traceroute  specify-probes destination-host

	   Example: (VMS) traceroute/number=100/delay_stats destination.host
	 	    (Unix) traceroute -q 100 -Q destination.host

	   Note: SPRINT's backbone and MCI's backbone and several others use
	         Cisco routers.  (This is a Good Thing).  SPRINT uses 
	         experimental code which is perfectly happy to drop a lot of
	    	 the duplicate-looking ICMP packets that traceroute uses.

		 Thus, you should IGNORE a loss figure unless you see it 
		 continue on all subsequent hops.

		 Example.  If on hop N you see 10% loss, and hop N+1 you see
		 11% loss, and hop N+2 you see 9% loss, you can definitely
	  	 claim that you think there's a 9% real loss at hop N.

	         Example 2. If on hop N you see 10% loss, and hop N+1 you see
		 5% loss, and hop N+2 you see 0% loss, you can definitely 
	  	 claim that there is no loss.



Ehud

--
Ehud Gavron	(EG76)
