[Bro-Dev] PF_RING cluster ID

[Gregor Maier]

On 8/31/11 9:28 , Seth Hall wrote:
>
> On Aug 31, 2011, at 12:14 PM, Martin Holste wrote:
>
>> PF_RING's greatest feature is the ability to do per-flow clustering so
>> that many sniffers can run in parallel on their own CPU and each
>> receive a portion of the traffic which has been load-balanced.  Snort
>> and Suricata both support this, and we've come to rely on it as we
>> don't have access to hardware load balancing.  Is there a way to do
>> this in Bro?
>
> Use the cluster deployment in BroControl and assign each of the virtual interfaces to a separate worker node.  Since you're running the git master though, keep in mind that the broctl master that is currently checked out has some problems.  I'll work on merging in our fixed branch today and I'll reply again once it's updated.

I think it doesn't work like that :-(
It appears that PF_RINGs clustering doesn't use virtual interfaces for 
its clustering.

Bro currently uses libpcap exclusively for packet capture and AFAIK 
libpcap doesn't use PF_RING clustering.

I guess there are two possible ways to get this support to Bro:

a) directly: add a new PktSrc() that uses the PF_RING API directly and 
add the command line argument to specify the clustering information. 
BroControl will likely need to be updated as well. If somebody does 
that, than the same framework can probably be used for Endace's 
load-balancing packet capture as well.

b) use a modified libpcap: modify libpcap so that it uses PF_RING 
clusters and add some magic to the way libpcap parses interface names 
passed to it. Say that the monitoring interface it eth0, then libpcap 
could interpret an interface like "eth0::1" (*) as the first cluster 
stream from eth0 and setup PF_RING accordingly. You'd probably need a 
small external program that sets up the cluster then.

Although b) is a little hacky, it would also enable any libpcap based 
application to make use of PF_RING and it likely quicker to integrate 
with Bro and BroControl (since neither Bro nor BroControl need to be 
changed for that)


(*) I guess one could even encode even more information into this 
"virtual" interface name, like the cluster id: "eth0::CLUSTERID::STREAM"


cu
Gregor
-- 
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/