<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>I use PF_RING.<div><br></div><div>Changing these net.core buffers actually made it worse. Packet loss is instant with 30%.</div><div>These are what my defaults are:</div><div><div>net.core.wmem_default = 124928</div><div>net.core.rmem_default = 124928</div><div>net.core.netdev_max_backlog = 1000</div><div><br></div><div>I have 10 gig NIC as well. Not that busy pipe. About 1 million packets a minute.</div><br><div>> Subject: Re: [Oisf-users] packet loss troubleshooting<br>> To: coolyasha@hotmail.com; oisf-users@lists.openinfosecfoundation.org<br>> From: cnelson@ucsd.edu<br>> Date: Wed, 9 Dec 2015 09:03:33 -0800<br>> <br>> -----BEGIN PGP SIGNED MESSAGE-----<br>> Hash: SHA1<br>> <br>> I use AF_PACKET + mmap mode, as described here:<br>> <br>> > https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/<br>> <br>> This is my config for a 16 core server. Using af-packet mode and large<br>> buffers is the best way to mitigate packet drops in my experience.<br>> <br>> > af-packet:<br>> > - interface: eth2<br>> > threads: 16<br>> > cluster-id: 99<br>> > cluster-type: cluster_flow<br>> > defrag: yes<br>> > use-mmap: yes<br>> > ring-size: 500000<br>> > use-emergency-flush: yes<br>> > buffer-size: 1048576<br>> > checksum-checks: kernel<br>> <br>> To answer your question, you can drop packets anywhere. I believe if<br>> you see kernel drops that means you could be losing packets from the NIC<br>> - -> kernel or from the kernel -> suricata. Increasing the sysctl<br>> parameters mitigates the former. Increasing suricata's buffers<br>> mitigates the latter.<br>> <br>> Here is my config for a heavily utilized 10Gbit tap:<br>> <br>> > net.core.netdev_max_backlog = 8000000<br>> > net.core.rmem_default = 1073741824<br>> > net.core.rmem_max = 1073741824<br>> <br>> Make sure you make them permanent with 'sysctl -p' if you change them.<br>> <br>> - -Coop<br>> <br>> On 12/9/2015 5:36 AM, Yasha Zislin wrote:<br>> > I am at about 10% now. So this is not good.<br>> > So whenever I see capture.kernel_drops this is always OS or NIC problem?<br>> > Suricata itself has nothing to do with it, right?<br>> > I guess once I start seeing kernel drops, reassembly gaps start to<br>> > increase. Is that correct as well?<br>> > <br>> > I am not an expert on net.core.* buffers. Can you advise on which ones i<br>> > need to increase or how to find out which ones I need to increase?<br>> > <br>> > Thank you.<br>> <br>> <br>> - -- <br>> Cooper Nelson<br>> Network Security Analyst<br>> UCSD ACT Security Team<br>> cnelson@ucsd.edu x41042<br>> -----BEGIN PGP SIGNATURE-----<br>> Version: GnuPG v2.0.17 (MingW32)<br>> <br>> iQEcBAEBAgAGBQJWaF7lAAoJEKIFRYQsa8FWwbcH/2fBw4xfEM+etnn77y+Hqc6c<br>> PEHtZarvr4HZRQlnZ2NICt9seCfw60sEOIeduiv7nOOAjw4nU/B/xndeyj9b+Ls4<br>> 02+GUh9q4M4Sh0VV0KhMI/eaYMHMnBpjDOkZPzRBpcjcua/KHQEZFe6tCA5v7KWT<br>> qiFYSoxDtmm+jUETBtt07rWX+WM3Bdp8M4MnCT1rA6zqIUBqqjiylFisBWcAJjuN<br>> vCd6jD/XhcTHUSjrAkz5F9p+59isztip0H0XsO91JsTTCka/1+5mG0nIUpaRR/3c<br>> DTclbxfCz3joJ1DLFSUpDmr/R09TTkgAIKBSh3NHrdEhEPmbGJywAzqGpRoLpfE=<br>> =o07w<br>> -----END PGP SIGNATURE-----<br></div></div> </div></body>
</html>