[Snort-devel] Snort 2.0 high CPU load and bad alert rate with higher traffic lo ads?
Daniel J. Roelker
droelker at ...402...
Wed Jun 4 11:11:13 EDT 2003
Thanks for testing Snort 2.0 performance and giving us your feedback.
I just have some suggestions as you do your testing:
- I suggest reading the focus-ids mailing list archives about the
different ways in which to test an intrusion detection system for
performance. There's been quite a lot of discussion about the type of
background traffic to generate. The forerunners in the IDS testing
market try to mimic real network traffic profiles when testing
performance. This especially became important after the very
questionable testing methodologies that Miercom originally used (sending
random traffic on one port, in their case port 0).
- Check your snort configuration file. Do you have all the performance
options turned on (httpflow, detection, etc)? The configuration files
will look different between snort 1.9 and snort 2.0.
The other thing to keep in mind when evaluating your test results is
that both Sourcefire customers and open-source users have validated the
fact the Snort 2.0 is much faster than 1.9. This isn't counting all the
testing that Sourcefire has done or the verification by independent
third parties. My guess is that either your snort configuration and/or
background traffic may be the culprit here.
Good luck in your future testing.
On Mon, 2003-06-02 at 08:14, Obermayr Thomas wrote:
> 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.
> Test Scenario:
> Snort machine:
> Intel P4 2.4 GHz
> 256 MB RAM
> Dual GBit Ethernet
> RedHat 7.3
> 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:
> Snort 1.9:
> BG CPU Alerts
> 0 5% 38
> 100 35% 36
> 380 95% 30
> 750 99% 25
> Snort 2.0:
> 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!
> Tom Obermayr
> This SF.net email is sponsored by: Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> Snort-devel mailing list
> Snort-devel at lists.sourceforge.net
More information about the Snort-devel