[Oisf-users] Tuning Suricata (2.0beta1) -- no rules and lots of packet loss

Cooper F. Nelson cnelson at ucsd.edu
Wed Aug 14 20:47:31 UTC 2013

Hash: SHA1

If you are monitoring a 10gig interface and using 'worker' mode, its
critical you follow this guide exactly:

> https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/

And specifically, if a feature isn't set, don't set it.  AF_PACKET
doesn't set a buffer by default in this configuration as you can see by
checking the suricata.log file:

> 14/8/2013 -- 11:00:39 - <Info> - all 16 packet processing threads, 3 management threads initialized, engine started.
> 14/8/2013 -- 11:00:39 - <Info> - AF_PACKET RX Ring params: block_size=32768 block_nr=26215 frame_size=1584 frame_nr=524300
> 14/8/2013 -- 11:00:39 - <Info> - Using interface 'eth2' via socket 7

I think the issue is you don't want a buffer in mmap mode as it will
interfere with moving the packets directly into the RX Ring.  Basically,
forcing a buffer breaks the 'zero copy' model.

But again, as mentioned in all run modes there is a limit on the number
of packets per second any single thread can process.  This is especially
an issue with 'auto flow pinned mode' as flows will be pinned to a
single core, so a single large flow can peg a core and cause a backlog
and ultimately packet drops.

I'm not sure if there is a fix for this (or how big an issue it is as
properly sized box will drop less than 1% of packets).

Some ideas I've had (which may be way off base)

1.  I think the linux kernel is still sending packets for large flows to
the AF_PACKET RX Ring even after the stream limit has been reached and
streams are no longer tracked.  If flows could be truncated once the
stream depth limit is reached it should mitigate this issue in most cases.

2.  Allow a 'Ring emergency mode' where packets can be spooled to a
second buffer if any of the AF_PACKET queues fill up.  This could even
be a spool file, to avoid a OOM condition.

- -Coop

On 8/14/2013 11:43 AM, rmkml wrote:
> Hi Tritium and Cooper,
> Maybe it's related to recently speak on list for new dns preproc cause
> drop, I don't known if it possible to disable actually.
> Maybe back to v1.4.4 for comparing ?
> Regards
> @Rmkml

- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/


More information about the Oisf-users mailing list