Bro performance issues

What nic are people using to test PF_RING on bro? The one I using is a Broadcom Corporation NetXtreme II BCM57711 10-Gigabit PCIe.

The NIC shouldn't matter, the load balancing is all done in the kernel.

  .Seth

Found the problem. getenv is not work on linux, sigh.

Bill Jones

Oh, what distribution is this? I guess this is totally breaking the clustering support in pf_ring's libpcap wrapper.

  .Seth

Its Redhat 5.7.

Now I know that there is a problem with getenv I should be able to track the problem down the exact nature of the problem down.

Attached is a patch to fix the getenv problem. The were tow PCAP env variables that need a shell export statement.

This will make PF_RING work so long as all the data is going into one interface or bonded interface.

Bill Jones

run-bro-export-patch (371 Bytes)

What shell are you using? There is something messed up because those environment variables are already set and I think don't think you should need those lines in run-bro. I haven't seen anyone else that has needed those lines at least.

  .Seth

Seth, here is my configuration:

Bro 2.0beta

Running on Debian GNU/Linux 6.0

broctl config | grep pfring

pfringclusterid = 21

ldd bro

linux-vdso.so.1 => (0x00007fff41be1000)

libpcap.so.1 => /usr/local/pfring/lib/libpcap.so.1 (0x00007f3a74c0c000)

libpthread.so.0 => /lib/libpthread.so.0 (0x00007f3a749f0000)

libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007f3a7479a000)

libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f3a743f9000)

libmagic.so.1 => /usr/lib/libmagic.so.1 (0x00007f3a741db000)

libz.so.1 => /usr/lib/libz.so.1 (0x00007f3a73fc3000)

libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f3a73d8c000)

libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f3a73a78000)

libm.so.6 => /lib/libm.so.6 (0x00007f3a737f5000)

libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f3a735df000)

libc.so.6 => /lib/libc.so.6 (0x00007f3a7327e000)

/lib64/ld-linux-x86-64.so.2 (0x00007f3a74e63000)

libdl.so.2 => /lib/libdl.so.2 (0x00007f3a73079000)

cat /proc/net/pf_ring/*

PF_RING Version : 5.0.0 (Revision: exported)

Ring slots : 4096

Slot version : 13

Capture TX : Yes [RX+TX]

IP Defragment : No

Socket Mode : Standard

Transparent mode : Yes (mode 0)

Total rings : 0

Total plugins : 0

for i in $(pidof bro); do echo -n "Pid:$i " ; cat /proc/$i/environ | grep -w ‘PCAP_PF_RING_CLUSTER_ID’; done

Shows me that all instances exported the PCAP_PF_RING_CLUSTER_ID (also tested PCAP_PF_RING_USE_CLUSTER_PER_FLOW)

Again, Traffic does not split between the workers, they see the same packets.

What do you get for broctl status?

Name Type Host Status Pid Peers Started

manager manager localhost running 30614 3 06 Nov 18:01:09

proxy-1 proxy localhost running 30645 3 06 Nov 18:01:11

worker-1 worker localhost running 30688 2 06 Nov 18:01:13

worker-2 worker localhost running 30689 2 06 Nov 18:01:13

Wow, well I'm quite sure that PF_RING is not being used because you
don't have /proc/net/pf_ring entries, but I have no idea why as the
workers are obviously running and you have libpcap compiled with
pf_ring support.

Did you see the patch I sent to the list to export the PF_RING averment variables in run_bro. It should fix your problem.

If just sent info@bro-ids.org three patch's to fix a few minor compatibility issues do to python version difference. A patch to export the PF_RING variables so that pf_ring libpcap can see PF_RING environment variables. A patch to serializes the bro works startup when opening multiple network interfaces when using PF_RING.

FYI

Seth

I have been able to get 8 works reading 8 interfaces to work properly with PF_RING. There is a limit of 8 slots per cluster id in PF_RING. There a good chance that it can be increased with out any performance losses, that will have to be tested. There may also may be some internal limitation with bro when the number of workers go above 8.

Bill Jones