<div dir="ltr"><div>So here's what I did at one of out offices. Intel X710 are used there</div><div><br></div><div>ethtool -L enp17s0f0 combined 4</div><div>ethtool -L enp17s0f0 rxhash on</div><div>ethtool -K enp17s0f0 ntuple on</div><div><br></div><div>ethtool -X enp17s0f0 hkey 6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A equal 4</div><div><br></div><div>ethtool -N enp17s0f0 rx-flow-hash tcp4 sd</div><div><br></div><div>The _qm flow has been used in both Zeek and Suricata.</div><div><br></div><div>So far I can see traffic hashed correctly. If you have some ideas how I could test this further, please let me know.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 5, 2019 at 11:52 AM Nelson, Cooper <<a href="mailto:cnelson@ucsd.edu">cnelson@ucsd.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">I updated the ticket, so I'm throwing some info here as well in case any OISF readers have ideas.<br>
<br>
It appears that switching to the older 'autofp' runmode resolves this issue (while also greatly increasing packet drops on my system).  My theory being that  by running the stream tracker on the RSS cores, separate from the detect threads, fragmented TCP are properly reassembled before being forwarded.  In the 'workers' runmode the fragments end up on the 'wrong' threads and increase the counter.<br>
<br>
Digging deeper into the kernel and suricata source code, at this point I think the solution would be to update cluster_flow to properly handle fragmented TCP/UDP packets.  Since this is 'broken' in the hardware RSS implementation it needs to be fixed in user space, the AF_PACKET code in the kernel doesn't seem to be able to handle this edge case properly.  <br>
<br>
There are a couple ways this could be handled; as mentioned the easiest thing is to just 'punt' and only hash on the IP header src->dst for all protocols.<br>
<br>
Another thing would be to check the 'fragflag' and offset fields in each TCP/UDP packet and then send them to a dedicated thread queue for reassembly, then computing the hash and forwarding the packet to the proper thread.  This should guarantee that the fragments are put together in the proper order.<br>
<br>
-Coop<br>
<br>
-----Original Message-----<br>
From: Peter Manev <<a href="mailto:petermanev@gmail.com" target="_blank">petermanev@gmail.com</a>> <br>
Sent: Wednesday, May 29, 2019 2:00 PM<br>
To: Michał Purzyński <<a href="mailto:michalpurzynski1@gmail.com" target="_blank">michalpurzynski1@gmail.com</a>><br>
Cc: Nelson, Cooper <<a href="mailto:cnelson@ucsd.edu" target="_blank">cnelson@ucsd.edu</a>>; Cloherty, Sean E <<a href="mailto:scloherty@mitre.org" target="_blank">scloherty@mitre.org</a>>; Eric Urban <<a href="mailto:eurban@umn.edu" target="_blank">eurban@umn.edu</a>>; Open Information Security Foundation <<a href="mailto:oisf-users@lists.openinfosecfoundation.org" target="_blank">oisf-users@lists.openinfosecfoundation.org</a>><br>
Subject: Re: [Oisf-users] [EXT] Re: Packet loss and increased resource consumption after upgrade to 4.1.2 with Rust support<br>
<br>
On Wed, May 29, 2019 at 9:52 PM Michał Purzyński <<a href="mailto:michalpurzynski1@gmail.com" target="_blank">michalpurzynski1@gmail.com</a>> wrote:<br>
><br>
> How about ignoring layers above 3 and just going with ip src + ip dst? I'm pretty sure I can do that on i40e.<br>
><br>
<br>
Lets give it a spin ? :)<br>
Maybe  do runs with/without taking into consideration of vlanids?<br>
(just to see if related)<br>
<br>
<br>
--<br>
Regards,<br>
Peter Manev<br>
</blockquote></div>