Refusing Pings on Core Routers??? A new trend?
eric at spaethco.com
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