<div dir="ltr"><div dir="ltr"><div>Thanks for sharing. It is indeed important to monitor packet drops during all stages of packet processing.</div><div>We actually wrote about it in the original SEPTun Mark I - see the section about packet drops (point 1, SPAN ports)</div><div><br></div><div><a href="https://github.com/pevma/SEPTun/blob/master/SEPTun.rst#packet-drops">https://github.com/pevma/SEPTun/blob/master/SEPTun.rst#packet-drops</a></div><div><br></div><div>Fortunately, most switches and Arista lets you query everything with SNMP and that is something your monitoring should look at as well. You have a tricky setup, so you should monitor both.</div><div><br></div><div>If you have Zeek running with the same upstream infrastructure and you can enable the stats.log + capture_loss.log and if there are no drops seen in stats.log but there's something in the capture_loss.log - it is time to check the upstream. I used Zeek to troubleshoot the entire NSM stack a couple of times ;)</div><div><br></div><div>Now (and developers can verify me) I think that if in Suricata's stats log</div><div>- kernel drops are 0</div><div>- memcap drops are 0</div><div>- tcp.reassembly_gap is bigger than 0</div><div><br></div><div>You can deduce from those you have an upstream problem.</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 17, 2019 at 8:14 AM Greg Grasmehr <<a href="mailto:greg.grasmehr@caltech.edu">greg.grasmehr@caltech.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello All,<br>
<br>
Some of you may remember in early-mid 2018 I was essentially pulling my<br>
hair out trying to figure out why Suricata was apparently missing alert<br>
traffic on our 10G wire.  Network claimed everything was hunky dory on<br>
their end, and I spent countless hours testing different configs and<br>
rule sets trying to determine what was going on.<br>
<br>
Fortunately I attended Zeekcon last October and one of the presentations<br>
got me looking at our Zeek data and then to thinking.<br>
<br>
Long story short - one of the SPANS feeding our Arista switch turned out<br>
to be saturated and dropping packets on the edge switch feeding the<br>
Arista.  Once that was rectified Suricata was finally receiving all<br>
network data and with Hyperscan enabled easily handling the traffic,<br>
even during micro bursts exceeding 10G, and this is with more than 57000<br>
rules enabled.  As far as I can tell it doesn't miss a thing now. w00t!<br>
<br>
-- <br>
Sincerely,<br>
<br>
Greg Grasmehr<br>
Lead Information Security Analyst<br>
California Institute of Technology (Caltech)<br>
GPGMe: 38E2 F9BD A95E 9824 20AB  331A 9E29 D1A1 AAEE 5F42<br>
<a href="http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x9E29D1A1AAEE5F42" rel="noreferrer" target="_blank">pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x9E29D1A1AAEE5F42</a><br>
_______________________________________________<br>
Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org" target="_blank">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>
<br>
Conference: <a href="https://suricon.net" rel="noreferrer" target="_blank">https://suricon.net</a><br>
Trainings: <a href="https://suricata-ids.org/training/" rel="noreferrer" target="_blank">https://suricata-ids.org/training/</a></blockquote></div></div></div>