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

[Tritium Cat]

On Wed, Aug 14, 2013 at 11:10 AM, Cooper F. Nelson <cnelson at ucsd.edu> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> #Edit:  I wrote the following before checking your suricata.yaml.  Try
> #not setting the "buffer-size:" directive under the af-packet
> #configuration.  Setting that seems to cause packet drops in AF_PACKET
> #+ mmap mode.
>

I seemed to have hosed the queues on the intel cards when reloading ixgbe
so I'll try your suggestions after a reboot.  (only seeing traffic on one
queue)



> What does your traffic look like?  Do you have any high volume, single
> flows?  e.g. two hosts doing a sustained >500mbit transfer?
>
>
Oh yeah.... I completely forgot about filtering out things like this,
should help some as we definitely do have such flows.



> One, use AF_PACKET + mmap mode and set a large ring buffer:
>
> >     ring-size: 524288
>
> I've found if you go too far above this suricata will generate errors
> about allocating memory (which it will eventually recover from).  I
> believe this is an issue with the linux kernel and not suricata.  Be
> careful not to run your box out of memory


Suricata would not start with such a setting.  I'll experiment with it
after reboot/upgrade/recompile.


> As mentioned, you should also set large receive queues via sysctl.conf:
>
> > net.core.netdev_max_backlog = 10000000
> > net.core.rmem_default = 1073741824
> > net.core.rmem_max = 1073741824
>

I had the rmem settings at half of those values.  Seem to recall anything
higher overflowing to negative values.. guess not, just tried it and they
are OK.

By the way, is there a way to profile how well these types of settings are
performing ?  (e.g. what is the current rmem utilization ?)  I was thinking
SNMP might be a great help but I've not spent any time on it.


You should also set short timeouts (e.g. 5 seconds) and lower the stream
> depth.  I have mine set to 2mb.
>
> Another thing you can do is if you can identify the large, boring data
> flows (like backups or other bulk transfers) you can use BPF filters to
> prevent those packets from being processed.
>
>
Good call, I'll experiment with it.

--TC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20130814/b2682037/attachment-0002.html>