Dissecting a U.U.U ping response
By stretch | Tuesday, May 27, 2008 at 9:20 a.m. UTC
Once every so often, in the course of troubleshooting, you'll encounter a somewhat odd response to a ping: U.U.U. Recall that the dot signifies that a response was not received before the request timed out, while the U indicates an ICMP unreachable message was received from a router somewhere along the path. But why do the responses alternate?
The answer to this question lies in how a router performs ICMP rate limiting. Cisco IOS will, by default, rate-limit ICMP replies to one every 500ms. We can view active ICMP rate-limiting with show ip icmp rate-limit
:
Router# show ip icmp rate-limit DF bit unreachables All other unreachables Interval (millisecond) 500 500 Interface # DF bit unreachables # All other unreachables --------- --------------------- ------------------------ FastEthernet0/0 0 0 ...
We must also realize that the default ping timeout on IOS is two seconds. Armed with this information, we can trace how the ping results were formed. Assume Router A is attempting to ping an unreachable subnet via Router B.
- Router A sends its first echo request, and Router B responds with an ICMP unreachable message. Router B cannot send another unreachable message for 500ms. Router A receives the unreachable message and reflects it on the console as a U.
- The second echo request is sent by Router A. This time, Router B doesn't respond with an ICMP unreachable message because the 500ms window has not passed yet.
- Router A waits for two seconds without receiving a response, then sends its third ICMP request. By now, the 500ms window on Router B has expired, so router B responds with a second ICMP unreachable message. Router B starts its 500ms timer again, and the console on router A now reflects U.U
- Router A sends its fourth echo request. Because Router B is waiting for its rate-limit window to expire again, it does not respond. Router A again waits two seconds without receiving an echo reply before marking another . on the console.
- The fifth echo request is answered with an ICMP unreachable message because the two-second delay on Router A again allows the 500ms window on Router B to expire, completing the U.U.U result observed on Router A's console.
The two response types will alternate indefinitely until the querying router stops sending pings. Note that this example assumes Router B hasn't responded to any other traffic with ICMP unreachable messages, which would skew its rate-limiting window and likely alter the results observed on Router A. Also keep in mind that other conditions, particularly load-balancing, can create the same effect, but the scenario discussed here is the most probable cause.
Posted in Tips and Tricks
Comments
May 27, 2008 at 3:00 p.m. UTC
If the B Router is Juniper then you will not get U.U.U because there is nothing like 500 ms ICMP rate limit..
jahil-test#ping 53.53.53.1
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 53.53.53.1, timeout is 2 seconds: UUUUU Success rate is 0 percent (0/5) jahil-test#
May 27, 2008 at 4:58 p.m. UTC
I've often seen this (U.U.U), but never could figure out why.. thanks!
June 9, 2008 at 2:14 p.m. UTC
Very interesting but that show command doesn't seem to work on a 7200 I just tried (12.2(25)S15). Is there an alternative?
June 9, 2008 at 3:24 p.m. UTC
Apparently the command 'show ip icmp rate-limit' wasn't introduced until 12.4(2)T, so check your IOS version.
June 25, 2008 at 11:16 a.m. UTC
does the value of ICMP rate limit can be change ?
June 25, 2008 at 11:32 a.m. UTC
Yep, with the 'ip icmp rate-limit unreachable' command.
July 13, 2008 at 12:03 a.m. UTC
wow :) very enlightening. thanks for sharing :)
August 14, 2008 at 11:21 a.m. UTC
Thanks for the great topic. It really helped me to understand what exactly happens when router does not have the path to the destination.
January 6, 2009 at 2:18 p.m. UTC
That's an excellent explanation of why I get that kind of odd responses. It does really help me a lot! But stretch, you have stated that it happens particularly in load sharing condition, could you also explain that as well? I have encountered this issue that I could not explain to the customer. Thank you!
July 19, 2009 at 7:21 a.m. UTC
I have got the responce as UUUU
Is it a different than what discussed above by Stretch? If it is different, then plz expalin
January 14, 2011 at 7:15 p.m. UTC
The explanation above is very good, it does not fixes my problem.
While it is good to know what is happening, I also need to know how to fix it.
I have 3 router in my network topology, I'm trying to ping router 3 interface 192.168.3.1, and this is what I get.
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds: U.U.U Success rate is 0 percent (0/5)
Now; if I may, how do I fix it?
Thank you.
January 15, 2011 at 4:13 a.m. UTC
@rjo: As explained in the article, this is simply default rate-limiting behavior. It isn't something that needs to be "fixed."
Still, if you feel the need to disable this behavior, you can do as indicated by the documentation referenced in the article with the command no ip icmp rate-limit unreachable
.
May 6, 2012 at 11:39 p.m. UTC
Awesome !!!!!
March 5, 2013 at 6:17 p.m. UTC
Dude this was awesome! excellent explanation.
May 15, 2013 at 11:34 a.m. UTC
Wow!!! very good article.
December 28, 2013 at 3:18 a.m. UTC
thanks really really helpfull to understand behaviour of this feature.
September 19, 2014 at 6:06 a.m. UTC
Thanks :D
April 28, 2015 at 10:04 a.m. UTC
Great stuff, thanks for the info.
June 12, 2015 at 5:21 a.m. UTC
You saved my comrade. Thanks alot.