[Bro] Bro performance issues

Gregor Maier gregor at icir.org
Tue Nov 1 05:57:39 PDT 2011


In terms of performance please note that using the new_packet() event 
generates a lot of overhead so the performance you see is
going to be significantly worse than in "normal" operation.

cu
gregor

On 10/30/11 2:46 , Tomer Teller wrote:
> Hey all,
>
> I am testing Bro's performance using tcpreplay for some project of mine.
>
> I am using a packet capture of 680000 packets using different rates to
> check for packet loss.
>
> tcpreplay  -i eth0 --mbps=X 680000.pcap (where X = 1000,500,100,10)
>
> I am registered on the new_packet event in order to count packets like so:
>
> global ctr = 0;
> event new_packet (c: connection,p: pkt_hdr)
> {
>     ctr = ctr + 1;
>     ...
> }
>
> I write to log every time ctr % 100,000 = 0 to avoid unnecessary I/O to
> disk.
>
> On the sender side i see that all packet was transmitted successfully as
> well as on the receiver side (using tcpdump), i.e. it is not libpcap issue.
>
> Bro on the other hand, doesn't see all 680000, he sees around 540,000.
>
> I also used smaller packet captures (10/30/100 packets), again, bro does
> not see all packets.
> Note! Packet captures are valid (checksum) HTTP connections that i
> recorded for testing.
>
> I tried removing some analyzers using broctl as well as modifying local.bro.
> Also followed the Bro performance tuning.
>
> Nothing helps, Bro does not see all the packets.
>
> Any ideas what is the problem?
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Bro mailing list
> bro at bro-ids.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro


-- 
Gregor Maier
<gregor at icir.org>  <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA
http://www.icir.org/gregor/



More information about the Bro mailing list