[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
http.log...
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 ?
Thanks
Francesco
More information about the Oisf-users
mailing list