GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Traceroute troubles [7:61247]---------- Thank You. [7:62023] posted 01/28/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


I am sorry i am late in getting back to you...... You have answered my
question precisely.... You just cleared all the doubts i had...  I donot
think we can get any better explanation than this.Thank you very much.





-----Original Message-----
From: Priscilla Oppenheimer [mailto:nobody@xxxxxxxxxxxxxx]
Sent: Monday, January 20, 2003 2:53 PM
To: cisco@xxxxxxxxxxxxxx
Subject: RE: Traceroute troubles [7:61247]


Your question isn't clear. Maybe you could start over in a new thread
and
explain your question clearly, if the following info doesn't help. Once
a
thread gets this old, a lot of people ignore it. ;-)

However, I think I understand your confusion. You are worried because
Cisco
and UNIX use a UDP message for trace route. So how could disabling the
rate
limiting of ICMP fix the problem where trace route seems to fail every
so
often?

Yes, they send a UDP packet, but they depend on routers returning an
ICMP
Time-To-Live Exceeded message (ICMP type 11, code 0). If ICMP rate
limiting
is enabled on those routers, they won't send the message very time,
making
it appear as if trace route fails sometimes.

Here's how it works, from my book Troubleshooting Campus Networks, that
everyone should get, especially if you are studying for the Support test
for
CCNP. It covers all topics for that test. Hey, my publisher won't do any
marketing for me. I'll have to do it myself. Hope that's OK, if I keep
it to
a minimum. :-) Anyway, here's the info. (There are more details in the
book.)

"Trace-route displays the sequence of hops a packet traverses to get
from a
source to a destination. The results provided by trace-route are a
measurement of the round-trip time to each router in the path to a
destination and also a measurement of the round-trip time to the actual
destination. The timing measurements account for processing time at the
recipients in addition to propagation delay. Trace-route can be used as
a
rough estimate of delays on a network. It is most useful, however, as a
method for determining the path to a remote destination.

With UNIX and Cisco IOS operating systems, an IP trace-route packet is a
User Datagram Protocol (UDP) probe sent to a high UDP port number,
usually
in the 33,000 to 43,000 range. 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 1. This
causes the first router in the path to discard the probe and send back a
TTL
exceeded message. One of the first things a router does when forwarding
IP
packets is decrement the TTL (which is essentially a hop count value).
If
the decrement causes the TTL to reach 0, then the packet is dead
(discarded)
and a TTL exceeded message is sent.

The trace-route command sends several probes, increasing the TTL by 1
after
sending three packets at each TTL value. For example, trace-route 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 TTL exceeded message. The final destination host
sends back a port unreachable ICMP message, because the high UDP port
number
is not a well-known port number. This process allows a user to see a
message
from every router in the path to the destination, and a message from the
destination.

The trace-route facility in Microsoft operating systems sends a ping
(ICMP
echo) rather than a UDP packet. The trace-route command makes use of the
IP
TTL feature and router behavior with respect to TTL, but the packet is
an
ICMP echo instead of a UDP probe. 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."

Hope that helps!?
_______________________________

Priscilla Oppenheimer
www.troubleshootingnetworks.com
www.priscilla.com

Kumar, N K. Satish, NSPM wrote:
> 
> Guys,
>   Have anybody figured this out.....I seem to go nowhere
> thinking about
> this...... Your help appreciated as i am loosing sleep.
> 
> Thanks
> 
> 
> 
> 
> -----Original Message-----
> From: Kumar, N K. Satish, NSPM 
> Sent: Saturday, January 18, 2003 8:36 PM
> To: cisco@xxxxxxxxxxxxxx
> Subject: RE: Traceroute troubles [7:61247]
> 
> 
> I agree this works, but still that doesn;t answers one
> thing....Cisco
> and unix boxes where this * trouble is seen doesn;t use ICMP
> but uses
> UDP port for the trace output....
> 
> then howcome this is the fix !!!!!
> 
> Thanks
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: William Pearch [mailto:wpearch@xxxxxxxxxxxxx]
> Sent: Friday, January 17, 2003 1:13 AM
> To: cisco@xxxxxxxxxxxxxx
> Subject: RE: Traceroute troubles [7:61247]
> 
> 
> Solved my own problem - see CSCdu43762 on the CCO.  Shows up
> with the
> 7200
> and an NSE-1 and (evidently though they are not listed) the
> 1760, 2621,
> 2621XM, 2611 and 1720.  Solution is to turn off PXF (rate
> limiting of
> ICMP
> unreachables) using:  no ip icmp rate unreach
>  
> Lesson learned?  Read everything... :)
>  
> Bill
>  
>  
> 
> 	-----Original Message----- 
> 	From: William Pearch 
> 	Sent: Thu 1/16/2003 8:12 PM 
> 	To: William Pearch; cisco@xxxxxxxxxxxxxx 
> 	Cc: 
> 	Subject: Traceroute troubles
> 	
> 	
> 	Why does traceroute seem to have problems with the second check
> of a final
> hop?
> 	 
> 	RouterA-----RouterB
> 	 
> 	When trace from routerA loopback to routerB loopback, first one
> comes back
> fine, second is a * and third is fine.  Seems wierd - 500 pings
> all go
> swell.
> 	Then to top it off... RouterA trace to RouterA loopback0, first
> one comes
> back fine, second is a * and third is fine.  500 pings all go
> swell.
> 	 
> 	I've tried over ethernet, fast ethernet, serial (HDSL and frame
> relay).
> 	 
> 	Same behavior on my 2600's and 1700's.  All running 12.2.13T. 
> I
> wasn't
> able to find anything on the CCO this evening.
> 	 
> 	Thoughts?
> 	 
> 	Bill Pearch, Anchorage




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=62023&t=62023
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx