<div dir="ltr">I tried all of your recommendations and performance is worse.  Short of having the exact same server and single card there's nothing else I can match exactly.<div><br></div><div>ring-size=300000 exhausts memory and swap.  Even ring-size=100000 is taxing on the system and consumes 56GB ram.</div>
<div><br></div><div><div>Also updated ixgbe to latest version as recommended on the blog.  Not sure if this is connected but oddly it seems now I am reaching a limit of 32 CPUs/queues with unused cores at 100% idle.  I think there are some errors on the blog too with the ixgbe parameters and expectations of queues but that is besides the point.  (FdirPballoc is for hardware filters and not relevant here?)</div>
<div><br></div><div>I cannot explain the feeling of how old this is becoming especially when all others seem to have success.  I guess maybe the answer must be filtering out lots of traffic however the traffic profile is definitely less than the 1M to 1.5M pps mentioned in the blog.  (The blog server is less powerful too?)  </div>
<div><br></div><div>For now I will just be happy with dropping 10-40% and restarting the IDS daily, a half working IDS is better than no IDS :p</div><div><br></div><div>Thanks for the detail it is still helpful.  Better luck tomorrow !</div>
</div><div><br></div><div>--TC</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 1:47 PM, 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"><div class="im">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</div>If you are monitoring a 10gig interface and using 'worker' mode, its<br>
critical you follow this guide exactly:<br>
<br>
> <a href="https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/" target="_blank">https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/</a><br>
<br>
And specifically, if a feature isn't set, don't set it.  AF_PACKET<br>
doesn't set a buffer by default in this configuration as you can see by<br>
checking the suricata.log file:<br>
<br>
> 14/8/2013 -- 11:00:39 - <Info> - all 16 packet processing threads, 3 management threads initialized, engine started.<br>
> 14/8/2013 -- 11:00:39 - <Info> - AF_PACKET RX Ring params: block_size=32768 block_nr=26215 frame_size=1584 frame_nr=524300<br>
> 14/8/2013 -- 11:00:39 - <Info> - Using interface 'eth2' via socket 7<br>
<br>
I think the issue is you don't want a buffer in mmap mode as it will<br>
interfere with moving the packets directly into the RX Ring.  Basically,<br>
forcing a buffer breaks the 'zero copy' model.<br>
<br>
But again, as mentioned in all run modes there is a limit on the number<br>
of packets per second any single thread can process.  This is especially<br>
an issue with 'auto flow pinned mode' as flows will be pinned to a<br>
single core, so a single large flow can peg a core and cause a backlog<br>
and ultimately packet drops.<br>
<br>
I'm not sure if there is a fix for this (or how big an issue it is as<br>
properly sized box will drop less than 1% of packets).<br>
<br>
Some ideas I've had (which may be way off base)<br>
<br>
1.  I think the linux kernel is still sending packets for large flows to<br>
the AF_PACKET RX Ring even after the stream limit has been reached and<br>
streams are no longer tracked.  If flows could be truncated once the<br>
stream depth limit is reached it should mitigate this issue in most cases.<br>
<br>
2.  Allow a 'Ring emergency mode' where packets can be spooled to a<br>
second buffer if any of the AF_PACKET queues fill up.  This could even<br>
be a spool file, to avoid a OOM condition.<br>
<br>
- -Coop<br>
<div class="im"><br>
On 8/14/2013 11:43 AM, rmkml wrote:<br>
> Hi Tritium and Cooper,<br>
><br>
> Maybe it's related to recently speak on list for new dns preproc cause<br>
> drop, I don't known if it possible to disable actually.<br>
> Maybe back to v1.4.4 for comparing ?<br>
><br>
> Regards<br>
> @Rmkml<br>
><br>
<br>
<br>
</div><div class="im">- --<br>
Cooper Nelson<br>
Network Security Analyst<br>
UCSD ACT Security Team<br>
<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.edu</a> x41042<br>
</div><div class="im">-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.17 (MingW32)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
</div>iQEcBAEBAgAGBQJSC+zjAAoJEKIFRYQsa8FW+VoIALT+vbKujpH62oxw0uJ9YPM6<br>
ibUjt5Vw2homkD73GdqIP2G6MePU+STk1aMAijv2UdVTIGv/QsL1jpS3m4DuG3f+<br>
Iu6GUT+CeLIlUjrg9GE1tWtbDoLiuh1MX3BtvI7mvsW2sZHtx5OLdrAaXNbL6Ccy<br>
sValT5g/D1L6CHvT9lTZkccQO6dLojLOz+yIQFVqv0dKNpF3ij1WLGn2knisK9AT<br>
0mR8WXBDVOY34chx6YtHrYoYPOtFRQnN1TbtZoSi6rGKnj+5I8W5ed8+vllhn6pk<br>
sAZvgBaQifV6WVbev/6qnsLFgBZoBScFVZ0jlM4l47QuJin/orVhgg+MU3bgW2I=<br>
=OR37<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br></div>