Argus 3.0.6 and dnaclusters

[Craig Merchant]

The Snort/Argus sensors that we're deploying aren't even in production yet, so I can happily help out with any testing that needs doing.  I'm not sure what our total throughput is, but our core switch generates something like 16 GB of netflow v5 events per hour.

We've got silicom fiber cards and a 32 core machine.  We're using redBorder (http://www.redborder.net) for managing Snort.  Their solution runs CentOS 6.2.

Let me know how I can help.

Craig

-----Original Message-----
From: Carter Bullard [mailto:carter at qosient.com] 
Sent: Thursday, December 13, 2012 3:36 PM
To: Chris Wakelin
Cc: Craig Merchant; Argus (argus-info at lists.andrew.cmu.edu)
Subject: Re: [ARGUS] Argus 3.0.6 and dnaclusters

Hey Chris,
argus should be getting its packets using the routine ArgusGetPacket(), reading
packets from a " notselectable " interface, which starts on line 3823 in ArgusSource.c.

So, argus should try to read 4 packets, using pcap_next_ex(), if its there, 
pcap_dispatch() it its not, and if we don't get any packets (pkts == 0), then
we're suppose to call nanosleep(), for 25 mSecs,  on line 3820.  

Interesting that it never hits this call ?

Carter


On Dec 13, 2012, at 5:37 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:

> Yes it's a bug in DNA. I can't remember seeing a commit that claimed to
> fix it; the last I saw, I think on the topic was the developer's reply to
> 
> http://listgateway.unipi.it/pipermail/ntop-misc/2012-September/003279.html
> 
> (and IPv6 is fine now BTW :-) )
> 
> As far as I remember, for some reason Bro IDS manages to use select()
> without hitting the problem, I think, perhaps by adding empty select()
> calls with a timeout:
> 
> From Bro's IOSource.cc:
> 
>>        if ( all_idle )
>>                {
>>                // Interesting: when all sources are dry, simply sleeping a
>>                // bit *without* watching for any fd becoming ready may
>>                // decrease CPU load. I guess that's because it allows
>>                // the kernel's packet buffers to fill. - Robin
>>                timeout.tv_sec = 0;
>>                timeout.tv_usec = 20; // SELECT_TIMEOUT;
>>                select(0, 0, 0, 0, &timeout);
>>                }
> 
> I had a go at doing that in ARGUS but it made no difference (perhaps I
> put it in the wrong place!).
> 
> I'm happy to try things out on the test server, now I've updated
> everything (I'm using tcpreplay of a 10GB pcap over a 1Gb link from
> another machine using Intel e1000e cards and the time-limited DNA demo
> licence, so I can only test for 5 mins at a time).
> 
> Best Wishes,
> Chris
> 
> On 13/12/12 22:11, Carter Bullard wrote:
>> If I remember, the 100% CPU was a bug in the DNA code itself?
>> Was there a resolution to that?
>> If you would be a guinea pig, we can play around with it?
>> 
>> Carter 
>> 
>> 
>> On Dec 13, 2012, at 4:30 PM, Chris Wakelin <c.d.wakelin at reading.ac.uk> wrote:
>> 
>>> I've just tried 3.0.7.2 with latest PF_RING svn (post v5.5.1) and DNA
>>> clusters on a test machine. It looks like we do still need the name
>>> change (added "dna" to the list of interfaces that includes "dag" and
>>> "napa") and it still uses 100% of CPU, but otherwise appears to work.
>>> 
>>> Best Wishes,
>>> Chris
> 
> -- 
> --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+-
> Christopher Wakelin,                           c.d.wakelin at reading.ac.uk
> IT Services Centre, The University of Reading,  Tel: +44 (0)118 378 8439
> Whiteknights, Reading, RG6 2AF, UK              Fax: +44 (0)118 975 3094
>