[Bro] building a new bro server

Dopheide, Jeannette M jdopheid at illinois.edu
Tue Dec 9 08:29:58 PST 2014


Archiving to thread on behalf of Jusin Azoff:

On 12/9/14, 10:23 AM, "Azoff, Justin S" <jazoff at illinois.edu<mailto:jazoff at illinois.edu>> wrote:

The 2699 is definitely faster.  You can see some benchmarks here

http://www.cpubenchmark.net/high_end_cpus.html

One thing I know about intel CPUS is that the model numbers are mostly BS and hard to tell which should be faster, unless only the last two digits differ.. so for E5-26XX compared to E5-26YY, if YY is greater than XX, it's a better CPU.


--
- Justin Azoff

------
Jeannette M. Dopheide
Bro Outreach Coordinator
National Center for Supercomputing Applications
University of Illinois at Urbana-Champaign


From: Michal Purzynski <michal at rsbac.org<mailto:michal at rsbac.org>>
Date: Mon, 8 Dec 2014 20:39:07 -0800
To: <bro at bro.org<mailto:bro at bro.org>>
Subject: Re: [Bro] building a new bro server

I run a cluster with 12 workers on 16 physical cores. 64GB RAM each (mandatory!!). I pin workers to physical cores, otherwise OS will end up assigning two different workers to the same physical cores but different virtual (HT) and they end up competing for the same resources.

Are you looking at "netstats" or capture loss from a script (the one, that does heuristics with ACKs)? If you later and you can see a lot of drops and the number is more or less even accross the workers, than the loss might be happening before Bro. You said that using DNA didn't make a difference, so that might be worth looking into. How are you mirroring traffic - using taps or switch?

On 08/12/14 19:57, Allen, Brian wrote:
Good questions and suggestions.

  1.  The manager and the workers are all on the same server.
  2.  We have looked at all of those metrics, but the bro capture loss file is what we use most. That is the one saying we have 30+% packet loss.
  3.  We got a license and tried PF_Ring with DNA/Zero copy but it didn’t make a noticeable difference.
  4.  We do use the node.cfg file to pin the 14 worker processes to the individual cores.  That leaves 2 free cores for OS/System tasks.

We saw a huge improvement when we went from 16Gig RAM to 128Gig RAM. (That one was pretty obvious so we did that first).  We also saw improvement when we pinned the processes to the cores.

Thanks,
-Brian


From: Gary Faulkner <gfaulkner.nsm at gmail.com<mailto:gfaulkner.nsm at gmail.com>>
Date: Monday, December 8, 2014 at 6:52 PM
To: Brian Allen <brianallen at wustl.edu<mailto:brianallen at wustl.edu>>
Cc: Bro-Mailinglist <bro at bro.org<mailto:bro at bro.org>>
Subject: Re: [Bro] building a new bro server

A couple thoughts that might help the list better understand your topology/situation.

  1.  Are the manager and/or proxies on the same host?
  2.  What are you using to determine packet loss? (ex. Bro capture loss script, broctl netstat, pf_ring counters, etc)
  3.  Are you running PF_RING using any of the enhanced drivers (DNA/ZC) and/or zero copy scripts(Libzero/ZC)?
  4.  Are you pinning your worker processes to individual cores (via node.cfg) or are you letting the OS handle things?

I saw a marked improvement in average loss as measured by the bro capture loss script simply by pinning CPU cores on a server very similar to yours with similar traffic per host. Bursty traffic, and mega-flows, will still cause higher loss levels for individual workers at times though. Also, if you are running the manager and proxies on the same host they could be competing for the same cores that one or more workers are running on. Running htop might give you an idea of workers are being bounced between cores (if not pinned) as well as whether other processes are clobbering one or more of the cores your workers are on. Either could be an issue with workers running at 100% CPU usage.

Regards,
Gary

On 12/8/2014 4:56 PM, Allen, Brian wrote:
Hi All-
I currently have a server running BRO, and we are seeing a lot of packet loss.  I am getting quotes for a new server to replace it, and I wanted to run some of the options by this group to see what would be better.

Current server specs:

-2 Processors, 8 cores each at 2.4GHz, so 16 total.  We run 14 bro processes, one per core.  And they run at 100% utilization all the time.
-128G memory
-Intel IXGBE 10Gig network card with pfring

We are seeing 3-4 Gig traffic pretty much constantly, and we spike to 5 Gig.  The bro packet-loss file shows 30+% packet loss most of the time, but during the early morning hours, when traffic drops considerably it will fall to 0.01%.

For one test, we used a bpf filter to block all traffic going to bro except for a one /24 subnet of campus traffic for about 15 minutes and the packet-loss dropped to 0.01%.

So we think our processors are too few and too slow to handle this amount of bandwidth.

Our question as we get a quote to buy a new box is, which is more important for BRO, having the roughly same number of cores but get faster ones, or get more cores at the same or slower speed?

I’m looking at the following two Dell server options, although I can adjust this to add other better possibilities:

Option1:
-Intel Xeon E5-2699, two processors, 18 cores each at 2.3GHz for 36 total
-256Gig RAM
-Intel IXGBE 10Gig network card with pfring

Option2:
-Intel Xeon E5-2687 two processors, 10 cores each at 3.1GHz for 20 total
-256Gig RAM
-Intel IXGBE 10Gig network card with pfring

I’m assuming the first option would be much better but I’ve never researched this to know for sure, or how much better it would actually be.  I think the difference in price is around $2,400.

I’d like to get one box to handle our bandwidth as it grows over the next couple years, take the current underpowered box and use it is a BRO test box/elastic search server, and build the infrastructure to move to a BRO cluster in a couple years.  Right now a single box would be better for space issues.

I would be really interested to talk to other companies/universities who are running bro in the 3-7 Gig bandwidth range right now so I can see what hardware works for you.

Thanks for your help,
Brian Allen, CISSP
Information Security Manager
Washington University
brianallen at wustl.edu<mailto:brianallen at wustl.edu>
314-935-5380



_______________________________________________
Bro mailing list
bro at bro-ids.org<mailto:bro at bro-ids.org>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro




_______________________________________________
Bro mailing list
bro at bro-ids.org<mailto:bro at bro-ids.org>http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro

_______________________________________________ Bro mailing list bro at bro-ids.org<mailto:bro at bro-ids.org> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20141209/c9b02da0/attachment.html 


More information about the Bro mailing list