Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...

  • From: Curtis Villamizar
  • Date: Fri Dec 20 15:06:07 1996

In message <>, David Miller 
> On Tue, 17 Dec 1996, Chris Caputo wrote:
> > There is considerable difference between forwarding a packet that happens
> > to contain ICMP data (destination not the router) and responding to a
> > packet that contains ICMP data (destination is the router).  In the
> > former, priority in a Cisco is the same for ICMP as it is for UDP or TCP,
> > since this part of the packet is not even being examined.  In the later,
> > priority is lower and can be ignored altogether. 
> > 
> > I treat ignored (link good, but no response received) ICMP echo requests
> > as an indicator that a router is too loaded.  If the router has been
> > pushed to the point of not being able to respond to an ICMP, how well is
> > it going to do when a bunch BGP updates occur?  (rhetorical)  Both are CPU
> > intensive operations. 
> Would someone please tell me just why icmp echos are "cpu intensive"?
> Yes, I know they're in software.  So what? A PC can respond to an 
> ethernet loaded with them with a trivial percentage of it's CPU cycles.
> This sounds to me a whole lot more like a solution to an imagined 
> problem, but I'm prepared to be convinced that responding to pings 
> actually takes a great enough percentage of CPU cycles to slow down 
> packet delivery.....
> Thanks,
> David
> ----------------------------------------------------------------------------
> 		It's *amazing* what one can accomplish when 
> 		    one doesn't know what one can't do!

You've obviously never seen a router taking 15-25 kpps out on an
interface change a major portion of the routing table to point
somewhere else due to a circuit glitch on that outbound interface.  In
earlier versions of some routers the whole router dies.  With no ICMP
rate limiting you'd need to generate 25 kpps of ICMP until routing
converged.  That could be a fair amount of work.

Some routers send ICMP to another processor that mainly handles the
routing protocols and doesn't forward very well.  Some routers keep it
on the same card and pass it up to an IP process and incur IPC
overhead rather than doing it directly.  These are both slower than
the primary forwarding path.

The NSS used to do ICMP generation on the forwarding cards just as
fast (or slow) as they forwarded packets, so it is possible.

- - - - - - - - - - - - - - - - -

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.