<div dir="ltr">If a bug/feature report is needed - would that fall into Bug #2423 that I opened on Redmine last week?<br><br>As for splitting the rules, I'll test that out and let you know what happens.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 24, 2018 at 11:46 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 24, 2018 at 5:38 PM, Steve Castellarin<br>
<<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
> One thing I notice is that whenever 4.0.3 has this issue and I issue a "kill<br>
> `pidof suricata`" Suricata always logs two errors at the end of the<br>
> suricata.log file:<br>
><br>
> <Error> - [ERRCODE: SC_ERR_FATAL(171)] - Engine unable to disable detect<br>
> thread - "W#[THREAD]-[HB#]".  Killing engine<br>
> <Error> - [ERRCODE: SC_ERR_NAPATECH_INIT_FAILED(<wbr>219)] - NT_InfoRead()<br>
> failed: NTAPI is terminating<br>
><br>
<br>
</span>This needs maybe a bug/feature report - i havn't experienced it with<br>
af-packet/pcap/pf-ring<br>
<span class=""><br>
> The "HB#" from the first error line matches the host buffer seeing the<br>
> spiraling packet drops.  This offending host buffer is always noted in the<br>
> "suricata.log" file with messages like:<br>
><br>
> <Info> - HB# - Increasing Host Buffer Fill Level :   25%<br>
> <Info> - HB# - Increasing Host Buffer Fill Level :   51%<br>
> <Info> - HB# - Increasing Host Buffer Fill Level :   75%<br>
> <Info> - HB# - Increasing Host Buffer Fill Level :  100%<br>
> <Info> - HB# - Increasing Adapter SDRAM Fill Level:   26%<br>
> <Info> - HB# - Increasing Adapter SDRAM Fill Level:   53%<br>
> <Info> - HB# - Increasing Adapter SDRAM Fill Level:   80%<br>
> <Info> - HB# - Increasing Adapter SDRAM Fill Level:  100%<br>
><br>
><br>
> Could this point to an issue with the Napatech code in Suricata - and how it<br>
> pulls/polls/etc data from the Napatech?<br>
><br>
><br>
<br>
</span>Might be.<br>
Can you try to split the rules you are loading and just load 1/2 of<br>
the rules for example - see if that is going to have any effect<br>
(switch each 1/2 too to take turn to run)?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> On Wed, Jan 24, 2018 at 11:08 AM, Steve Castellarin<br>
> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>><br>
>> I made the change to mpm-algo and spm-algo as you asked.  Suricata 4.0.3<br>
>> ran for just over 2 hours then exhibited the same 100% buffer/packets<br>
>> dropping with one CPU pegged at 100%.  I'm attaching a .zip with the stats &<br>
>> suricata.log files.  At the time of the hangup I noticed that our bandwidth<br>
>> utilization was under 800Mbps.<br>
>><br>
>> On Wed, Jan 24, 2018 at 9:12 AM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>> wrote:<br>
>>><br>
>>> On Wed, Jan 24, 2018 at 2:44 PM, Steve Castellarin<br>
>>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> > I'll give those a try now and let you know what happens.  In an earlier<br>
>>> > email I noted something and wanted to get your take on it...<br>
>>> ><br>
>>> > "I've noticed one thing that's strange.  In my YAML file I have the<br>
>>> > "autofp-scheduler" set to "active-packets".  Yet everytime I run<br>
>>> > Suricata I<br>
>>> > see this noted in suricata.log "using flow hash instead of active<br>
>>> > packets".<br>
>>> > When I comment out the "autofp-scheduler" setting in the YAML file then<br>
>>> > that<br>
>>> > message disappears.  Any idea on what that is all about?"<br>
>>> ><br>
>>><br>
>>> This is the default setting -<br>
>>><br>
>>> <a href="https://redmine.openinfosecfoundation.org/projects/suricata/repository/revisions/master/entry/suricata.yaml.in#L1024" rel="noreferrer" target="_blank">https://redmine.<wbr>openinfosecfoundation.org/<wbr>projects/suricata/repository/<wbr>revisions/master/entry/<wbr>suricata.yaml.in#L1024</a><br>
>>> with regards to autofp - but in your case you are using "--napatech<br>
>>> --runmode workers" so it should be unrelated.<br>
>>><br>
>>><br>
>>> > On Tue, Jan 23, 2018 at 6:00 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> On Tue, Jan 23, 2018 at 9:51 PM, Steve Castellarin<br>
>>> >> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> > Peter,<br>
>>> >> ><br>
>>> >> > I reviewed my compile of Suricata 4.0.3 I noticed that I was using<br>
>>> >> > Hyperscan<br>
>>> >> > version 4.7, as opposed to version 4.2 noted in the Suricata<br>
>>> >> > documentation<br>
>>> >> ><br>
>>> >> > (<a href="http://suricata.readthedocs.io/en/latest/performance/hyperscan.html" rel="noreferrer" target="_blank">http://suricata.readthedocs.<wbr>io/en/latest/performance/<wbr>hyperscan.html</a>).<br>
>>> >> > After recompiling with 4.2 I was able to get Suricata 4.0.3 to run<br>
>>> >> > for<br>
>>> >> > 42<br>
>>> >> > minutes before it started dropping packets uncontrollably.<br>
>>> >> ><br>
>>> >><br>
>>> >> If that made a change in behavior - can you try mpm-algo; ac-ks and<br>
>>> >> spm-algo: bm in the suricata.yaml?<br>
>>> >><br>
>>> >> > I then made a change to /proc/sys/vm/max_map_count based on a note<br>
>>> >> > in<br>
>>> >> > Napatech's documentation: "Especially for large host buffer<br>
>>> >> > configurations<br>
>>> >> > it is necessary to adjust the kernel sysctl "vm.max_map_count"<br>
>>> >> > (/proc/sys/vm/max_map_count).  The kernel sysctl "vm.max_map_count"<br>
>>> >> > (/proc/sys/vm/max_map_count) should be adjusted to (at least) the<br>
>>> >> > total<br>
>>> >> > configured host buffer memory in MB multiplied by four.<br>
>>> >> > Example for total host buffer size 128GB (131072MB): 131072*4 =<br>
>>> >> > 524288.<br>
>>> >> > Hence the minimum value for "vm.max_map_count" is 524288."<br>
>>> >> ><br>
>>> >> > In my case I'm using 17 host buffers at 2048MB per ((17 * 2048) *<br>
>>> >> > 4),<br>
>>> >> > which<br>
>>> >> > would be 139264.  My vm.max_map_count previously was 65530 (I guess<br>
>>> >> > default<br>
>>> >> > for Ubuntu 14.04).  After changing that and re-running Suricata<br>
>>> >> > 4.0.3 it<br>
>>> >> > ran<br>
>>> >> > for 45 minutes before the buffer/CPU issue came back.<br>
>>> >> ><br>
>>> >> > On Tue, Jan 23, 2018 at 9:49 AM, Steve Castellarin<br>
>>> >> > <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> >><br>
>>> >> >> Hi Peter,<br>
>>> >> >><br>
>>> >> >> I just realized I responded directly to you instead of the mailing<br>
>>> >> >> list<br>
>>> >> >> -<br>
>>> >> >> so here's my response, updated.<br>
>>> >> >><br>
>>> >> >> I made a change to my YAML file for 4.0.3, dropping the<br>
>>> >> >> detect-thread-ratio from 1.5 to 1 and on Friday was able to run<br>
>>> >> >> Suricata<br>
>>> >> >> 4.0.3 for five hours before the issue occurred.  This run did<br>
>>> >> >> handle<br>
>>> >> >> sustained network traffic of 1.2 through 1.7gbps.  So that is a<br>
>>> >> >> step in<br>
>>> >> >> the<br>
>>> >> >> positive direction.  I'm going to have a hard time running 4.0.3<br>
>>> >> >> without<br>
>>> >> >> rules, as this unfortunately is our only Suricata instance running<br>
>>> >> >> our<br>
>>> >> >> rule<br>
>>> >> >> set.<br>
>>> >> >><br>
>>> >> >> I've noticed one thing that's strange.  In my YAML file I have the<br>
>>> >> >> "autofp-scheduler" set to "active-packets".  Yet everytime I run<br>
>>> >> >> Suricata I<br>
>>> >> >> see this noted in suricata.log "using flow hash instead of active<br>
>>> >> >> packets".<br>
>>> >> >> When I comment out the "autofp-scheduler" setting in the YAML file<br>
>>> >> >> then<br>
>>> >> >> that<br>
>>> >> >> message disappears.  Any idea on what that is all about?<br>
>>> >> >><br>
>>> >> >> On Sun, Jan 21, 2018 at 3:49 PM, Peter Manev <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >> wrote:<br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>> On 18 Jan 2018, at 19:21, Steve Castellarin<br>
>>> >> >>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>><br>
>>> >> >>> wrote:<br>
>>> >> >>><br>
>>> >> >>> And also, the bandwidth utilization was just over 800Mbps.<br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>> Can you try the same run but this time - load no rules. I would<br>
>>> >> >>> like<br>
>>> >> >>> to<br>
>>> >> >>> see if it would make difference or not in the same amount of time.<br>
>>> >> >>><br>
>>> >> >>><br>
>>> >> >>> On Thu, Jan 18, 2018 at 1:16 PM, Steve Castellarin<br>
>>> >> >>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> >>>><br>
>>> >> >>>> Hey Peter,<br>
>>> >> >>>><br>
>>> >> >>>> Those changes didn't help.  Around 23+ minutes into the run one<br>
>>> >> >>>> worker<br>
>>> >> >>>> CPU (#30) stayed at 100% while buffer NT11 dropped packets and<br>
>>> >> >>>> would<br>
>>> >> >>>> not<br>
>>> >> >>>> recover.  I'm attaching a zip file that has the stats.log for<br>
>>> >> >>>> that<br>
>>> >> >>>> run, the<br>
>>> >> >>>> suricata.log file as well as the information seen at the command<br>
>>> >> >>>> line<br>
>>> >> >>>> after<br>
>>> >> >>>> issuing "/usr/bin/suricata -vvv -c /etc/suricata/suricata.yaml<br>
>>> >> >>>> --napatech<br>
>>> >> >>>> --runmode workers -D".<br>
>>> >> >>>><br>
>>> >> >>>> Steve<br>
>>> >> >>>><br>
>>> >> >>>><br>
>>> >> >>>> On Thu, Jan 18, 2018 at 11:30 AM, Steve Castellarin<br>
>>> >> >>>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> >>>>><br>
>>> >> >>>>> We never see above 2Gbps.  When the issue occurred a little bit<br>
>>> >> >>>>> ago<br>
>>> >> >>>>> I<br>
>>> >> >>>>> was running the Napatech "monitoring" tool and it was saying we<br>
>>> >> >>>>> were<br>
>>> >> >>>>> between<br>
>>> >> >>>>> 650-900Mbps.  I'll note the bandwidth utilization when the next<br>
>>> >> >>>>> issue<br>
>>> >> >>>>> occurs.<br>
>>> >> >>>>><br>
>>> >> >>>>> On Thu, Jan 18, 2018 at 11:28 AM, Peter Manev<br>
>>> >> >>>>> <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >>>>> wrote:<br>
>>> >> >>>>>><br>
>>> >> >>>>>> On Thu, Jan 18, 2018 at 5:27 PM, Steve Castellarin<br>
>>> >> >>>>>> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> >>>>>> > When you mean the "size of the traffic", are you asking what<br>
>>> >> >>>>>> > the<br>
>>> >> >>>>>> > bandwidth<br>
>>> >> >>>>>> > utilization is at the time the issue begins?<br>
>>> >> >>>>>><br>
>>> >> >>>>>> Sorry - i mean the traffic you sniff - 1/5/10...Gbps ?<br>
>>> >> >>>>>><br>
>>> >> >>>>>> ><br>
>>> >> >>>>>> > I will set things up and send you any/all output after the<br>
>>> >> >>>>>> > issue<br>
>>> >> >>>>>> > starts.<br>
>>> >> >>>>>> ><br>
>>> >> >>>>>> > On Thu, Jan 18, 2018 at 11:17 AM, Peter Manev<br>
>>> >> >>>>>> > <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >>>>>> > wrote:<br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> On Thu, Jan 18, 2018 at 4:43 PM, Steve Castellarin<br>
>>> >> >>>>>> >> <<a href="mailto:steve.castellarin@gmail.com">steve.castellarin@gmail.com</a>> wrote:<br>
>>> >> >>>>>> >> > Hey Peter,<br>
>>> >> >>>>>> >> ><br>
>>> >> >>>>>> >> > I tried as you asked.  Less than 15 minutes after I<br>
>>> >> >>>>>> >> > restarted<br>
>>> >> >>>>>> >> > Suricata I<br>
>>> >> >>>>>> >> > saw<br>
>>> >> >>>>>> >> > my first CPU hitting 100% and one host buffer dropping all<br>
>>> >> >>>>>> >> > packets.<br>
>>> >> >>>>>> >> > Shortly<br>
>>> >> >>>>>> >> > after that the second CPU hit 100% and a second host<br>
>>> >> >>>>>> >> > buffer<br>
>>> >> >>>>>> >> > began<br>
>>> >> >>>>>> >> > dropping<br>
>>> >> >>>>>> >> > all packets.  I'm attaching the stats.log where you'll see<br>
>>> >> >>>>>> >> > at<br>
>>> >> >>>>>> >> > 10:31:11<br>
>>> >> >>>>>> >> > the<br>
>>> >> >>>>>> >> > first host buffer (nt1.drop) starts to register dropped<br>
>>> >> >>>>>> >> > packets,<br>
>>> >> >>>>>> >> > then at<br>
>>> >> >>>>>> >> > 10:31:51 you'll see host buffer nt6.drop begin to register<br>
>>> >> >>>>>> >> > dropped<br>
>>> >> >>>>>> >> > packets.<br>
>>> >> >>>>>> >> > At that point I issued the kill.<br>
>>> >> >>>>>> >> ><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> What is the size of the traffic?<br>
>>> >> >>>>>> >> Can you also try<br>
>>> >> >>>>>> >> detect:<br>
>>> >> >>>>>> >>   - profile: high<br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> (as opposed to "custom")<br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> Also if can run it in verbose mode (-vvv)   and send me that<br>
>>> >> >>>>>> >> compete<br>
>>> >> >>>>>> >> output after you start having the issues.<br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> Thanks<br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> > Steve<br>
>>> >> >>>>>> >> ><br>
>>> >> >>>>>> >> > On Thu, Jan 18, 2018 at 10:05 AM, Peter Manev<br>
>>> >> >>>>>> >> > <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >>>>>> >> > wrote:<br>
>>> >> >>>>>> >> >><br>
>>> >> >>>>>> >> >> 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<br>
>>> >> >>>>>> >> >> > run<br>
>>> >> >>>>>> >> >> > 4.0.3 -<br>
>>> >> >>>>>> >> >> > with<br>
>>> >> >>>>>> >> >> > the<br>
>>> >> >>>>>> >> >> > network information removed.  Let me know if you need<br>
>>> >> >>>>>> >> >> > anything<br>
>>> >> >>>>>> >> >> > else<br>
>>> >> >>>>>> >> >> > from<br>
>>> >> >>>>>> >> >> > our<br>
>>> >> >>>>>> >> >> > configuration.  I'll also go to the redmine site to<br>
>>> >> >>>>>> >> >> > open a<br>
>>> >> >>>>>> >> >> > bug<br>
>>> >> >>>>>> >> >> > report.<br>
>>> >> >>>>>> >> >> ><br>
>>> >> >>>>>> >> >> > Steve<br>
>>> >> >>>>>> >> >><br>
>>> >> >>>>>> >> >> 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<br>
>>> >> >>>>>> >> >> example<br>
>>> >> >>>>>> >> >><br>
>>> >> >>>>>> >> >><br>
>>> >> >>>>>> >> >> Thank you.<br>
>>> >> >>>>>> >> >><br>
>>> >> >>>>>> >> >> ><br>
>>> >> >>>>>> >> >> > On Wed, Jan 17, 2018 at 6:36 AM, Peter Manev<br>
>>> >> >>>>>> >> >> > <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >>>>>> >> >> > 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<br>
>>> >> >>>>>> >> >> >> > at<br>
>>> >> >>>>>> >> >> >> > the<br>
>>> >> >>>>>> >> >> >> > stats<br>
>>> >> >>>>>> >> >> >> > log<br>
>>> >> >>>>>> >> >> >> > and<br>
>>> >> >>>>>> >> >> >> > configuration file I sent.  So far, running 3.1.1<br>
>>> >> >>>>>> >> >> >> > with<br>
>>> >> >>>>>> >> >> >> > the<br>
>>> >> >>>>>> >> >> >> > updated<br>
>>> >> >>>>>> >> >> >> > Napatech<br>
>>> >> >>>>>> >> >> >> > drivers my system is running without any issues.<br>
>>> >> >>>>>> >> >> >> ><br>
>>> >> >>>>>> >> >> >><br>
>>> >> >>>>>> >> >> >> The toughest part of the troubleshooting is that i<br>
>>> >> >>>>>> >> >> >> dont<br>
>>> >> >>>>>> >> >> >> have<br>
>>> >> >>>>>> >> >> >> the set<br>
>>> >> >>>>>> >> >> >> up to reproduce this.<br>
>>> >> >>>>>> >> >> >> I didn't see anything that could lead me to definitive<br>
>>> >> >>>>>> >> >> >> conclusion<br>
>>> >> >>>>>> >> >> >> from<br>
>>> >> >>>>>> >> >> >> the stats log.<br>
>>> >> >>>>>> >> >> >> Can you please open a bug report on our redmine with<br>
>>> >> >>>>>> >> >> >> the<br>
>>> >> >>>>>> >> >> >> details<br>
>>> >> >>>>>> >> >> >> form<br>
>>> >> >>>>>> >> >> >> this mialthread?<br>
>>> >> >>>>>> >> >> >><br>
>>> >> >>>>>> >> >> >> Would it be possible to share the suricata.yaml<br>
>>> >> >>>>>> >> >> >> (privately<br>
>>> >> >>>>>> >> >> >> if<br>
>>> >> >>>>>> >> >> >> 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<br>
>>> >> >>>>>> >> >> >> >> Napatech<br>
>>> >> >>>>>> >> >> >> >> drivers<br>
>>> >> >>>>>> >> >> >> >> before<br>
>>> >> >>>>>> >> >> >> >> running Suricata 4.0.3 to clear out any previous<br>
>>> >> >>>>>> >> >> >> >> drop<br>
>>> >> >>>>>> >> >> >> >> counters,<br>
>>> >> >>>>>> >> >> >> >> etc.<br>
>>> >> >>>>>> >> >> >> >><br>
>>> >> >>>>>> >> >> >> >> The first time I saw a packet drop was at the<br>
>>> >> >>>>>> >> >> >> >> 12:20:51<br>
>>> >> >>>>>> >> >> >> >> mark, and<br>
>>> >> >>>>>> >> >> >> >> you'll<br>
>>> >> >>>>>> >> >> >> >> see "nt12.drop" increment.  During this time one of<br>
>>> >> >>>>>> >> >> >> >> the<br>
>>> >> >>>>>> >> >> >> >> CPUs<br>
>>> >> >>>>>> >> >> >> >> acting<br>
>>> >> >>>>>> >> >> >> >> as<br>
>>> >> >>>>>> >> >> >> >> a<br>
>>> >> >>>>>> >> >> >> >> "worker" was at 100%.  But these drops recovered at<br>
>>> >> >>>>>> >> >> >> >> the<br>
>>> >> >>>>>> >> >> >> >> 12:20:58<br>
>>> >> >>>>>> >> >> >> >> mark,<br>
>>> >> >>>>>> >> >> >> >> where<br>
>>> >> >>>>>> >> >> >> >> "nt12.drop" stays constant at 13803.  The big issue<br>
>>> >> >>>>>> >> >> >> >> triggered at<br>
>>> >> >>>>>> >> >> >> >> the<br>
>>> >> >>>>>> >> >> >> >> 12:27:05 mark in the file - where one worker CPU<br>
>>> >> >>>>>> >> >> >> >> was<br>
>>> >> >>>>>> >> >> >> >> stuck<br>
>>> >> >>>>>> >> >> >> >> at<br>
>>> >> >>>>>> >> >> >> >> 100%<br>
>>> >> >>>>>> >> >> >> >> followed<br>
>>> >> >>>>>> >> >> >> >> by packet drops in host buffer "nt3.drop".  Then<br>
>>> >> >>>>>> >> >> >> >> came a<br>
>>> >> >>>>>> >> >> >> >> second<br>
>>> >> >>>>>> >> >> >> >> CPU<br>
>>> >> >>>>>> >> >> >> >> at<br>
>>> >> >>>>>> >> >> >> >> 100%<br>
>>> >> >>>>>> >> >> >> >> (another "worker" CPU) and packet drops in buffer<br>
>>> >> >>>>>> >> >> >> >> "nt2.drop" at<br>
>>> >> >>>>>> >> >> >> >> 12:27:33.  I<br>
>>> >> >>>>>> >> >> >> >> finally killed Suricata just before 12:27:54, where<br>
>>> >> >>>>>> >> >> >> >> you<br>
>>> >> >>>>>> >> >> >> >> see all<br>
>>> >> >>>>>> >> >> >> >> host<br>
>>> >> >>>>>> >> >> >> >> buffers<br>
>>> >> >>>>>> >> >> >> >> beginning to drop packets.<br>
>>> >> >>>>>> >> >> >> >><br>
>>> >> >>>>>> >> >> >> >> I'm also including the output from the "suricata<br>
>>> >> >>>>>> >> >> >> >> --dump-config"<br>
>>> >> >>>>>> >> >> >> >> command.<br>
>>> >> >>>>>> >> >> >> >><br>
>>> >> >>>>>> >> >> >> >> On Thu, Jan 11, 2018 at 11:40 AM, Peter Manev<br>
>>> >> >>>>>> >> >> >> >> <<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<br>
>>> >> >>>>>> >> >> >> >>> > a<br>
>>> >> >>>>>> >> >> >> >>> > couple<br>
>>> >> >>>>>> >> >> >> >>> > weeks<br>
>>> >> >>>>>> >> >> >> >>> > with<br>
>>> >> >>>>>> >> >> >> >>> > Napatech support and they believed the Napatech<br>
>>> >> >>>>>> >> >> >> >>> > setup<br>
>>> >> >>>>>> >> >> >> >>> > (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<br>
>>> >> >>>>>> >> >> >> >>> 4.0.x in<br>
>>> >> >>>>>> >> >> >> >>> terms of<br>
>>> >> >>>>>> >> >> >> >>> Napatech is that they did update the code, some<br>
>>> >> >>>>>> >> >> >> >>> fixes<br>
>>> >> >>>>>> >> >> >> >>> and<br>
>>> >> >>>>>> >> >> >> >>> updated<br>
>>> >> >>>>>> >> >> >> >>> 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<br>
>>> >> >>>>>> >> >> >> >>> issue<br>
>>> >> >>>>>> >> >> >> >>> starts<br>
>>> >> >>>>>> >> >> >> >>> occuring?<br>
>>> >> >>>>>> >> >> >> >>><br>
>>> >> >>>>>> >> >> >> >>><br>
>>> >> >>>>>> >> >> >> >>> > On Thu, Jan 11, 2018 at 9:52 AM, Peter Manev<br>
>>> >> >>>>>> >> >> >> >>> > <<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<br>
>>> >> >>>>>> >> >> >> >>> >> back<br>
>>> >> >>>>>> >> >> >> >>> >> to<br>
>>> >> >>>>>> >> >> >> >>> >> our<br>
>>> >> >>>>>> >> >> >> >>> >> 3.1.1<br>
>>> >> >>>>>> >> >> >> >>> >> install of<br>
>>> >> >>>>>> >> >> >> >>> >> Suricata, with<br>
>>> >> >>>>>> >> >> >> >>> >><br>
>>> >> >>>>>> >> >> >> >>> >><br>
>>> >> >>>>>> >> >> >> >>> >> the upgraded Napatech version.  Since then I've<br>
>>> >> >>>>>> >> >> >> >>> >> seen<br>
>>> >> >>>>>> >> >> >> >>> >> no<br>
>>> >> >>>>>> >> >> >> >>> >> packets<br>
>>> >> >>>>>> >> >> >> >>> >> dropped<br>
>>> >> >>>>>> >> >> >> >>> >> with sustained bandwidth of between 1 and<br>
>>> >> >>>>>> >> >> >> >>> >> 1.7Gbps.<br>
>>> >> >>>>>> >> >> >> >>> >> So<br>
>>> >> >>>>>> >> >> >> >>> >> I'm<br>
>>> >> >>>>>> >> >> >> >>> >> not<br>
>>> >> >>>>>> >> >> >> >>> >> sure<br>
>>> >> >>>>>> >> >> >> >>> >> what is<br>
>>> >> >>>>>> >> >> >> >>> >> going on with my configuration/setup of<br>
>>> >> >>>>>> >> >> >> >>> >> Suricata<br>
>>> >> >>>>>> >> >> >> >>> >> 4.0.3.<br>
>>> >> >>>>>> >> >> >> >>> >><br>
>>> >> >>>>>> >> >> >> >>> >><br>
>>> >> >>>>>> >> >> >> >>> >><br>
>>> >> >>>>>> >> >> >> >>> >> So the only thing that you changed is the<br>
>>> >> >>>>>> >> >> >> >>> >> upgrade<br>
>>> >> >>>>>> >> >> >> >>> >> of<br>
>>> >> >>>>>> >> >> >> >>> >> the<br>
>>> >> >>>>>> >> >> >> >>> >> Napatech<br>
>>> >> >>>>>> >> >> >> >>> >> drivers<br>
>>> >> >>>>>> >> >> >> >>> >> ?<br>
>>> >> >>>>>> >> >> >> >>> >> The Suricata config stayed the same -  you just<br>
>>> >> >>>>>> >> >> >> >>> >> upgraded to<br>
>>> >> >>>>>> >> >> >> >>> >> 4.0.3<br>
>>> >> >>>>>> >> >> >> >>> >> (from<br>
>>> >> >>>>>> >> >> >> >>> >> 3.1.1) and the observed effect was - after a<br>
>>> >> >>>>>> >> >> >> >>> >> while<br>
>>> >> >>>>>> >> >> >> >>> >> all<br>
>>> >> >>>>>> >> >> >> >>> >> (or<br>
>>> >> >>>>>> >> >> >> >>> >> 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<br>
>>> >> >>>>>> >> >> >> >>> >> 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"<br>
>>> >> >>>>>> >> >> >> >>> >>> <<a href="mailto:petermanev@gmail.com">petermanev@gmail.com</a>><br>
>>> >> >>>>>> >> >> >> >>> >>> wrote:<br>
>>> >> >>>>>> >> >> >> >>> >>><br>
>>> >> >>>>>> >> >> >> >>> >>> On Wed, Jan 10, 2018 at 11:29 AM, Steve<br>
>>> >> >>>>>> >> >> >> >>> >>> 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<br>
>>> >> >>>>>> >> >> >> >>> >>> that<br>
>>> >> >>>>>> >> >> >> >>> >>> happens<br>
>>> >> >>>>>> >> >> >> >>> >>> ?<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>
>>> >> >>>>>> >> >> --<br>
>>> >> >>>>>> >> >> Regards,<br>
>>> >> >>>>>> >> >> Peter Manev<br>
>>> >> >>>>>> >> ><br>
>>> >> >>>>>> >> ><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >><br>
>>> >> >>>>>> >> --<br>
>>> >> >>>>>> >> Regards,<br>
>>> >> >>>>>> >> Peter Manev<br>
>>> >> >>>>>> ><br>
>>> >> >>>>>> ><br>
>>> >> >>>>>><br>
>>> >> >>>>>><br>
>>> >> >>>>>><br>
>>> >> >>>>>> --<br>
>>> >> >>>>>> Regards,<br>
>>> >> >>>>>> Peter Manev<br>
>>> >> >>>>><br>
>>> >> >>>>><br>
>>> >> >>>><br>
>>> >> >>><br>
>>> >> >><br>
>>> >> ><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> --<br>
>>> >> Regards,<br>
>>> >> Peter Manev<br>
>>> ><br>
>>> ><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Regards,<br>
>>> Peter Manev<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>