<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Pinning threads and disabling flow director should help. No time to test it though. Well, a quick test with bro half a year ago looked promising. There are more issues no one is aware of, I'll describe it later.</div><div><br>On Jan 26, 2017, at 7:05 AM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">If you set a symmetric queue (posted elsewhere in some thread), I believe you do not see issues with reordering. We have seen output from pf_ring and af_packet as being near identical in logged connections, events, so unless pf_ring is also mangling connectings the same way as if_packet/AF_PACKET, we can assume this is a non-issue. Packet loss is actually substantually lower for both suricata and bro using a symmetric key, proper udp/tcp hashing, and af_packet compared to pf_ring on identical hardware. It comes at cost of cpu over memory however.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 26, 2017 at 9:56 AM, Seth Hall <span dir="ltr"><<a href="mailto:seth@icir.org" target="_blank">seth@icir.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jan 26, 2017, at 8:29 AM, erik clark <<a href="mailto:philosnef@gmail.com">philosnef@gmail.com</a>> wrote:<br>
><br>
> This is going into RHEL7.4, which is a 3.10 branch. We will be staying on RHEL7 as we have a full support contract with them, and to be honest, their engineers are amazing.<br>
<br>
</span>I would still be concerned about the packet reordering issue coming from the NIC with having multiple queues enabled. This appears to be an actual hardware behavior and not fixable through software. The effects from it can be fairly hard to discern too, but you may see an inflated capture_loss (in Bro, I forget what the Suricata equivalent is called) due to the packet reordering. It can also more directly effect things in UDP DNS query and reply matching.<br>
<br>
Sorry for the Bro stuff on the OISF mailing list, but I thought it was relevant since Erik is running Bro as well as Suricata on his system and I assume that Suricata would also have the same or similar issues with reordered packets. It's not an easy problem to diagnose.<br>
<br>
.Seth<br>
<br>
--<br>
Seth Hall<br>
International Computer Science Institute<br>
(Bro) because everyone has a network<br>
<a href="http://www.bro.org/" rel="noreferrer" target="_blank">http://www.bro.org/</a><br>
<br>
</blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Suricata IDS Users mailing list: <a href="mailto:oisf-users@openinfosecfoundation.org">oisf-users@openinfosecfoundation.org</a></span><br><span>Site: <a href="http://suricata-ids.org">http://suricata-ids.org</a> | Support: <a href="http://suricata-ids.org/support/">http://suricata-ids.org/support/</a></span><br><span>List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users</a></span><br></div></blockquote></body></html>