[Bro] PF_Ring and Bro - packet loss

[Adam Pumphrey]

Your broctl status output shows Bro is in standalone mode and not configured to take advantage of pf_ring.  You'll need to configure a local cluster with the pf_ring specific options set for the monitoring interface/worker.   https://www.bro.org/sphinx-git/configuration/index.html#using-pf-ring <https://www.bro.org/sphinx-git/configuration/index.html#using-pf-ring>

Something like this might work in your case; notice the lb_method and lb_procs settings for the worker:

[manager]
type=manager
host=127.0.0.1

[proxy-1]
type=proxy
host=127.0.0.1

[worker-1]
type=worker
host=127.0.0.1
interface=eth0
lb_method=pf_ring
lb_procs=2

I think you need at least 2 lb_procs for pf_ring to provide any performance gain.  You can also set cpu affinity for the worker processes; this is recommended for better performance and cluster stability, but not required.  If you do be sure to specify only physical cpu/core ID’s.  I believe the general rule of thumb is to leave half of your physical cores freed up for the OS and other Bro processes.  For example: 

pin_cpus=2,3		# assumes a single quad-core with core ID’s 0-3

There are a few more pf_ring specific options available in BroControl’s config file.  You can check them out here https://www.bro.org/sphinx/components/broctl/README.html#pfringclusterid <https://www.bro.org/sphinx/components/broctl/README.html#pfringclusterid>

You might want to give “broctl capstats” and the capture-loss Bro script a try also; both are really helpful with troubleshooting traffic capture issues.  

-Adam


> On Sep 11, 2015, at 2:38 PM, nathanael rayborn <nathanael.rayborn at gmail.com> wrote:
> 
> I'm experiencing high packet loss (15% -50%) with Bro 2.4 compiled with PF_Ring. PFcount (pfcount -i eth0 -e 1) shows 0% packet loss while /proc/net/pf_ring/PID shows the same number of dropped packets as broctl netstats. The github link contains all changes and performance steps I've taken so far along with output from PFcount, broctl, and ethtool. Has anyone else experienced similar performance issues or have recommendations to get my dropped packets as close to 0% as possible? Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150911/3f4d3691/attachment.html