[Snort-users] high packet loss - low throughput

Michal Purzynski michal at ...16244...
Sun Jul 21 09:33:00 EDT 2013


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/da008d12/attachment.html>


More information about the Snort-users mailing list