[Snort-users] high packet loss - low throughput

Michal Purzynski michal at ...16244...
Sun Jul 21 14:16:25 EDT 2013

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 

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 at ...16244... 
> <mailto:michal at ...16244...>> 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 at ...16244... 
>>> <mailto:michal at ...16244...>> wrote:
>>>> On 7/21/13 2:22 AM, Joel Esler wrote:
>>>>> On Jul 20, 2013, at 6:46 PM, Michal Purzynski <michal at ...16244... 
>>>>> <mailto:michal at ...16244...>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20130721/37e2d6e0/attachment.html>

More information about the Snort-users mailing list