[Snort-devel] Snort 2.0 high CPU load and bad alert rate with higher traffic lo ads?
Thomas.Obermayr at ...2012...
Wed Jun 4 06:27:23 EDT 2003
As part of our studies of different free and commercial IDSs we've had
students perform high speed tests with Snort 1.9.1 and Snort 2.0. The papers
published before the release of Snort 2.0 lead us to believe that Snort 2.0
would actually perform better in a higher load scenario.
However we've found the opposite to be true.
Intel P4 2.4 GHz
256 MB RAM
Dual GBit Ethernet
Snort 1.9/Snort 2.0
HP ProCurve 8000M
8x 100 MBit Ports
4x 1000 MBit Ports
Snort attached to port configured as monitoring port
8x Traffic generating and receiving machines
1x Nessus scan machine
1x Nessus scan target machine
A pre-defined Nessus Scan was run in all cases and resulted in 38 alerts
with Snort 1.9 and 42 alerts with Snort 2.0.
Certain rules within Snort 1.9 and 2.0 had to be disabled as to not cause
alerts. With the default config otherwise unaltered both versions of Snort
found no alerts with the background traffic alone.
Background traffic: Traffic Generator TCP to port 11111, reply either ACK
only or echo for 750 MBit.
BG : Background Traffic in MBit/s
CPU : CPU load in percent
Alerts: Number of alerts reported by Snort
All tests were repeated 5 times with the number of alerts being the average
over all five tests.
Results for 80k TCP packets background traffic:
BG CPU Alerts
0 5% 38
100 35% 36
380 95% 30
750 99% 25
BG CPU Alerts
0 5% 42
100 90% 20
380 99% 15
750 99% 12
The test was repeated with 1024 byte TCP packets to make sure TCP stream
reassembly was not causing the high CPU loads. This test lead to the same
results as stated above.
There were several more tests performed with different background traffic
(UDP, mixed TCP/UDP, HTTP requests), with all showing the same picture
within a small margin of error.
This very much looks to us like something within the Snort 2.0 engine is
using a lot more CPU time than 1.9 and therefore causes 2.0 to "see" only
half of the attacks with a traffic load of 100 MBit/s whereas Snort 1.9
utilizes a third of the CPU and performs almost as well as with zero
I didn't, of course, expect Snort to work great with 750 Mbit/s traffic
load, however the results with Snort 2.0 for 100 Mbit are a bit
There will probably be a detailed paper of all the tests, results,
configuration etc. at a later time, but this is a pretty good summary of the
If any of the developers (or anyone else) can shed some light on why Snort
2.0 is performing "so badly" with higher traffic loads (and misses 50% of
attacks at only 100MBit/s already) it would be greatly appreciated.
Also any hints or tops on how to make Snort 2.0 perform better in the 100
MBit/s traffic range would be great. Or maybe we just have to wait for 2.0
to be further optimized? And finally, of course, let me congratulate all the
dedicated developers for such a great product!
More information about the Snort-devel