ICMP Rate-Limit

Ever wonder why when you do a trace and the last hop shows timeouts?

trace1

.

This is due to a built-in Deniel-Of-Service protection mechanism, to limit the rate of transmitted ICMP packets out an Interface. The default value is one ICMP destination unreachable message per 500 milliseconds ( 1/2 second), this would be why 1 in 3 response from the destination appears as a timeout, since the destination router silently discards the second packet.

The following command allows you to change the interval at which ICMP unreachable messages are generated (1 packet every 100 ms):

R5#conf t
R5(config)#ip icmp  rate-limit  unreachable 100

The show and clear commands available, was only introduced in IOS 12.4(2).

clear ip icmp rate-limit
show ip icmp rate-limit

.

A trace route will then complete as you would expect:

trace2

Advertisements

7 thoughts on “ICMP Rate-Limit

  1. Can you illustrate more?
    I see that you said many things that in no relation, that it is to limit the ICMP out of the interface and then the router discards “input” the second ICMP, what is the relation?
    and I know that in Traceroute there is only ONE unreachable msg sent back from the final destination and all other msgs are “time expired”.

      1. I am not speaking about if the command works or not.
        but the mentioned points make no sense and actually no relation between what you already said and only just one unreachable msg during the whole Trace operation.
        the information is not accurate thats why I asked to illustrate more.

      2. You do not understand the difference between “time expired” and “unreachable”. The destination will receive three echos from the source, and respond with 3 “unreachables”. The last traceroute above proves that. “time expired” is only used by the intermediate routers.

        Understand, the following two steps are involved with a Traceroute:
        1- Manipulating the TTL in the IP header to find the routers in the path to the destination.
        >> The source initiating the trace will generate three ICMP echos towards the destination, starting with a TTL=1.
        >> Each router in the path decrements the IP TTL by 1 upon receipt of the packet.
        >> If a router in the path decrements the received packet’s TTL to 0, that router will discard the packet and generate an ICMP ‘time-exceeded’ message to indicate to the source that the packet expired in transit.
        >> Every time the source gets a ‘time-exceeded’ it will generate three new echos with the previous TTL incremented by 1.
        >> This cycle continues until the router receiving the ICMP packets matches the destination IP specified to one of its own.
        2- Getting some form of response from the destination to know if it was reached.
        >> When the three echos reach the destination, the reply will depend on the packet type used by the traceroute application of the source.
        >> If UDP was used (like from a cisco router), the three echos sent to the destination would be sent to incremented unused UDP Ports starting at UDP port 33434 for the first hop. When the final destination receives three packets sent to an
        unused local UDP port, the destination will respond with three ICMP port-unreachable message. Once the source receives the ICMP port-unreachable, it knows the destination was reached.
        >> If ICMP was used (like windows pc), the process is the same as before, but the destination will reply with an ICMP echo-reply.

        I believe the post is clear. The command rate-limit the response of the ICMP unreachables per time interval. The bigger the rate-limit value per packet the less ICMP unreachables will be sent, as the router will wait for the timer to reach zero before responding to the next. The lower the rate-limit value per packet, the more unreachable responses will be sent as less time is spend waiting.

        For additional reading, I would recommend the services chapter in Routing-Bits Handbook RS.

        HTH :)

  2. A quick follow up: I also read an article on Cisco Press and now I’m more clear and your article makes more sense. I think you should have included a little bit more background. Thanks anyway :)

Please leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s