[Snort-users] high packet loss - low throughput

Y M snort at ...15979...
Sat Jul 20 20:01:51 EDT 2013


What are the configurations of the http_inspect preprocessor?

In our environment we have noticed better http traffic performance after tweaking the http_inspect preprocessor configurations in terms of request/response based on our environment, specifically when running Snort inline. What are the values of the memcap, server_flow_depth and client_flow_depth, decompress_depth, and max_gzip_mem?

Also, since this an SO deployment, did you use the iso image directly to build your sensors or built your own Ubuntu server and then added the SO repository? Note: the SO iso distribution is x64.

Did you also try to not to manually bind Snort processes to processors and just let the kernel do it? As I said earlier, a post I read somewhere suggested not to manually bind Snort processes to processors which involved pfring.
________________________________
From: Michal Purzynski<mailto:michal at ...16244...>
Sent: ‎7/‎21/‎2013 1:49 AM
To: snort-users at lists.sourceforge.net<mailto:snort-users at ...3783...net>
Subject: Re: [Snort-users] high packet loss - low throughput

On 7/20/13 5:17 AM, waldo kitty wrote:
> On 7/19/2013 15:51, Michal Purzynski wrote:
>> 64 bit of course. It's Ubuntu 12.04.2, everything updated, etc.
> and i can't help it but this has been nipping at me ever since i read it the
> first time...
>
> 1. why "of course"??
>
> 2. i would try the 32bit load and see what happens there... 64bit stuff takes at
> least twice the space and may be half as fast depending on factors...
>
> [anecdote: we have seen that 64bit doesn't offer an advantages in our
> environments... at best there's twice as much resources needed for roughtly the
> same load and half the speed as well... we've just not been able to truly
> justify the 64bit builds of the firewall we work with but for some reason
> everyone thinks that 64bit is better than the tried, tested and true 32bit stuff...]
>
> with that stated, i would seriously consider testing the 32bit load of SO and
> ensure that it is at least using the PAE kernel so that all that memory is
> recognized and used...
>
> what can it hurt, really? ;)
>
Yeah, sure I have time to rebuild everything on production
infrastructure to be 32 bit just to test it ;) I know the story - for
example a really cool vyatta distribution (firewall, router, etc)
refused to go 64 bit as the 32 bit version was better in a raw pps. They
actually did it after all - as the 64 bit version was more scalable, in
terms of supported netfilter rules and whatnot.

Still, I really appreciate your comments and ideas and find them
valuable. I just think it's something about the kind of traffic I have
(mostly http) and a snort configuration.

The sourcefire company claims to achieve 1Gbit/sec per CPU core. I find
it actualy hard to believe as the "empty" snort used to do around
250-300Mbit/sec per core here. Empty as in no rules at all.

Still, the packet loss rate does not seem to be connected in any way to
a Mbit/sec or pps. Need some more ideas, from the snort
developers/sourcefire team maybe? You know, hidding a good tuning tips
does not make people buy your products at the end of the day. It can
only cause people move to another vendor :)

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Snort-users mailing list
Snort-users at 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://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130721/3506e847/attachment.html>


More information about the Snort-users mailing list