[nsp] NetFlow and DoS attacks - tuning

[Nathan Patrick]

I've found "show ip cache flow" to be extremely useful in diagnosing DoS 
attacks.

Given the quantity of flow data that we archive, flow-tools searches 
take quite some time. It's often faster to simply hop on the router and 
try "show ip cache flow | inc K" to find IPs sourcing large amounts of 
traffic, or taking a visual look at "show ip cache flow" for random 
source IPs and their ingress interface. "show ip cache flow | inc 
<attacked IP>" is also very useful, as it lets you know what's hitting a 
destination. More advanced regexps can give you some interesting data.

As for tuning, we set our inactive timeout to 300 seconds and active 
timeout to 1 minute. The inactive timeout gets flows out of the cache 
quickly, while the active timeout cuts up long running flows (news 
peers, etc.) for graphing and some other applications. Other than that, 
we've found the defaults to work well on NPE-400s as well as RSP4s. Note 
that these parameters are not intended to reduce router load, but rather 
help other applications.

-Nathan

Charles Sprickman wrote:

>Hi,
>
>I'm very new to netflow and flow-tools, but I had to use them tonight to
>try and figure out what was being hit and where from (thanks elr at panix!).
>
>After we dug up what we wanted, we started wondering about what kind of
>impact logging all the flows was having on the router (a vxr w/npe-300),
>as it was falling down under a 20,000 pps hit at a 384K SDSL customer
>behind it.
>
>There appear to be some tunables for flow export:
>
>router.bway.net(config)#ip flow-cache ?
>  entries             Specify the number of entries in the flow cache
>  feature-accelerate  Enable flow based feature acceleration
>  timeout             Specify flow cache timeout parameters
>
>But I'm not really sure what I should be setting these to.  I want some
>data during an attack, as it seems flow-tools is almost mandatory for
>figuring out what is being hit when the traffic doesn't exit the router to
>a LAN segment, but I also don't want the router to sacrifice itself in the
>process.
>
>Any pointers?  Any real-world experience with tuning this?
>
>Thanks,
>
>Charles
>
>--
>Charles Sprickman
>spork at inch.com
>
>_______________________________________________
>cisco-nsp mailing list  cisco-nsp at puck.nether.net
>https://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>  
>