<div dir="ltr">Hey Peter,<div><br></div><div>I tried as you asked.  Less than 15 minutes after I restarted Suricata I saw my first CPU hitting 100% and one host buffer dropping all packets.  Shortly after that the second CPU hit 100% and a second host buffer began dropping all packets.  I'm attaching the stats.log where you'll see at 10:31:11 the first host buffer (nt1.drop) starts to register dropped packets, then at 10:31:51 you'll see host buffer nt6.drop begin to register dropped packets.  At that point I issued the kill.</div><div><br></div><div>Steve</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 18, 2018 at 10:05 AM, Peter Manev <span dir="ltr"><<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Jan 17, 2018 at 1:29 PM, Steve Castellarin<br>
<<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
> Hey Pete,<br>
><br>
> Here's the YAML file from the last time I attempted to run 4.0.3 - with the<br>
> network information removed.  Let me know if you need anything else from our<br>
> configuration.  I'll also go to the redmine site to open a bug report.<br>
><br>
> Steve<br>
<br>
</span>Hi Steve,<br>
<br>
Can you try without -<br>
<br>
  midstream: true<br>
  asyn-oneside:true<br>
so<br>
  #midstream: true<br>
  #asyn-oneside:true<br>
<br>
and lower the "prealloc-session: 1000000" to 100 000 for example<br>
<br>
<br>
Thank you.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Jan 17, 2018 at 6:36 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>><br>
>> On Tue, Jan 16, 2018 at 4:12 PM, Steve Castellarin<br>
>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>> > Hey Peter, I didn't know if you had a chance to look at the stats log<br>
>> > and<br>
>> > configuration file I sent.  So far, running 3.1.1 with the updated<br>
>> > Napatech<br>
>> > drivers my system is running without any issues.<br>
>> ><br>
>><br>
>> The toughest part of the troubleshooting is that i dont have the set<br>
>> up to reproduce this.<br>
>> I didn't see anything that could lead me to definitive conclusion from<br>
>> the stats log.<br>
>> Can you please open a bug report on our redmine with the details form<br>
>> this mialthread?<br>
>><br>
>> Would it be possible to share the suricata.yaml (privately if you<br>
>> would like works too; remove all networks)?<br>
>><br>
>> Thank you<br>
>><br>
>> > On Thu, Jan 11, 2018 at 12:54 PM, Steve Castellarin<br>
>> > <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Here is the zipped stats.log.  I restarted the Napatech drivers before<br>
>> >> running Suricata 4.0.3 to clear out any previous drop counters, etc.<br>
>> >><br>
>> >> The first time I saw a packet drop was at the 12:20:51 mark, and you'll<br>
>> >> see "nt12.drop" increment.  During this time one of the CPUs acting as<br>
>> >> a<br>
>> >> "worker" was at 100%.  But these drops recovered at the 12:20:58 mark,<br>
>> >> where<br>
>> >> "nt12.drop" stays constant at 13803.  The big issue triggered at the<br>
>> >> 12:27:05 mark in the file - where one worker CPU was stuck at 100%<br>
>> >> followed<br>
>> >> by packet drops in host buffer "nt3.drop".  Then came a second CPU at<br>
>> >> 100%<br>
>> >> (another "worker" CPU) and packet drops in buffer "nt2.drop" at<br>
>> >> 12:27:33.  I<br>
>> >> finally killed Suricata just before 12:27:54, where you see all host<br>
>> >> buffers<br>
>> >> beginning to drop packets.<br>
>> >><br>
>> >> I'm also including the output from the "suricata --dump-config"<br>
>> >> command.<br>
>> >><br>
>> >> On Thu, Jan 11, 2018 at 11:40 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >> wrote:<br>
>> >>><br>
>> >>> On Thu, Jan 11, 2018 at 8:02 AM, Steve Castellarin<br>
>> >>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>> >>> > Peter, yes that is correct.  I worked for almost a couple weeks with<br>
>> >>> > Napatech support and they believed the Napatech setup (ntservice.ini<br>
>> >>> > and<br>
>> >>> > custom NTPL script) are working as they should.<br>
>> >>> ><br>
>> >>><br>
>> >>> Ok.<br>
>> >>><br>
>> >>> One major difference between Suricata 3.x and 4.0.x in terms of<br>
>> >>> Napatech is that they did update the code, some fixes and updated the<br>
>> >>> counters.<br>
>> >>> There were a bunch of upgrades in Suricata too.<br>
>> >>> Is it possible to send over a stats.log - when the issue starts<br>
>> >>> occuring?<br>
>> >>><br>
>> >>><br>
>> >>> > On Thu, Jan 11, 2018 at 9:52 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >>> > wrote:<br>
>> >>> >><br>
>> >>> >> I<br>
>> >>> >><br>
>> >>> >> On 11 Jan 2018, at 07:19, Steve Castellarin<br>
>> >>> >> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>><br>
>> >>> >> wrote:<br>
>> >>> >><br>
>> >>> >> After my last email yesterday I decided to go back to our 3.1.1<br>
>> >>> >> install of<br>
>> >>> >> Suricata, with<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> the upgraded Napatech version.  Since then I've seen no packets<br>
>> >>> >> dropped<br>
>> >>> >> with sustained bandwidth of between 1 and 1.7Gbps.  So I'm not sure<br>
>> >>> >> what is<br>
>> >>> >> going on with my configuration/setup of Suricata 4.0.3.<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> So the only thing that you changed is the upgrade of the Napatech<br>
>> >>> >> drivers<br>
>> >>> >> ?<br>
>> >>> >> The Suricata config stayed the same -  you just upgraded to 4.0.3<br>
>> >>> >> (from<br>
>> >>> >> 3.1.1) and the observed effect was - after a while all (or most)<br>
>> >>> >> cpus<br>
>> >>> >> get<br>
>> >>> >> pegged at 100% - is that correct ?<br>
>> >>> >><br>
>> >>> >><br>
>> >>> >> On Wed, Jan 10, 2018 at 4:46 PM, Steve Castellarin<br>
>> >>> >> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>> >>> >>><br>
>> >>> >>> Hey Peter, no there is no error messages.<br>
>> >>> >>><br>
>> >>> >>> On Jan 10, 2018 4:37 PM, "Peter Manev" <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>> >>> >>> wrote:<br>
>> >>> >>><br>
>> >>> >>> On Wed, Jan 10, 2018 at 11:29 AM, Steve Castellarin<br>
>> >>> >>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>> >>> >>> > Hey Peter,<br>
>> >>> >>><br>
>> >>> >>> Are there any errors msgs in suricata.log when that happens ?<br>
>> >>> >>><br>
>> >>> >>> Thank you<br>
>> >>> >>><br>
>> >>> >>><br>
>> >>> >>><br>
>> >>> >>> --<br>
>> >>> >>> Regards,<br>
>> >>> >>> Peter Manev<br>
>> >>> >>><br>
>> >>> >>><br>
>> >>> >><br>
>> >>> ><br>
>> >>><br>
>> >>><br>
>> >>><br>
>> >>> --<br>
>> >>> Regards,<br>
>> >>> Peter Manev<br>
>> >><br>
>> >><br>
>> ><br>
>><br>
>><br>
>><br>
>> --<br>
>> Regards,<br>
>> Peter Manev<br>
><br>
><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>