[Oisf-users] Suricata, 10k rules, 10Gbit/sec and lots of RAM

[Jason Holmes]

Hi,

I just wanted to give some feedback on the grouping code branch 
(dev-detect-grouping-v173).  I was running 3.0rc3 with:

detect-engine:
   - profile: custom
   - custom-values:
       toclient-src-groups: 200
       toclient-dst-groups: 200
       toclient-sp-groups: 200
       toclient-dp-groups: 300
       toserver-src-groups: 200
       toserver-dst-groups: 400
       toserver-sp-groups: 200
       toserver-dp-groups: 250

I tested dev-detect-grouping-v173 with:

detect:
   profile: custom
   custom-values:
     toclient-groups: 1000
     toserver-groups: 1000

(Actually, I had to hardcode this into src/detect-engine.c because the 
above syntax caused Suricata to crash when starting up.  I didn't dig 
into it enough to figure out why.)

The impetus for trying this was that adding additional rules to 3.0rc3 
caused packet loss to jump from <1% to ~25%.  The <1% on 3.0rc3 was 
using around 20,000 rules.  The 25% on 3.0rc3 was using around 30,000 rules.

My observations (using 30,000 rules):

1. Startup time is greatly reduced.  With the above settings, 
dev-detect-v173 starts up in about 2.5 minutes.  3.0rc3 took about 5.5 
minutes.

2. Performance is significantly improved.  Packet loss dropped from ~25% 
with 3.0rc3 to <1% with dev-detect-v173.  I'm also able to push more 
traffic through the box and maintain <1%.  It's hard to quantify exactly 
since this is production traffic and it spikes and dips, but I'd say 25% 
more traffic would be a conservative estimate in increased throughput.

I haven't had any stability issues that I wasn't already seeing in 
3.0rc3.  To me, the new grouping code branch seems like a fundamental 
improvement.

Thanks,

--
Jason Holmes

On 12/8/15 12:12 PM, Victor Julien wrote:
> On 04-12-15 18:03, Cooper F. Nelson wrote:
>> We are running the grouping code branch as well, ~7gbit traffic
>> and sampling port 80 flows.  Using groups of 1000.
>>
>> Performance so far is very good, currently running 27,568 ETPRO
>> signatures.
>
> How does it compare to your normal performance? Are you seeing
> differences in memory use, drop rate, etc?
>
> Thanks,
> Victor
>
>
>> On 12/3/2015 4:56 PM, Michal Purzynski wrote:
>>> I kind of feel responsible here and should answer this question.
>>
>>> The grouping code branch will make it to Suricata post 3.0. Give.
>>> The new release schedule, this should be quick.
>>
>>> I'm testing it on production traffic, more than 20gbit, two
>>> sensors (peak, but frequent, long and crazy. Average is between 3
>>> to 6gbit/sec).
>>
>>> In order to stress the code I run it with even more insane
>>> settings, like this
>>
>>> detect-engine: - profile: custom - custom-values:
>>> toclient-src-groups: 2000 toclient-dst-groups: 2000
>>> toclient-sp-groups: 2000 toclient-dp-groups: 3000
>>> toserver-src-groups: 2000 toserver-dst-groups: 4000
>>> toserver-sp-groups: 2000 toserver-dp-groups: 2500 -
>>> sgh-mpm-context: full - inspection-recursion-limit: 3000 -
>>> rule-reload: true
>>
>>> Note - do not try this at home. Or work. It kills kittens on 2.x
>>
>>> And it just works on the new branch that's yet to be merged :)
>>
>>> Note - I have over 16500 rules now.
>>
>>
>> _______________________________________________ Suricata IDS Users
>> mailing list: oisf-users at openinfosecfoundation.org Site:
>> http://suricata-ids.org | Support:
>> http://suricata-ids.org/support/ List:
>> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>>
> Suricata User Conference November 4 & 5 in Barcelona: http://oisfevents.net
>>
>