It is available via bro-pkg; note you need to have a DAG card and software installed (available with registration at the support portal https://www.endace.com/support).
With bro-pkg:
bro-pkg refresh
bro-pkg install endace/bro-dag
bro -i endace::dag0:0
The first number is the DAG card index, and the second number is the stream number on that card.
In our experience this plugin provides the best capture performance on DAG cards. The bro-dag README covers example node.cfg for hardware flow balancing across multiple workers (see github above).
There are two alternative methods for live capture using DAG cards in Bro: libpcap or PF_RING.
If libpcap is compiled on a system with DAG software installed, it will support capture from DAG devices with full kernel bypass. Using Bro's native pcap packet source and linking with the correct libpcap library:
bro -i dag0:0
If a recent PF_RING version is installed on a system with DAG software, it dynamically supports DAG cards without any manual compilation/linking required. The bro-pfring plugin can then be used for high performance capture:
Cool! Thanks for not only creating a new packet source but also making a broctl plugin and adding it to the Bro package manager! Nice job all around.
I only have one small request. Would you mind changing the documentation to use two workers instead of the "lb_interfaces" option? I don't know if anyone actually uses that option anymore and I'd be a little worried that we might break it on accident. You should be able to break that into two separate worker stanzas, each with one of the interfaces that you've defined in your documentation. You get the additional benefit that you can specify different numbers of "lb_procs" for each one and any other differentiated configuration that you need.
Cool! Thanks for not only creating a new packet source but also making a
broctl plugin and adding it to the Bro package manager! Nice job all around.
Thanks! We wanted to integrate it as smoothly as possible, so please let us know if you have any further feedback.
I only have one small request. Would you mind changing the documentation
to use two workers instead of the "lb_interfaces" option?
I don't know if anyone actually uses that option anymore and I'd be a little
worried that we might break it on accident. You should be able to break that
into two separate worker stanzas, each with one of the interfaces that you've
defined in your documentation. You get the additional benefit that you can
specify different numbers of "lb_procs"
for each one and any other differentiated configuration that you need.
I didn't realise lb_interfaces was out of date, so I'll remove that section. I think it is clear enough how to use multiple workers.
Yeah, that's our bad. It's not documented anywhere that it's sort of falling out of date (I forgot that it was even a feature!). I'm just concerned that we'd have a small portion of the community that started using it and we wouldn't be aware of that usage and accidentally break it or something.
