[Oisf-users] where are my missing packets ?

mc8647 mc8647 at mclink.it
Wed Feb 22 23:38:39 UTC 2012

Hi to everybody, first time poster.

I must admit that I've been following suricata for only one week. I'm 
reading mailing lists, testing, reading blogs and again testing... 
modifying configuration, modifying rules, and again reading and testing...

Now I need to ask the experts for some help.

My server is a double cpu with 6 cores each = 12 core (24 if I enable 
hyperthreading), 12 GB ram, using last ubuntu with kernel 3.0 64 bit. I 
can double (or triplicate) the ram if needed. I compiled suricata from 
the 1.2.1 tar source file.
I don't have PF_RING enabled since the broadcom PF_RING aware drivers 
doesn't easily compile under 3.0 kernel (I was not able to compile them...)

I want to setup as a IDS and activate some rules to check for malicious 
traffic in order to locate malware infected workstations.

I have a mirror port that gives me about 200/400 mbit of lan traffic on 
a 1 gbit port of the server. No special setting was done on linux 
network kernel parameters.

 From day 1 I noticed that we are losing packets. If I stop suricata 
with ctrl-c I get a message stating about 25% packets missed. I changed 
several parameters, the first was max-pending-packets I set to 500 then 
to 5000 and now to 50000. I also raised memory available for various 
buffers. I also tried some threading settings.
This evening I read that the packets missed percentage printed at ctrl-c 
are from the pcap library, but if I run tcpdump together with suricata I 
see the packets in tcpdump output but they don't show up in suricata 
When suricata starts http.log logs entries really fast but then it gets 
slower and slower probably due to the missed packets.

top reports a range of 9-25% for each cpu, with a total of about 230% on 
the process.

I'd like to ask you a lot of questions but I know it is not possible in 
a single message :-)

So just to start I'd like to know which metrics should I monitor in 
stat.log, in top (swap ? process size ?) in order to understand where 
these packets miss the road... would it be good to test the setup using 
replicable traffic, like a pcap file ?

Try some other optimization method with 3.0 kernel (cpu affinity, 
memory, af_packet, network kernel parameters....) or is it better to 
wipe the disks, install a 2.6.39 kernel and install PF_RING ? Or is the 
hardware not powerfull enough anyway ?


More information about the Oisf-users mailing list