Hi, This is also a good one www.netflowanalyzer.com
On Nov 24, 2007 8:45 PM, Charles Spurgeon <[EMAIL PROTECTED]> wrote: > On Fri, Nov 23, 2007 at 10:07:26AM +0100, Gert Doering wrote: > > Hi, > > > > On Fri, Nov 23, 2007 at 11:14:16AM +0300, Rivo Tahina RAZAFINDRATSIFA wrote: > > > Thanks to all who answered to this question, we are now testing some > > > of these, I would like to know the additional cpu charge due to the > > > use of netflow on the cisco box. > > > > This very much depends on the traffic characteristic (high number of > > short-lived flows vs. long-lived high-volume flows, etc.) and the type of > > box you have (software-forwarding vs. MLS based, vs. PXF vs. ...). > > > > On 7600s, the actual flow collection is done in the hardware ASICs, and > > doesn't cause any load - but the actual flow *export* can cause notable > > load (>30%) if there is a high number of flows on the box, like "2 Gbit/s > > of short-lived HTTP flows" or "single-flow DNS queries" or such. > > > > On software-forwarding platforms, like the 7200, my gut feeling is "add 10% > > CPU load for netflow". But that *will* vary according to traffic mix. > > > > We see the same thing. Worst case in our experience for Sup720B and > BXL netflow-induced SP CPU load is caused by short flows, typically > some sort of address scanning attack. This can be simulated in the lab > by using something like "stream.c" which randomizes the source addr > and ports, causing each packet to look like a new flow. You can see > the SP CPU load with "remote command switch sho proc". > > The RP CPU typically doesn't get involved in generating a lot of > netflow traffic since the only thing that the RP sees are packets that > are punted to software switching paths. However, the RP is also doing > the netflow export and that has been seen to cause RP CPU load > increases of approx 30 percent or so during scanning attacks, etc. > > Tests in the lab show that the SP CPU rate appears to be capped at > pprox 40 percent when running full netflow and hitting the box with > stream.c, presumably due to the limit on the amount of hardware tcam > space available to hold flow data. > > The last time we got a "tcam full" message on a production box a month > or so ago (apparently another scanning attack from a compromised host) > the SP CPU was showing approx 40 percent added SP CPU load on top of > the existing baseline of about 35 percent. > > -Charles > > Charles E. Spurgeon / UTnet > UT Austin ITS / Networking > [EMAIL PROTECTED] / 512.475.9265 > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > -- Raymond Macharia _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
