[c-nsp] [?? Probable Spam] Re: netflow

[Charles Spurgeon]

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
c.spurgeon at its.utexas.edu / 512.475.9265