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: [EMAIL PROTECTED] > 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:[EMAIL PROTECTED]] > Sent: Friday, January 17, 2003 1:13 AM > To: [EMAIL PROTECTED] > 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; [EMAIL PROTECTED] > 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=61391&t=61247 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
