Hi!
The field tcp packet seen on wrong thread is critical for the correct functioning of the tool?
This can be an issue, yes. I would recommend the following discussion: Support #2725: stream/packet on wrong thread - Suricata - Open Information Security Foundation
tl;dr packets might not be inspected in such a case
The problem is that I have a low-end network card (NetXtreme II BCM5709 Gigabit Ethernet). I can´t make all that optimization.
You could try autofp mode. How does your configuration look like currently?
This is my config.
suricata copy.yaml (74.5 KB)
Autofp mode gives my a lot bigger number of kernel drops.
Some stats…
So you use 3 interfaces, can you check if the issue is gone if you use only one interface? and afterwards enable just specific ones?
Overall we have no perfect solution to this issue yet.
I can confirm that using only one interface, the issue is gone. Autofp mode resolves the issue aswell but gives me a larger number of drops
You could try to check what options the NIC offers via ethtool.
Also worth a try to check if there is a NIC combination that would work, could be also worth to check different order in the configuration settings.
Could packets in a single flow be split among the interfaces? What are the traffic sources for your 3 interfaces?
One of the interfaces is mirroring internet traffic (outside). The other two are mirroring inside traffic, some special networks and VRF traffic
Is the mirroring done using for example switch span ports or physical fiber taps?
You could try to run 3 tcpdump sessions, one on each interface, and look at the pcaps in wireshark. Out of order packets or sessions being split between interfaces might be highlighted as broken sessions in wireshark.