[Snort-users] Snort as Gigabit Sensor

Kreimendahl, Chad J Chad.Kreimendahl at ...4716...
Tue Jul 29 09:39:14 EDT 2003

As a beta test I set up an intel machine running FreeBSD 5.x with
several interfaces.  Specs are PIII 2GHz 512MB.  

With polling compiled into the kernel I did some eyeball tests:  This is
all pushing @500Mbps of a large capture.

Now, unfortunately for freebsd polling is not dynamic, it's on or off.
So this test was done having one window open monitoring interrupts, one
watching iostat and one to set/unset the flag for polling.

With polling OFF:
  system went into live-lock
  took a while to recover
  was using 97% kernel time (interrupts)

With polling ON:
  system ran like a beautiful dream
  didn't appear as if anything was going on with the system
  was using 3% kernel time (polling interrupts)
  snort was taking about 40% cpu with everything turned on
  didn't check memory usage (didn't care)

Unfortunately for FreeBSD and Linux and Solaris, interrupts don't spread
across SMP.  So doubling your processor doesn't get you twice the
bandwidth/interrupt handling.  Though, if you're wanting to push massive
gigabits, it would work well to always have a that extra CPU for snort.
The limitation above Gig is indeed the PCI Bus.  64bit bus doubles this
limitation (approx 2.5Gbps?).  

There is a solution for the PCI bus... And that's built in networking


In theory you could push 4Gbps to the built-in.  4Gbps to the 66MHz PCI
and 2Gbps to the 33MHz PCI.  With polling on, the system could watch 10
Gbps without a problem (Hope I get to test this theory).  You're only
downside would be analyzing all this data... 

... This leads me to... What about a threading snort.  I know this was
going on a while back but taken out... Why?

-----Original Message-----
From: Bennett Todd [mailto:bet at ...6163...] 
Sent: Thursday, July 24, 2003 2:37 PM
To: Banniza Robert
Cc: 'snort-users at lists.sourceforge.net'
Subject: Re: [Snort-users] Snort as Gigabit Sensor

2003-07-24T14:43:39 Banniza Robert:
> Anyone have any good pointers on tuning Linux (Redhat 9) as a gigabit
> sensor?

Not this year.

Expect to hit a flat out impenetrable wall at c. 300Mbps for a
PCI-bus NIC, possibly as much as 550-600 for PCIx. These limits seem
to show up consistently, I've heard 'em from a lot of different

To approach those speeds you should

 - run on unnumbered interface in promisc --- you don't want the
   OS's IP stack analyzing the traffic (hence TCP tuning won't help)

 - use snort 2

 - give it plenty of ram (512MB is a good idea, cheap as ram is go
   ahead and give it a GB for future-proofing)

 - get the ring-buffered libpcap for Linux

 - go through the preprocessors, seeing which ones you can do

 - tune the config --- this is not optional if you want to hit
   multiple-hundred-mbps performance realms. Dial out false
   positives, get the alarm-generation rate down to something
   reasonable. Adjust the *_NET, *_SERVERS, *_PORTS tuning vars in
   snort.conf. #-out rules files you're not actively interested in.
   Examine the individual rules in the files you're including and
   eliminate any that don't apply to platforms you use.

Once you've gone down that road, a modern hot box ought to be able
to snort at bus speed limit (c. 300/550 Mbps as mentioned above).
Next year's hot box with a faster interface to the NIC may well be
able to do an honest Gbps. Maybe. I'll believe it when I see it:-).


More information about the Snort-users mailing list