Re: high packet loss - low throughput

[Michal Purzynski <michal () rsbac org>]

On 7/21/13 6:08 PM, Joel Esler wrote:
> If Snort sees traffic more than once, it will analyze it as many times 
> as it sees it.
>
> The SSL preprocessing should discard an ignore a session after it 
> determines the legitimate certificate exchange,
How does the SSL renegotiation rule work than? It seems to inspect some 
bytes deeper in the stream (and gets triggered here a few times a day, 
as people scan us on a regular basis).
> But like I said, it sounds like there is something else going on here.
Well it's only snort having problems here. I run Bro (on another host) 
for all the cool features it's got and have so little packet loss (<1%). 
Netsniff-ng has 0% loss, etc.

I've tuned the http preprocesor as advised here. I've set it up to not 
inspect everything and disabled all the unnecessary preprocessors.

preprocessor http_inspect: global iis_unicode_map unicode.map 1252 
compress_depth 1460 decompress_depth 2920

server_flow_depth 1460 \
    client_flow_depth 1460 \
    post_depth 65495 \


A very important question, to help me understand what's going on here - 
are the packet drop, pps, Mbit/sec, and all other counters calculated 
every period, right?

It looks to me like a new line with a current stats gets added every few 
minutes. So I did

for i in {1..20}; do cat snort-$i.stats | awk 'BEGIN { drop=0 } /^[0-9]/ 
{ FS=","; drop+=$2 } END { print drop }'; done;

And diving that number by a numer of lines beggining by number

for i in {1..20}; do cat snort-1.stats | grep '^[0-9]' | wc -l; done;

gets me a packet drop rate from 1.37% to almost 0%, depending on the 
process.

Still some of the processes can have short "peak" with a very high drop 
rate. Any ideas what might be a reason that some of them get 'saturated' 
from time to time? 6.7% loss on a process that's got 29.71Mbit/sec in 
statistics but later ... 0%.
> Sent from my iPhone
>
> On Jul 21, 2013, at 9:33 AM, Michal Purzynski <michal () rsbac org 
> <mailto:michal () rsbac org>> wrote:
>
> > On 7/21/13 2:03 PM, Joel Esler wrote:
> > > Yes, performance that low seems incorrect. I don't think it's Snort 
> > > with numbers that low.
> > Also, a question for the more experienced. I have a simple setup - 
> > load balancers in front of everything, doing L7 and terminating SSL. 
> > Snort gets a copy of all the traffic and that means it can see:
> > 1. traffic from Internet to load balancers
> > 2. traffic from LB to the backend servers
> > 3. traffic from the backend to LB
> > 4. traffic from the LB to the Internet
> >
> > It's clear it can see the same traffic twice, sometimes enrypted 
> > sometimes decrypted (SSL preprocessor enabled, so the encrypted 
> > traffic is being ignored).
> >
> > Question: does it make sense to leave it like this or should I only 
> > direct the "internal" traffic to snort? You know, the one between the 
> > LB <-> backend?
> >
> > > Sent from my iPad
> > >
> > > On Jul 21, 2013, at 6:16 AM, Michal Purzynski <michal () rsbac org 
> > > <mailto:michal () rsbac org>> wrote:
> > >
> > > > On 7/21/13 2:22 AM, Joel Esler wrote:
> > > > > On Jul 20, 2013, at 6:46 PM, Michal Purzynski <michal () rsbac org 
> > > > > <mailto:michal () rsbac org>> wrote:
> > > > >
> > > > > > 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.
> > > > >
> > > > > Even more.  But we have a dedicated appliance specifically tuned 
> > > > > with special drivers to run Snort very fast.  You are doing this, 
> > > > > I assume on commodity hardware, on a stock OS, running many things 
> > > > > (Security Onion)
> > > > Not really, SO is so wonderful you can enable and disable 
> > > > functionality on demand, and so I've done. The box is running snort 
> > > > and netsniff-ng only, has around 20 processes of snort (24 
> > > > execution threads with HT enabled).
> > > >
> > > > Still - 45Mbit/sec per instance with packet loss is disappointing. 
> > > > And 100 would be too.
> > > >
> > > > Also, I'm running Intel and pf_ring, can try a Myricom (and not 
> > > > pf_ring). I won't try anything more expensive like FPGA accelerated 
> > > > cards, since I find them too limited and having no real advantage 
> > > > over Myricom and a lot of downsides.

------------------------------------------------------------------------------
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 () 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!