[ARGUS] PAPER: Building a Better Netflow

[Peter Van Epp]

	Hmmm, someone modifying their hammer to pound screws in more 
efficiently rather than buying a screw driver. The correct answer here is 
leave the router to route and install a network tap and something appropriate
(argus, netramet, Coral Reef (nee OCXmon), undoubtably more) to monitor the 
network traffic while not interfering (or being able to interfere in the case
of a fault) with the operation of the network. Then you don't have to trade off 
operation of the network for data collection (on the assumption that a network 
that is operating but not collecting data is more useful than one collecting 
all the data but not operating ...). 

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada

On Wed, Aug 04, 2004 at 02:08:42PM -0500, eric wrote:
> Some of you might be interested in reading this:
> 
> ``Network operators need to determine the composition of the traffic
> mix on links when looking for dominant applications, users, or
> estimating traffic matrices. Cisco's NetFlow has evolved into a
> solution that satisfies this need by reporting flow records that
> summarize a sample of the traffic traversing the link. But sampled
  NetFlow has shortcomings that hinder the collection and analysis of
> traffic data. First, during flooding attacks router memory and
> network bandwidth consumed by flow records can increase beyond what
> is available; second, selecting the right static sampling rate is
> difficult because no single rate gives the right tradeoff of memory
> use versus accuracy for all traffic mixes; third, the heuristics
> routers use to decide when a flow is reported are a poor match to
> most applications that work with time bins; finally, it is
> impossible to estimate without bias the number of active flows for
> aggregates with non-TCP traffic.''
> 
> <http://www.caida.org/outreach/papers/2004/tr-2004-03/tr-2004-03.pdf>