<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 14, 2013 at 11:10 AM, Cooper F. Nelson <span dir="ltr"><<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
#Edit:  I wrote the following before checking your suricata.yaml.  Try<br>
#not setting the "buffer-size:" directive under the af-packet<br>
#configuration.  Setting that seems to cause packet drops in AF_PACKET<br>
#+ mmap mode.<br></blockquote><div><br></div><div>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)</div><div><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What does your traffic look like?  Do you have any high volume, single<br>
flows?  e.g. two hosts doing a sustained >500mbit transfer?<br>
<br></blockquote><div><br></div><div>Oh yeah.... I completely forgot about filtering out things like this, should help some as we definitely do have such flows.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One, use AF_PACKET + mmap mode and set a large ring buffer:<br>
<br>
>     ring-size: 524288<br>
<br>
I've found if you go too far above this suricata will generate errors<br>
about allocating memory (which it will eventually recover from).  I<br>
believe this is an issue with the linux kernel and not suricata.  Be<br>
careful not to run your box out of memory</blockquote><div> </div><div>Suricata would not start with such a setting.  I'll experiment with it after reboot/upgrade/recompile. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

As mentioned, you should also set large receive queues via sysctl.conf:<br>
<br>
> net.core.netdev_max_backlog = 10000000<br>
> net.core.rmem_default = 1073741824<br>
> net.core.rmem_max = 1073741824<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You should also set short timeouts (e.g. 5 seconds) and lower the stream<br>
depth.  I have mine set to 2mb.<br>
<br>
Another thing you can do is if you can identify the large, boring data<br>
flows (like backups or other bulk transfers) you can use BPF filters to<br>
prevent those packets from being processed.<br>
<br></blockquote><div><br></div><div>Good call, I'll experiment with it.</div><div><br></div><div>--TC</div><div><br></div></div></div></div>