RE: DOS attack tracing

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.