Argus vs SiLK

[Peter Van Epp]

On Mon, Apr 26, 2010 at 11:57:14PM -0700, John Gerth wrote:
> On 4/16/10 1:37 PM, John Kennedy wrote:
> > Is there someone that might have some experience with SiLK who could
> > provide a brief toe to toe comparison? 
> > 
>  The description below is based entirely on my experience and so is extremely anecdotal.
>  In order to be brief, I will also be frank and since I have far more practical
>  experience with Argus than SiLK, I'm undoubtedly not "fair and balanced".
> 
>  At our site, I started out with Cisco netflow but have been running argus
>  for about 5 years. For the last two years I've had contracts with
>  DHS organizations which were using SiLK tools so I've had to learn
>  a fair amount about the data although my actual experience with the
>  tools is limited.
> 
> SilK is described well at the CMU SEI site:
>   http://tools.netsa.cert.org/
> especially the tutorial
>   http://tools.netsa.cert.org/silk/analysis-handbook.pdf
> 

	Ah yes, I remember asking the CERT folks when this came out why they
didn't just use argus and looked at it but didn't see any advantage over argus.

<snip>

> uni vs. bi directionality can be somewhat of a religious issue
> in the flow community.  The big argument for uni-directional
> is that it's typical in large sites for traffic to be
> asymmetrically routed which makes it difficult, perhaps
> impossible, to have a sensor which can generate bi-directional
> records.  Furthermore, the typical bi-directional record has
> only one set of timestamps so there's an information loss
> compared to uni  However, argus 3 allows for separate sets of
> timestamps in each direction and also can generate uni-directional flows.
> 
<snip>

	While a "single sensor" may be a problem, argus has no difficulty with
asymmetric routing. My former site has both a commodity and CA*net link and
sometimes CA*net routes would be asymmetric due to BGP filter errors else 
where in REN space. Argus sensors on both links would see half the flow (and
that in turn would appear in the traffic reports as a unidirectional flow 
on each link). feeding both links in to ragator (or its 3.x eqivelent) would
produce a standard bidirecional flow although I was usually more interested
in the unidirectional flow as it indicated a problem :-). 

Peter Van Epp