Perhaps the question required a more detailed answer. We have discussed 
this numerous times, but here it is again....

The results provided by trace-route are rough round-trip measurements to 
each router in the path to a destination and finally a measurement also to 
the actual destination. With most implementations, you will see three 
results for each router and the destination. The timing measurements 
account for processing time at the recipients in addition to raw 
propagation delay. Trace-route can be used as a rough estimate of the time 
to reach destinations. It is most useful, however, as a method for checking 
the path to a remote destination.

With Unix and Cisco IOS and "real" operating systems, this is how 
trace-route works:

A trace-route packet is a User Datagram Protocol (UDP) "probe" packet sent 
to port 33434 or some other large UDP port. Trace-route works by taking 
advantage of the ICMP error message a router generates when a packet 
exceeds its time-to-live (TTL) value. TTL is a field in the IP header of an 
IP packet.

Trace-route starts by sending a UDP probe packet with a TTL of one. This 
causes the first router in the path to discard the probe and send back a 
destination unreachable, time-exceeded ICMP message. One of the first 
things an IP router does is decrement the TTL (which is essentially a hop 
count value). If the decrement causes the time-to-live to reach zero, then 
the packet is dead (discarded).

The trace-route command sends several probes, increasing the TTL by one 
after three packets have been sent at each TTL value. For example, it sends 
three packets with TTL equal to 1, then three packets with TTL equal to 2, 
then three packets with TTL equal to 3, and so on, until the destination 
host is reached or a configured maximum number of tries (usually 30) is 
reached.

Each router in the path decrements the TTL. The router that decrements the 
TTL to 0 sends back the time-exceeded message. The final destination host 
sends back a destination unreachable, port-unreachable ICMP message, 
because UDP port 33434 is not a well-known port. This process allows a user 
to see a message from every router in the path to the destination, and a 
message from the destination.

Unfortunately, trace-route is not dependable. Some routers do not send back 
time-exceeded messages. Some routers incorrectly use the TTL of the 
incoming packet to send the time-exceeded message, which does not work. 
Also, some end systems do not send the port-unreachable message which means 
that trace-route waits for a long time before timing out. Finally, some 
service providers purposely change the results of trace-route to hide 
internal hops.

Microsoft trace-route also makes use of the IP TTL feature and router 
behavior with respect to TTL. Microsoft trace-route sends an ICMP ping 
rather than an UDP probe packet, however. The only real difference is that 
when the message reaches the final destination, the destination normally 
responds to the ping, rather than sending a port unreachable message.

Priscilla


At 01:07 PM 6/21/01, ElephantChild wrote:
>On Thu, 21 Jun 2001, cisco guru wrote:
>
> > Hi,
> > When I do a traceroute www.cisco.com, I get a reply with 3 timings as in
> > 13   193 ms   176 ms   181 ms  www.cisco.com [198.133.219.25]
> >
> > What does 193ms 176ms and 181 ms stand for? SRTT??
> > Would someone kindly explain?
>
>% man traceroute
>...
>        This  program  attempts  to  trace  the route an IP packet
>        would follow to some internet host by launching UDP  probe
>        packets with a small ttl (time to live) then listening for
>        an ICMP "time exceeded" reply from a  gateway.   We  start
>        our  probes with a ttl of one and increase by one until we
>        get an ICMP "port unreachable"  (which  means  we  got  to
>        "host")  or  hit a max (which defaults to 30 hops & can be
>        changed with the -m flag).  Three probes (change  with  -q
>        flag)  are  sent at each ttl setting and a line is printed
>        showing the ttl, address of the  gateway  and *round  trip
>        time  of  each probe.*
>
>(emphasis mine).
>
>--
>"Someone approached me and asked me to teach a javascript course. I was
>about to decline, saying that my complete ignorance of the subject made
>me unsuitable, then I thought again, that maybe it doesn't, as driving
>people away from it is a desirable outcome." --Me
________________________

Priscilla Oppenheimer
http://www.priscilla.com




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=9399&t=9307
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to