nanog mailing list archives
Re: NAP/ISP Saturation WAS: Re: Exchanges that matter...
From: Curtis Villamizar <curtis () ans net>
Date: Fri, 20 Dec 1996 14:59:18 -0500
In message <Pine.BSI.3.91.961219152151.18639F-100000 () sparks net>, David Miller writes:
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. Curtis - - - - - - - - - - - - - - - - -
Current thread:
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter..., (continued)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... David Schwartz (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Alan Hannan (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... David Schwartz (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Brett L. Hawn (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Alan Hannan (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Brett L. Hawn (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Jon Zeeff (Dec 21)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Michael Dillon (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Curtis Villamizar (Dec 20)
- DoS Attacks Robert Laughlin (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Curtis Villamizar (Dec 20)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... dave o'leary (Dec 22)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Matt Ranney (Dec 17)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... alex (Dec 18)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Tony Li (Dec 19)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Nathan Stratton (Dec 19)
- Re: NAP/ISP Saturation WAS: Re: Exchanges that matter... Avi Freedman (Dec 19)