Hello all,
I’m using Suricata 6.0.17 on RHEL8, installed from the EPEL package repo. I’m attempting to use Suricata’s stats.log file to figure out whether the span session that feeds my packet capture host is dropping packets.
I have used tcpdump to take a sample pcap file containing about a minute of traffic. I have ensured that the network card itself did not drop any packets during the capture. When I analyze this file with Suricata I get the following stats:
Counter | TM Name | Value
------------------------------------------------------------------------------------
decoder.pkts | Total | 21340008
decoder.bytes | Total | 6114100782
decoder.invalid | Total | 219771
decoder.ipv4 | Total | 21464915
decoder.ethernet | Total | 21340008
decoder.tcp | Total | 17607541
tcp.syn | Total | 30002
tcp.synack | Total | 29306
tcp.rst | Total | 14324
flow.tcp | Total | 658332
flow.tcp_reuse | Total | 4478
tcp.sessions | Total | 29824
tcp.pseudo | Total | 130
tcp.reassembly_gap | Total | 24757
tcp.overlap | Total | 70
I’m interpreting tcp.sessions to be a count of TCP connections established during the capture. This seems to follow from the tcp.syn and tcp.synack counts which have approximately the same value. The tcp.flow count is about double; I assume the difference here accounts for connections that were seen but established before my packet capture started.
I’m interpreting tcp.reassembly_gap to mean that there were 24757 occurrences where Suricata could not reassemble part of a TCP stream. So, at a minimum, this number of packets were dropped. I assume that refers to streams represented by tcp.sessions as opposed to flow.tcp, and that I should expect this to be roughly zero, even for a short 60 second capture.
Do my assumptions seem sane? Would you conclude from these stats that there’s a problem upstream? Thanks