Right... I did mention that further down in my message. And yeah - almost impossible to get much done when the CPU is pegged. I remember a DOS attack demo where they used 7200s for the examples - almost wanted to yell out "try pegging the CPU with lots of traffic and THEN try to identify / null0 the destination or source". That's the problem in our case. One of our downstream customers got the attack. Once we disconnected them, everything became fine. I tried pretty much everything under our control to divert the traffic, including ingress acl to block all incoming traffic to their subnets. But every time I turn
the downstream ISP back on, our router was dead. We got a 7206VXR and 100M Ethernet to the primary upstream. I think that the lesson is _always_ use a router powerful enough to handle all ingress traffic at wire rate. Without access to the router, there is nothing you can do. So we are going to switch out the router. Richard
richard@o-matrix.org (Richard) wrote:
Ethernet to the primary upstream. I think that the lesson is _always_ use a router powerful enough to handle all ingress traffic at wire rate. Without access to the router, there is nothing you can do. So we are going to switch out the router.
If you are mostly concerned about not being able to use the router console during attacks, you may change the CPU scheduling a bit. A brief "scheduler allocate 60000 2000" has helped me a lot there. The box stays manageable. This does of course not help you with the router "going dead" in regard to packet forwarding... Yours, Elmi. -- "Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren." (PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>) --------------------------------------------------------------[ ELMI-RIPE ]---
participants (2)
-
Elmar K. Bins
-
Richard