<div dir="ltr">Sorry, this didn't make it to the list. Forwarding.<div><div class="gmail_quote"><br><br><div dir="ltr">My suricata.yaml is built off of:<div><br></div><div><a href="https://home.regit.org/2012/07/suricata-to-10gbps-and-beyond/" target="_blank">https://home.regit.org/2012/<wbr>07/suricata-to-10gbps-and-<wbr>beyond/</a><br></div><div><br></div><div>Yes, I have already turned off all the offloading. </div><div><br></div><div>According to:</div><div><br></div><div><a href="https://github.com/JustinAzoff/can-i-use-afpacket-fanout" target="_blank">https://github.com/<wbr>JustinAzoff/can-i-use-<wbr>afpacket-fanout</a><br></div><div><br></div><div>fanout does not work with RHEL7 kernels, even if you set the rx hash. In this case, its the 3.10.0-327.36.1.el7 kernel. I have read several places that this is the case. I have tried setting the hash with:</div><div><br></div><div>ethtool -X $iface hkey 6d:5a:6d:5a....</div><div><br></div><div>and also tried setting the rss queue to 1 with</div><div><br></div><div>-L $iface combined 1</div><div><br></div><div>Interestingly, this seems to "work" without setting the hash or stripping the rss queues. However, since I know that fanout isn't working as is, I believe something in Suricata is not going correctly. This is evinced by the fact that Bro (also on the same box) has a trashed conn and weird log because traffic is going out one worker and coming back in on a totally different worker. Given what Suri does, this may not actually be an issue, but what concerns me is that connection driven signatures will fail because the worker used to start the sig is not the same as the one receiving return traffic.</div><div><br></div><div>Hope this makes sense.</div><div><br></div><div><br></div><div>Per RedHat support:</div><div><br></div><div>---</div><div><span style="color:rgb(51,51,51);font-family:monospace;font-size:11.375px;white-space:pre-wrap">The eb70db875 fix is included in upstream v4.7 so if you need this feature at the cost of everything else, you could use ELRepo's kernel-ml package of v4.7 or later. I tested their kernel-ml-4.8.12-1.el7.elrepo, recompiled the go application, and the test passes fine.</span><br></div><div><span style="color:rgb(51,51,51);font-family:monospace;font-size:11.375px;white-space:pre-wrap">---</span></div><div><br></div><div>Where eb70db875 is the kernel patch that resolves this issue. It MIGHT be fixed in 7.4, but I will not know. Based on the response from RHEL, I think it is safe to say that AF_PACKET does not work as expected with Suricata on RHEL7 at this time. </div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 7, 2016 at 4:52 AM, Cr3a70r <span dir="ltr"><<a href="mailto:sickgamep@gmail.com" target="_blank">sickgamep@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">What kernel you use ?<div>Did you set ethtool -K ethX gro off lro off? </div><div>Did you set suricata AF_PACKET threads to 1 explicitly ? </div><div>Show us your uname -a and suricata.yaml </div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_8560598889983872067h5"><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></div><br></div></div>