The premiere source of truth powering network automation. Open and extensible, trusted by thousands.

NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.

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.

icmp_rate_limit.jpg

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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


Masood Ahmad Shah
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#


Dinger
May 27, 2008 at 4:58 p.m. UTC

I've often seen this (U.U.U), but never could figure out why.. thanks!


Nick
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?


stretch
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.


shachar
June 25, 2008 at 11:16 a.m. UTC

does the value of ICMP rate limit can be change ?


stretch
June 25, 2008 at 11:32 a.m. UTC

Yep, with the 'ip icmp rate-limit unreachable' command.


gemmsay
July 13, 2008 at 12:03 a.m. UTC

wow :) very enlightening. thanks for sharing :)


Syed Asif Raza
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.


shchiu
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!


Rajendra
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


rjo
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.


stretch
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.


rao
May 6, 2012 at 11:39 p.m. UTC

Awesome !!!!!


Danny
March 5, 2013 at 6:17 p.m. UTC

Dude this was awesome! excellent explanation.


Harini
May 15, 2013 at 11:34 a.m. UTC

Wow!!! very good article.


raj
December 28, 2013 at 3:18 a.m. UTC

thanks really really helpfull to understand behaviour of this feature.


Dom
September 19, 2014 at 6:06 a.m. UTC

Thanks :D


Julius
April 28, 2015 at 10:04 a.m. UTC

Great stuff, thanks for the info.


Man from best Korea
June 12, 2015 at 5:21 a.m. UTC

You saved my comrade. Thanks alot.

Comments have closed for this article due to its age.