Traceroute troubles [7:61247]---------- Thank You. [7:62023]
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:[EMAIL PROTECTED]] Sent: Monday, January 20, 2003 2:53 PM To: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > Subject: RE: Traceroute troubles [7:61247] > > > I agree this works, but still that doesn;t answers one > thingCisco > 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
RE: Traceroute troubles [7:61247]
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 thingCisco 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=61378&t=61247 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Traceroute troubles [7:61247]
I agree this works, but still that doesn;t answers one thingCisco 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=61317&t=61247 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Console speed [7:36155]
Confreg in ROMMON with a bootloader of 12.0 XE the highest speed you can go is only 9600!!! Thats my whole problem. > -Original Message- > From: Ranma [SMTP:[EMAIL PROTECTED]] > Sent: Thursday, February 21, 2002 9:26 PM > To: [EMAIL PROTECTED] > Subject: Re: Console speed [7:36155] > > Re-start the router > then BREAK it during it boot up and enter rommon>config > > it will ask you question one by one... > > choose the option of different console=speed here > > then reboot the machine again. > > > > ""NK Sat"" wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Hi guys, > > I am not able to change the console speed of my 7204 VXR at all.I > > wanted it at 115200 to do a xmodem But it just cannot beyond 9600 > > > > What am i missing here. > > > > > > r7#line con 0 > > r7(config-line)#speed 0 > > Failed to change line 0's speed > > > > > > Does 7204 VXR console cannot go beyond 9600 ? Please advise > > > > > > Thanks > > > > > > _ > > Send and receive Hotmail on your mobile device: http://mobile.msn.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=36161&t=36155 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
ARP Cache [7:12270]
Hi Everybody, I ran into a weird trouble the yesterday.. I am having a Cisco 3600 router with some 16 Class-C connected to the Fast Ethernet as secondary addresses. My host were not able to ping the router across the ethernet at all... I was seeing the ARP entry of my host on the router but not able to ping the host from the router and vice-versa across the ethernet..when i cleared the arp-cache everything is working...( Not sure when the trouble may come back) Can somebody tell 1) What is the size of the ARP-CACHE, where i can see it and how i can manipulate it. 2) If i have "n" hosts and "n" is the maximum hosts the Arp-cache can accomidate when "n+1" host try to get to a host it will send a brodcast and get the MAC and get itself into the ARP-Cache removing the oldest entry in the ARP right? Apparently this does NOT seem to be happening.. Is my understanding wrong or is this a weird cisco IOS stuff! which needs the regular upgrade Any help is greatly appreciated. Thanks Satish Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=12270&t=12270 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
