We're going to need to change Bro's default snap length before the 2.0 final release or at least do something. I've run into several people now who are having really abysmal performance (dropping packets at relatively low data rate) and when they run with a reduced snaplen the performance immediately improves.
If anyone is seeing apparent performance problems with Bro, add the following line to broctl.cfg:
broargs=-l 9800
You can set the value to match your MTU but you also need to be aware that you must disable some offload features of NICs. More information about the issue can be found at a recent post on the security onion blog.
I think we should add a script-level option snaplen and set it to a
much smaller default, like 8K or 4K. Plus a FAQ entry, linked from the
Quickstart guide, explaining what's going on and what to do.
This is a separate issue that shows up on almost every NIC but I don't know what wrinkles PF_RING introduces. I suppose it could also depend on if you are using PF_RING's DNA drivers or not since I believe that's doing direct memory injection from the NIC which changes the behavior where we are currently seeing trouble.
Just wondering what the final decision was for snaplen in 2.0?
* Reduced snaplen default from 65535 to old default of 8192. The
large value was introducing performance problems on many
systems.
* Replaced the --snaplen/-l command line option with a
scripting-layer option called "snaplen". The new option can also
be redefined on the command line, e.g. ``bro -i eth0
snaplen=65535``.
There's also a related ticket slated for 2.1 that would help with the problems encountered at large snaplens: