<div dir="ltr">Keep in mind that large flows can induce bursty packetloss.<div><br></div><div>For instance, a perfSonar network monitoring device will test bandwidth by shoving many gigabytes of max MTU null padded packets through the pipe to a remote perfSonar box. This will result in the whole stream being buffered and fed to a single core due to tuple hashing. Chances are good that your buffer won't flush fast enough and you'll start dropping packets. </div><div><br></div><div>Long story short. Know your traffic. See what netflow has to say.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 1:51 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"><span class="">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span>Let it run for a bit.  There is race condition somewhere that causes<br>
suricata to drop packets when its starting up and large buffers are<br>
enabled.  Or, at least there is on my config.<br>
<br>
Aside from that, try running a "top-talkers" report to see if is any<br>
traffic you can filter out.  Just dropping our local Netflix/Youtube<br>
caches doubled our capacity.<br>
<br>
- -Coop<br>
<span class=""><br>
On 12/9/2015 11:32 AM, Yasha Zislin wrote:<br>
> I use PF_RING.<br>
><br>
> Changing these net.core buffers actually made it worse. Packet loss is<br>
> instant with 30%.<br>
> These are what my defaults are:<br>
> net.core.wmem_default = 124928<br>
> net.core.rmem_default = 124928<br>
> net.core.netdev_max_backlog = 1000<br>
><br>
> I have 10 gig NIC as well. Not that busy pipe. About 1 million packets a<br>
> minute.<br>
<br>
<br>
</span><span class="">- --<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>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.17 (MingW32)<br>
<br>
</span>iQEcBAEBAgAGBQJWaIZLAAoJEKIFRYQsa8FWnhMH/Ag8+EPGSdtigG7eXED0K2hG<br>
h8ZyMn5GTWgz6cAS62EED8RS8ot6Q8FRBNrOf7Yd87jytdSMUN+FuzWRLheGP615<br>
944UuMm66oJgtMfINRTZTsEubnnS7NYVMexTBMzhU+Y7qbZo6qTupx1S7ULtidHC<br>
mvdBmWyf7IJex9ccGyBhwjDYJqMLkK0ThDkfJlMUN3fm5MhYyri94y9y2XI+aYtL<br>
CrteDmXDvOZ63mWGQdS+WDNv/0UNpkTSlGBV0mZs4KWRa3bSiAY2aheoMAnMjgyW<br>
RopmFif6dzHN8eAjfce+70R0KZFgtBMCKL/9VOIGFmCpv5JHe+zvY3ainZ3ePgk=<br>
=7DOe<br>
<div class="HOEnZb"><div class="h5">-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" rel="noreferrer" target="_blank">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/" rel="noreferrer" target="_blank">http://suricata-ids.org/support/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users" rel="noreferrer" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a><br>
Suricata User Conference November 4 & 5 in Barcelona: <a href="http://oisfevents.net" rel="noreferrer" target="_blank">http://oisfevents.net</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Brandon Lattin<div>Security Analyst<br><div>University of Minnesota - University Information Security<br>Office: 612-626-6672</div></div></div></div>
</div>