Dissecting a U.U.U ping response

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.

About the Author

Jeremy Stretch is a freelance networking consultant, instructor, and the maintainer of PacketLife.net. He currently lives in Fairfax, VA on the edge of the Washington, DC metro area. Although primarily an R&S guy, he likes to get into everything, and runs a free Cisco lab out of his basement for fun. You can contact him by email or follow him on Twitter.

Comments

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#

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

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?

Apparently the command 'show ip icmp rate-limit' wasn't introduced until 12.4(2)T, so check your IOS version.

does the value of ICMP rate limit can be change ?

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

wow :) very enlightening. thanks for sharing :)

Thanks for the great topic. It really helped me to understand what exactly happens when router does not have the path to the destination.

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!

I have got the responce as UUUU
Is it a different than what discussed above by Stretch? If it is different, then plz expalin

Leave a Comment


Register to comment as a member. You'll look cooler.

Optional; will not be displayed publicly or given out.

Only personal (e.g. blog, Twitter, or LinkedIn) and/or on-topic links, please.