<div dir="ltr">Here is the zipped stats.log.  I restarted the Napatech drivers before running Suricata 4.0.3 to clear out any previous drop counters, etc.  <div><br></div><div>The first time I saw a packet drop was at the 12:20:51 mark, and you'll see "nt12.drop" increment.  During this time one of the CPUs acting as a "worker" was at 100%.  But these drops recovered at the 12:20:58 mark, where "nt12.drop" stays constant at 13803.  The big issue triggered at the 12:27:05 mark in the file - where one worker CPU was stuck at 100% followed by packet drops in host buffer "nt3.drop".  Then came a second CPU at 100% (another "worker" CPU) and packet drops in buffer "nt2.drop" at 12:27:33.  I finally killed Suricata just before 12:27:54, where you see all host buffers beginning to drop packets.</div><div><br></div><div>I'm also including the output from the "suricata --dump-config" command.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 11, 2018 at 11:40 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 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 and<br>
> custom NTPL script) are working as they should.<br>
><br>
<br>
</span>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 occuring?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> On Thu, Jan 11, 2018 at 9:52 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>><br>
>> I<br>
>><br>
>> On 11 Jan 2018, at 07:19, Steve Castellarin <<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 install of<br>
>> Suricata, with<br>
>><br>
>><br>
>> the upgraded Napatech version.  Since then I've seen no packets dropped<br>
>> with sustained bandwidth of between 1 and 1.7Gbps.  So I'm not sure 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 drivers<br>
>> ?<br>
>> The Suricata config stayed the same -  you just upgraded to 4.0.3 (from<br>
>> 3.1.1) and the observed effect was - after a while all (or most) cpus 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>> 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>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Regards,<br>
Peter Manev<br>
</font></span></blockquote></div><br></div>