# A more parallel Bro

**URL:** <https://community.zeek.org/t/a-more-parallel-bro/1496>\
**Category:** Zeek\
**Created:** [March 4, 2009, 4:33pm UTC](https://community.zeek.org/t/a-more-parallel-bro/1496 "2009-03-04T16:33:07Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![dalbrech](https://avatars.discourse-cdn.com/v4/letter/d/ecae2f/32.png) [@dalbrech](https://community.zeek.org/u/dalbrech)\
**Post date:** [March 4, 2009, 4:33pm UTC](https://community.zeek.org/t/a-more-parallel-bro/1496/1 "2009-03-04T16:33:07Z")

</div>

Robin Sommer wrote:

> > real system. So I built a simple tool I call "dns-packet-gen", which

generates

> > pathological DNS packets constructed for their difficulty in parsing. The

tool

> > emits pcap traces containing DNS traffic with many records (50+), all of

which

> > feature deeply-recursive DNS names.
> 
> Neat. Is that tool available?

Making it available is on my todo, but it's toward the bottom. My group  
currently doesn't have a good web presence, but we're planning to fix that one  
of these days as I think it does a lot for a research group's visibility.

> > I'm wondering how you plan to address cache behavior in your multi-

threaded

> > implementation of Bro. Obviously, this is a really hard problem, and I'm not  
> > sure how well-studied it is in the literature, especially in the context of IDS.
> 
> That's an excellent question and I don't think it has been studied  
> in the IDS context yet. Our main strategy is to keep related state  
> together, e.g., by running all analysis involving the same  
> connection on the same core. It's hard to predict though how cache  
> effects will eventually turn out to hurt us, and we expect to do a  
> number of measurements in this regard once the multi-threaded Bro is  
> in a shape that we can actually measure something. Going from there,  
> I'm sure there'll be lots of further optimization potential.

I'm going to start analyzing Bro's memory use and performance; do you have  
any recommendations about which policy I use? I'm looking for a reasonably  
"representative" workload (if such a thing even exists), something that will test  
a lot of code paths through the system.

Thanks again,  
DA

---

<div class="post-metadata">

**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\
**Post date:** [March 5, 2009, 9:38pm UTC](https://community.zeek.org/t/a-more-parallel-bro/1496/2 "2009-03-05T21:38:21Z")

</div>

Here's a sequence of scripts imposing increasing load on Bro that we  
have been using in the past for some of our measurements:

(1) tcp  
(2) tcp mt  
(3) tcp mt scan trw  
(4) tcp mt scan trw udp icmp  
(5) tcp mt scan trw udp icmp http-request http-reply http-body http-header  
(6) tcp mt scan trw udp icmp http-request http-reply http-body http-header ssh pop3 irc ssl smtp

It's also worth comparing running with the connection compressor vs.  
without (use\_connection\_compressor=T/F). And keep an eye on the  
packet filter; it's easy to forget but can have quite an impact on  
performance depending on what it lets through and what not.

Robin

---

<div class="post-metadata">

**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\
**Post date:** [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/a-more-parallel-bro/1496/3 "2022-05-06T15:38:52Z")

</div>

Closed on May 6, 2022, 3:38pm UTC