Support #1232
closedHow to detect packet loss
Description
Hey!
Can anyone explain how to detect paket loss? Currently, I'm using suricata in two different setups:
1) Suricata "standard" installation, without modifications
2) Suricata, compiled with PF_RING Support, I'm running suricata in combination with PF_RING transparent_mode 0 and standard intel e1000e driver (no DNA or ZC)
All tests are carried out with same Traffic and Bandwith (100Mbit/s - tcpreplay)
-------------------------------------------------------------------
Date: 4/27/2014 -- 15:55:46 (uptime: 0d, 02h 00m 01s)
-------------------------------------------------------------------
Counter | TM Name | Value
-------------------------------------------------------------------
capture.kernel_packets | RxPcapeth21 | 119807497
capture.kernel_drops | RxPcapeth21 | 47781707
-------------------------------------------------------------------
Date: 5/4/2014 -- 23:39:52 (uptime: 0d, 02h 00m 01s)
-------------------------------------------------------------------
Counter | TM Name | Value
-------------------------------------------------------------------
capture.kernel_packets | RxPFR1 | 46011931
capture.kernel_drops | RxPFR1 | 0
Setup without modifications: 119.807.497
Setup with PF_RING: 46.011.931
Why is there such a wide difference between this two data? - Traffic and runtime was always the same.
I would appreciate your feedback,
Wolfgang
Updated by Andreas Moe almost 10 years ago
As far as i have come to know, kernel_drops is the amount of packets not sent from kernel space into user space. So if PFRING has no kernel_drops it means that suricata has revieced all the packets that have been detected on the wire. Apart from this there are other factors such as memcap drops (see: https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Statistics).
Updated by Wolfgang Schlichtner almost 10 years ago
But why is there such a big difference between capture.kernel_packets with or without PF_RING? Bandwith and Traffic was exactly the same..
capture.kernel_packets:
Setup without modifications: 119.807.497
Setup with PF_RING: 46.011.931
Updated by Peter Manev almost 10 years ago
Are you sure that the traffic/bandwidth was the same?
Updated by Wolfgang Schlichtner almost 10 years ago
definitely, tcpreplay with the same pcap file!
Updated by Victor Julien almost 10 years ago
What are the suricata commandlines you uses for both tests?
Updated by Wolfgang Schlichtner almost 10 years ago
without pf_ring:
suricata -i eth1 -c /etc/suricata/suricata.yaml
with pf_ring (transparent_mode 0, standard NAPI polling):
suricata --pfring-int=eth1 --pfring-cluster-id=99 --pfring-cluster-type=cluster_flow -c /etc/suricata/suricata.yaml
Updated by Peter Manev almost 10 years ago
Which pf_ring ver is that?
Can you try af_packet and observe if the issue is the same?