Refusing Pings on Core Routers??? A new trend?

Eric Spaeth eric at
Fri Oct 20 04:37:31 UTC 2006

Rubens Kuhl Jr. wrote:
> If I recall well, Cisco GSRs impose low priority and/or limits for all
> ICMP traffic flowing thru the box, not just packets to/from router
> itself, and there's not a knob to adjust that.
There'd be no reason to limit ICMP globally -- for traffic through a 
router it's all IP; it doesn't really matter what the sub-protocol it 
is.  The forwarding process on the router is the same for all IP 
traffic, the simple breakdown being:

1) Take the source and destination IP and hash them to get an index value
2) Look up the destination prefix in the forwarding table (the CEF table 
on Cisco hardware)
3) Match the hashed index value in the CEF table with an outbound interface
4) Puke the packet out the destination interface.

All of these tasks are easily done in hardware ASICs because they are 
just doing simple hashing and bit comparisons.  If the destination 
prefix is already populated in the CEF table then there is no 
CPU/software involved in the process. The hashing is to keep traffic 
from source to destination on a single interface to reduce out-of-order 

To respond to ICMP, however, the packet needs to be routed up to the CPU 
to be handled.   There the packet must be inspected, and an entirely new 
packet must be created to be sent back.  While individually these 
responses take a negligible amount of CPU time, if you get enough 
devices flooding you with ICMP requests it starts to add up.  Since 
processor time is used for other semi-important tasks like maintaining 
BGP peering, it is often prudent to rate-limit ICMP handling by the router.

Overall this is a bigger issue with IOS devices; Juniper has a whole 
architecture built into JunOS to protect the CPU so they can often get 
by without end-user configuration to limit impact.


More information about the NANOG mailing list