Hi Paolo, 2009/10/12 Paolo Lucente <pa...@pmacct.net>: >> Netflow table utilization of module 5 is 99% >> >> With "mls flow ip interface-source": >> Netflow table utilization of module 5 is 32% >> >> [ ... ] > > Something you might try is to enable sampling - given that you seem > not to be running some older IOS (where sampling rate is not properly > exported to the collector). So, on your 6500/7600: > > mls sampling packet-based <xxx> > ! > interface <xxx> > mls netflow sampling > ! > > Look specifically at the packet-based flow-sampling variant as the > other, time-based, is not working very well (IHMO). On the nfacctd > side of the things, you can do calculations on your own or you can > configure the daemon to renormalize data for you: > > nfacctd_renormalize: true
Flow sampling works fine, and seems also to deliver better (respectively more matching to the "real" traffic) data. I also figured out that i only get a full table when i'm activating netflow sampling on interfaces with "routed" traffic (e.g. interfaces with a transfer network configured and some networks routed over a remote router) like our carrier uplinks. When i activate netflow on interfaces with networks "directly" attached the netflow table keeps its low usage. >> splitting up the interfaces into some that generate netflow data via >> the cisco box and some that have netflow data generated using fibre >> taps and some BSD boxes using pmacct (maybe with PF_RING?) generating >> netflow data sending this data to the central nfacctd-box. Opinions on >> that? > > It's certainly an option; although on the specific example you mention, > i'm not sure PF_RING works outside a Linux environment. You would have > some "information loss", ie. input/output interfaces, due to the fact > NetFlow is not done on the device where traffic is passing through but > off-line. Also its applicability depends on the size of the environment > we are speaking about: I see it not very popular in large-scale scenarios > because it puts added burden onto you: you should not mind only to the, > say, scalability of the collector but also scalability of the probe, > architecture of the capturing framework as you touch your network, etc. I know there are some disadvantages of this setup, but in this case (a "historical" grown network) i have not really much options (besides to drop the 6500er-boxes into the dumpster and replace them with some devices that can really do Netflow, but i think our controlling... ;-). My preferred solution is also to generate the data at the point the traffic is processed, but the second-best solution is a passive tapping on the links that are not configurable on the cisco boxes without getting the generation of netflow data going down on the whole system... Bye, Chris _______________________________________________ pmacct-discussion mailing list http://www.pmacct.net/#mailinglists
