[Snort-users] Snort on DNA/Libzero performance tuning
livio at ...15149...
Thu Dec 20 12:58:28 EST 2012
We have not tested the libzero and bpf combination,
but with PF_RING NAPI you should be able to get several gigs with that hardware..
You can look at http://www.metaflows.com/technology/10-gbps-pf_ring-2/
for some performance comparison between PF_RING NAPI and PF_RING_DNA.
In general, given our experience, I would say that the best way to use your
hardware would be to spawn as many snort processes as you have cores like:
|for| |i ||in| |`||seq| |0 1 y`; ||do|
|snort -c snort.serv.conf -N -A none -i ethx --daq-||dir|
|--daq pfring --daq-var clusterid=10 &|
Notice that there is no bindcpu option! When running snort, the bottleneck is
the CPU not the packet IO.. So, letting the processes float on the cores seems
to give the best performance.
Here are a few other things:
o Do you have rules with long lists of IPs like [ip1,ip2,ip3,ip4...]
etc? These types of rules are horribly slow because snort matches them
linearly. If so, try disabling them and see if things improve (if so,
let me know we have a plugin for that). You can also configure snort with
--enable-perfprofiling to see if there are bad rules that are taking
too much time.
o A big buffer can always help. When you load the pf_ring kernel module
give it at least 65k and place your interfaces in transparent mode 1 as in:
transparent_mode=1 min_num_slots=65536 (or even more than 65k if your
kernel can handle it). You might need to also increase the kernel memory
with vmalloc=256M as a boot parameter.
o On some of our processors we got very good performance improvements by
compiling snort with "-march=native -fomit-frame-pointer -O3"
o What does cat /proc/interrupts show? Do you map the eth* IRQs to
different CPUs or does CPU 0 do all the interrupts?
o Then there is the snort.conf.. I will let other people chime on that..
Here are just a few things I can think of right now..
On 12/19/2012 4:50 PM, Craig Merchant wrote:
> I'm new to running Snort in fairly high throughput environment. We
> have a Snort sensor running in IDS mode and using a SPAN port. That
> core switch generally handles traffic volumes between 150 Mbit/sec to
> 600+ Mbit/sec.
> We purchased a Silicom fiber NIC and have installed the PF_RING
> drivers that use DNA and Libzero. The sensor has 32 cores in it.
> I've used the Libzero pfdnacluster_master to divide our traffic into
> 28 channels so we can run 28 Snort instances.
> Even with no rules applied to snort, some instances run at 90%+ almost
> all the time while others are running around 45%. Libzero doesn't
> load balance traffic by volume, so it's not surprising that we're
> seeing some instances burn more CPU than others. With a ruleset of
> only about 180 rules, we're seeing a number of the following messages
> when traffic flows near the top end of the range:
> <29>Dec 19 16:42:09 ids01-dc1 snort: S5: Session exceeded
> configured max bytes to queue 1048576 using 1049163 bytes (server
> queue). 22.214.171.124 51499 --> 126.96.36.199 25 (0) : LWstate 0x48
> LWFlags 0x406107
> The command we use to start snort is (instance 10 in this example):
> snort -q -D -e --pid-path /var/run -i dnacluster:10 at ...15345... -c
> /opt/rb/etc/snort/snort.conf -l /var/log/snort/instance-10
> --perfmon-file /var/log/snort/instance-10/stats/snort.stats --daq-dir
> /opt/rb/lib/daq/ --daq pcap --daq-mode passive --daq-var bindcpu=10 -R
> _10 --treat-drop-as-alert
> I'm wondering if there are any DNA/Libzero specific documents or
> threads that deal with performance tuning. Or if there is a
> definitive "best practices" methodology and guide for tuning Snort.
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> Go to this URL to change user options or unsubscribe:
> Snort-users list archive:
> Please visit http://blog.snort.org to stay current on all the latest Snort news!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users