Multi tap architecture

Hi everyone,

I'm looking to build a Bro architecture with several Tap components (I
mean the tcpdump stuff), all separated from the core.
I've seen the "cluster" architecture
(, but as I said I want to
split out the capture work, not the protocol analysis stuff.

My situation is the following : I have several "boxes" (with not enough
power to do the protocol analysis work, that's the point) in different
networks, all connected to one single "core" component. I would like to
deploy network capture (Tap) instances on all those boxes, and let the
core component do all the hard stuff (I can potentially install a
front-end on this core component to set up many "workers" behind it).

Is there any way to do this ? Any documentation ? Does anyone have any
clue about how to set it up that way ?

Thanks a lot,

Hi Pierre,

just to recap if I understand everything correctly: you have low-powered
boxes that you just want to capture traffic on, without analyzing the
payload, because they are too low powered. And then you would like to do
the protocol analysis on another machine.

Bro itself does not support this scheme - parsing has to happen on the
same instance that does the capturing. It sounds like you might want to
use some other software that can just duplicate and forward interesting
traffic to a more high-powered machine, where you can perform the actual

I have never built a setup like this myself - but I suspect you might even
be able to do this directly in Linux using onboard tools; create a
tunneled interface that sends traffic to the destination that you want to
send it to and mirror traffic to that interface - or something similar to


Many moons ago, I deployed a number of Linksys systems running OpenWRT (one per internal subnet), all reporting back to a central Bro system. The Linksys systems captured all traffic (which would be directed traffic to their IP, as well as broadcast traffic - ARP, etc.). The traffic was captured via tcpdump, and tunneled via an ssh connection to the central collector box, which would push that traffic via a small binary onto a virtual interface monitored by Bro (the traffic from all of the collectors was pushed onto the same interface) - worked fine for the low volume of traffic that the systems saw. Does this sound similar to what you’re trying to accomplish?


This might work with something that’s light enough to capture and forward traffic. I suggest doing it with netsniff-ng and copying traffic to some kind of tunnel interface.