>>>>> "jn" == Jeremy Noetzelman <jnoetzel@cac.washington.edu> writes:
> Remember, netflow, sampled or not, is hard on the router CPU.
Good point. Also, routers are generally not optimized for originating
packets, so the mere task of sending out these accounting packets can
have a significant impact. I don't know what typical rates of data
traffic to (unsampled) NetFlow accounting traffic are - it will vary
widely depending on mouse/elephant traffic mix - but in the worst case
(think aggressive port scans or DOS attacks with small packets and
random addresses), accounting traffic could be similar to data traffic.
> So at higher line rates, if you attempt full unsampled netflow, your
> router will keel over from the load. Sampling was introduced to
> allow you to gather netflow data at line rates that are too high for
> unsampled netflow. A GSR can monitor full line rate OC3 just as
> easily as a VXR. It's just a matter of how much traffic before your
> box keels over.
> We initially didn't like the idea of sampling, as we use netflow for
> things that must be very accurate. However, after several
> discussions with Statistics PhDs, it's been statistically proven
> that sampled netflow is perfectly adequate for determining traffic
> patterns as well as accounting usage.
I'd be interested in that proof, because we use NetFlow for billing
(for "expensive" transatlantic bandwidth) so it could be useful to
convince our customers (in case we have to move to sampling in the
future :-).
> We were able to sample in excess of 8000 packets per second with the
> M10, but ymmv.
I just checked one of our border routers we run NetFlow accounting on.
This is a Cisco 7507 with various VIP2 boards. Its interface shift
between 3500 and 17500 pps right now, for a total of 39000 packets per
second. This works because each VIP2 performs NetFlow accounting and
exporting more or less autonomously. The busiest VIP2 runs at 55%
CPU, which is acceptable.
> Considering we will need to get netflow data for OC192 lines, full
> netflow is just not an option on the routers themselves. The new
> Foundry product I mentioned may also be of interest, we certainly
> like that concept.
I guess that given enough customer demand, NetFlow could be
implemented in ASICs or on network processors (for example Cisco
implements it for their PXF architecture, which is used in the new
7600 OSR and the 7200 NSE-1). It doesn't look trivial however, if
only because of the problems of getting the accounting data exported
and efficiently maintaining the potentially large cache.
But in practice, you'll never be able to guarantee reliable NetFlow
accounting at line rate, unless you make assumptions on "reasonable"
flow sizes, and those assumptions will typically be violated in the
situations I mentioned above (DOS/scans). So I think it's nice to
have a throttling mechanism that increases the sampling interval if
necessary to conserve resources. Ideally the sampling interval would
be equal to one under "normal" circumstances.
-- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/Computers hate being anthropomorphized.
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:42 EDT