RE: snort behavior in very high-load environment, B SD vs. linux

["Cloppert, Michael" <Michael.Cloppert () 53 com>]

Okay, I'm not going to be able to address all of your issues/concerns here
as I'm fairly new with snort myself, BUT here are my thoughts...

> Now, I've read/heard for a long time that the BSD packet capture
> ability is far better than that in linux, even with the new 2.4
> optimizations.
I've heard this too, this is the first attempt at verifying such claims with
regard to snort that I've read.  Kudos!

> I've got two identical boxes with two identical gig-e feeds running
> into them.  The hardware is dual P3 1.26GHz, 1GB RAM, plenty of
> 7200rpm IDE disk, and Intel pro1000-T adapters.  On the copper there
> is a steady stream from our backbone of around 55-70kpps, weighing
> in at between 300-400Mbps, depending on time of day.  
Okay, first thing to consider is your processors.  Keep in mind snort is
single-threaded, so unless you're running barnyard (I think that's what it's
called), which handles output processors in a separate thread, this likely
won't help your performance.  Second, the point you make about your PCI bus
being 32 as opposed to 64 bit is valid.  Remember, you have not only your
gig ethernet card trying to talk across this bus, but also all the data
going to your disk array, and if you have two NIC's (one for capture and one
for management), you're cramming that data onto the bus as well.  Whether or
not LINUX & BSD handle pushing data across the bus differently I don't know,
but something to think about.

> Snort analyzed -906323712 out of -843192947 packets, The 
> kernel dropped
<snip>
> Snort analyzed -1634877952 out of -796656885 packets, The 
> kernel dropped
> 793215694(22.674%) packets
<snip>
> Snort analyzed -249022464 out of -1275082956 packets, The 
> kernel dropped
> 1452753881(113.934%) packets
>
> How do I drop more than 100%?
I'd bet you're seeing integer wraparound.  Snort's using a signed integer
for keeping track of how many packets it's captured and when it attempts to
count high enough, you will begin to see negative numbers.  If you're not a
coder, here's basically how it works.  IF a signed integer is used, the
high-order bit is reserved as the negative indicator.  For example, 0000
0010 is a positive number, but 1000 0111 is a negative number (because the
high-order bit is set).  When you're counting, if you get high enough and
you add 1 to 0111 1111, you get 1000 0000, which then puts you in the
negative realm!  You may simply need to regulate the number of packets
you're capturing by doing so for a shorter period of time, so you avoid this
problem - maybe do this a number of times and add up your results?  It's a
thought...

Hope this helps.  Definitely post any other results you get - this is very
useful information!!

Mike


-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users