Suricata lots of flow never timeout

Version info(from github install):

suricata --build-info
This is Suricata version 8.0.2 RELEASE
Features: PCAP_SET_BUFF AF_PACKET NETMAP HAVE_PACKET_FANOUT LIBCAP_NG HAVE_HTP_URI_NORMALIZE_HOOK PCRE_JIT HAVE_NSS HTTP2_DECOMPRESSION HAVE_LUA HAVE_JA3 HAVE_JA4 HAVE_LIBJANSSON TLS TLS_C11 MAGIC RUST POPCNT64
SIMD support: SSE_4_2 SSE_4_1 SSE_3 SSE_2
Atomic intrinsics: 1 2 4 8 16 byte(s)
64-bits, Little-endian architecture
GCC version 11.4.0, C version 201112
compiled with _FORTIFY_SOURCE=2
L1 cache line size (CLS)=64
thread local storage method: _Thread_local
compiled with LibHTP v8.0.2

I use tcpreplay send 1.1GB pcap 100 times to suricata,stats show no packet drop

capture.kernel_drops": “0”,
“capture.kernel_packets”: “431647396”,
“decoder.arp”: “0”

when stop tcpreplay for longtime(more than 30 min),stats still show lots of udp flow notimeout

“flow.mgr.flows_checked”: “11396362”,
“flow.mgr.flows_evicted”: “420218”,
“flow.mgr.flows_evicted_needs_work”: “1840”,
“flow.mgr.flows_notimeout”: “10978514”,
“flow.mgr.flows_timeout”: “417848”,
“flow.mgr.full_hash_pass”: “1295”,
“flow.mgr.rows_maxlen”: “7”,
“flow.mgr.rows_per_sec”: “104856”,
“flow.recycler.queue_avg”: “23”,
“flow.recycler.queue_max”: “19178”,
“flow.recycler.recycled”: “418378”,
“flow.spare”: “3095452”

Here is may config,I have try change udp flow timeout many time, still not work

flow:
memcap: 4gb
hash-size: 1048576
prealloc: 700000
managers: 4
recyclers: 4
flow-timeouts:
default:
new: 30
established: 300
emergency-new: 10
emergency-established: 100
tcp:
new: 60
established: 300
closed: 120
emergency-new: 10
emergency-established: 300
emergency-closed: 20
udp:
new: 30
established: 300
emergency-new: 10
emergency-established: 300
icmp:
new: 30
established: 300
emergency-new: 10
emergency-established: 100
stream:
memcap: 2gb
reassembly:
memcap: 20gb
depth: 128kb

So whers is these flows “flow.mgr.flows_notimeout”: “10978514”, these flows was already droped or still in flow.mgr, How can I flush them out to eve output?

Thank you for your help.

flows_notimeout should be compared with flows_checked. Flows are checked for timeout by the flowmanager on an interval, and the notimeout counter simply reflects how often flows were checked but not yet timed out. It’s not a reflection of flows never timing out for some reason.

Thank you for your explaination,even flows_notimeout cause flows output, But I still has the problem. stats show “capture.kernel_packets”: “431647417”,and tcpreplay show Actual: 440181000 packets (65221941400 bytes) sent in 1395.80 seconds
Rated: 46726981.5 Bps, 373.81 Mbps, 315359.04 pps
Flows: 429633 flows, 307.80 fps, 43974600000 flow packets, 5730000 non-flow
Statistics for network device: cap1
Successful packets: 440181000
Failed packets: 100
Truncated packets: 0
Retried packets (ENOBUFS): 0
Retried packets (EAGAIN): 0

I can see suricata did not drop packet. I get 158.1K flows output by eve log( get 154007165 pkt sum by all flows pkts_toclient+ pkts_toserver),That means all flows get only 34% packets, May I know What causes the total number of packets across all flows to be much smaller than capture.kernel_packets?

I have arkime capture on same NIC at same time, arkime get 2094786 flows logs,and get 98.37% pkts (433019587/440181000),Seems work good.