I've got it up on 3 7206s as global options (meaning it is automatically introduced to all interfaces) and it dropped my CPU by 3 points. On Wed, 19 Aug 1998, Alex Bligh wrote: :Steve, : :> I too have a similar setup for my network since we as well :> run an Efnet irc server, however, CAR really won't do much if :> you set it up inside your own network. The smurf will still enter :> and saturate your pipes. The best thing to do is to have your upstreams :> setup rate-limits on their side of your pipes so the feed coming into your :> router is limited before it even hits your router. :> :> Here is a question though, what kind of CPU drain does rate-limiting cause :> on the CPU of the routers running it? I flipped through CCO and couldn't find :> any information regarding this... : :My limited experience is that if you run CEF on the interface concerned, :life is bearable. If you don't, it isn't. If you run < 11.1.17?? CA :where fast discards and routes to null0 were introduced, life is :disastrous. : :Alex Bligh :GX Networks (formerly Xara Networks) : :> :> :> Alex Bligh wrote: :> :> > > servers, one for the outside world and one for our customers only. The :> > > public server will be connected via a T1 to a smurf tracing friendly :> > > transit provider for external connectivity. This T1 will be used for this :> > :> > OK, tell me where this falls down. Set up two IP addresses for your :> > IRC server on the same machine. On the router upstream from the machine, :> > allow only your customers to connect to one IP address, and anyone else :> > to connect to the other IP. Now go to your border routers, enable CEF :> > and configure something like: :> > :> > ! impose limits :> > access-list 100 permit ip any host public-irc.my.net :> > access-list 100 permit ip any host public-irc.my.net :> > access-list 101 deny ip any host private-irc.my.net :> > ! i/f config for borders :> > interface myinterface :> > ip access-group 101 in :> > rate-limit input access-group 102 512000 512000 512000 conform-action transmit exceed-action drop :> > :> > Effectively this means that if your public IP gets smurfed, it's b/w :> > usage internally on your network is limited. If your private IP gets :> > smurfed, it all gets dropped (thinking about it if you made exceptions :> > for IRC peering you could do the whole thing on one IP if your customers :> > never use border router i/fs). :> > :> > If you are paying per bit, you'll still pay for smurfs, but they'll have :> > to be 45Mb/s in size to cause any real damage. You'll probably find BGP :> > flapping up and down as your T1 saturates is more of a problem. :> > :> > -- :> > Alex Bligh :> > GX Networks (formerly Xara Networks) :> > :> > :> :> -- :> \\|// :> -(@ @)- :> ==========================oOO==(_)==OOo================================= :> Steven Nash uin: 9021398 :> Cisco Certified Design Specialist em: snash@lightning.net :> Network Engineer :> Lightning Internet Services LLC :> http://www.lightning.net :> -=+===================================================================+- :> :> :> : : -- Regards, Jason A. Lixfeld Network Engineer, iDirect Network Operations --------------------------------------------------------------------- TUCOWS Interactive Ltd. o/a | "A Different Kind of Internet Company" Internet Direct Canada Inc. | "FREE BANDWIDTH for Toronto Area IAPs" 5415 Dundas Street West | http://www.torontointernetxchange.net Suite 301, Toronto Ontario | (416) 236-5806 (T) M9B-1B5 CANADA | (416) 236-5804 (F) --------------------------------------------------------------------- jlixfeld@idirect.ca | jlixfeld@torontointernetxchange.net ---------------------------------------------------------------------