PF_RING pfring_open() for Endace DAG

Zeek
1

(Currently I’m using Bro 2.1)

Can we change PF_RING mode to use pfring_open() from /usr/local/include/pf_ring.h instead of libpcap? My rational follows, and I would really like to see this get into the main dist.

(I’ve not looked into modifying libpcap-ring1.1.1 yet, but it’s probably not be possible due to how information is delivered from the dag interface.)

According to the NTOP website, it would be just as fast as using libpcap-ring.
(see: http://www.ntop.org/products/pf_ring/ under “Who needs PF_RING?”)

I’m having trouble getting the libpcap-ring1.1.1 from PF_RING to use my DAG interfaces. (Operationally I have to use PF_RING for the specific stream, because I’m already using the DAG to split the streams for another application, and the DAG is limited to only doing this once.)

When using the pf_ring enabled libpcap on a normal interface, it will open that interface with pf_ring. As it turns out this is not the behavior on a DAG stream. This is a problem because bro relies on using libpcap to interface with the DAG.

PF_RING does support the DAG, but you must use the pf_ring library to open the interface with something like pfring_open(“dag:dagX:Y”) instead of trying to use libpcap.

There is an example of pfcount (pf_ring) and pcount (libpcap) in the PF_RING/userland/examples directory that illustrates how to use the PF_RING API.

What are your thoughts?

Thanks,
Ben

2

We don't have resources to do this work and honestly we're going to be taking a slightly different direction with Bro. However we are in the process of abstracting our packet source interface and if you chose to write a native PF_Ring plugin (when we have the interface complete) you could contribute it back to us for possible inclusion into Bro.

  .Seth

3

Thanks Seth.

Unfortunately I don’t have the time to look into this much further either. I’ve got some higher priority things to do right now. If I can come back to it I’ll let you know.

I’m assuming this different direction will change the way bro interfaces with the network? I understand if you can’t say much about it.

Cheers,
Ben

4

Nah, it won't change that. I just think we'll end up doing something different than PF_Ring as our primary accelerated mechanism. I'd only rather not talk about it publicly quite yet because we're still exploring. :slight_smile:

PF_Ring will certainly still be supported at it's current level though. The next release will be even a bit better because recently I added support for PF_Ring DNA to the BroControl plugin. I just need to write documentation for it.

  .Seth

5

This was actually a sponsored project; I think the sponsor will be stepping forward soon.

Liam

6

Does that use pfring_open from the PF_RING API by chance? I was reading the
PF_RING User Guide, and noticed this:

As stated in the previous chapter, PF_RING 4.7 has a modular architecture.
In order to indicate to the library which module we are willing to use, it
is possible to prepend the module name to the device name, separated by a
colon (e.g. dna:dnaX@Y for the dna module, dag:dagX:Y for the dag module,
"multi:ethA@X;ethB@Y;ethC@Z" for the Link Aggregation module,
"dnacluster:A@X" for the Cluster consumer module).

Makes me think that if "dna:dnaX@Y" works then "dag:dagX:Y" should also
work. Anyways, my project is shifting gears now and I can't look into this
any further. I may come back to it in 6 months if there is still work to be
done here.

Thanks again,
Ben

7

Yes, it's likely that it would work.

.Seth

8

Last question. What release can I see this change in? Or is it still in the development branch for now?

Can I get it from the latest git? (https://github.com/bro/broctl)

Thanks,
Ben

9

I recall you can duplicate streams with DAG. Something like:

100 all
200 all
color 100 stream 2,4,6,8
color 200 stream 0

…and then have bro use a bpf filter upon the dag0:2,4,6,etc interfaces. Would take some more digging into the DAG docs to see if you could just outright apply hash load balancing across those streams as well. Etiher way, I’m pretty sure this can all be done directly within the DAG card with no need for pf_ring (the bro integration with pf_ring does make things wonderfully easy to setup though!)

-Alex

10

It depends on your DAG hardware. They can all do the load balancing, not all can duplicate the buckets to multiple streams.
On my 9.2X2, I have:

80 all

color 80 hash 0 stream 0,2,4,6,8
color 80 hash 1 stream 0,2,4,10,12
color 80 hash 2 stream 0,2,4,14,16
color 80 hash 3 stream 0,2,4,18,20
color 80 hash 4 stream 0,2,4,22,24
color 80 hash 5 stream 0,2,4,26,28
color 80 hash 6 stream 0,2,4,30,32
color 80 hash 7 stream 0,2,4,34,36

Snort listens to streams 6,10,14, etc.
Bro listens to streams 8,12,16, etc.
Streams 0,2,4 are for tcpdump like applications.

For a while I just had Bro listening on stream 4, and used some magic that Seth helped me with to have 6 workers listening to it, although he now tells me that it’s a terrible way to do things, so I won’t pain him by posting it here now - I think I have previously if you dig around a bit in the list archives.

(However, I’ve run out of useful cores on my box hosting the DAG, so I’m going to be taking a different approach, once I get the round tuits and meeting-free time - snort will be booted off this box and onto another one.)

Mike

11

Yeah. I was talking to our system admins, and we can’t to this because reasons…

We may be able to replicate the hash for bro and snort with our DAG (7.5), but as it turns out, we are also running low on cores on that box. So we are much better off trying to get new hardware to accomplish this.

I appreciate all the feedback. You guys are always very helpful with these things.

Thanks Bros,
Ben