Dissecting a U.U.U ping response

Posted by stretch in Networking on Tuesday, 27 May 2008 at 9:20 a.m. GMT

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 timeline

  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.

Masood Ahmad Shah commented on 27 May 2008 at 3:00 p.m.

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 commented on 27 May 2008 at 4:58 p.m.

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

Nick commented on 9 Jun 2008 at 2:14 p.m.

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 commented on 9 Jun 2008 at 3:24 p.m.

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

shachar commented on 25 Jun 2008 at 11:16 a.m.

does the value of ICMP rate limit can be change ?

stretch commented on 25 Jun 2008 at 11:32 a.m.

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

gemmsay commented on 13 Jul 2008 at 12:03 a.m.

wow :) very enlightening. thanks for sharing :)

Syed Asif Raza commented on 14 Aug 2008 at 11:21 a.m.

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

Leave a comment

(optional) (will not be published)
(optional)