Since getting involved with Security Onion over a year ago, I have really grown to appreciate the value that Bro brings to the NSM scene. Thanks to you and the rest of the Bro community for your work on this!
Not long ago I noticed that my Bro instances were eating up way more memory than necessary for my non-jumbo-frame environment because of the default snaplen of 8192, so based on what I saw in your comment here a couple of years ago:
… I added “redef snaplen = 1514;” to my local.bro file on 6 different Security Onion systems and reclaimed a heap of memory. At first it seemed to work great but after a short while three completely separate systems start throwing kernel panics. I finally traced it down to the snaplen change in Bro and upon raising the snaplen from 1514 to 1600, all kernel panics completely stopped.
I am looking for your recommendation as to how low should be considered “safe” to change the Bro snaplen to for non-jumbo-frame environments, as well as to confirm that the old redef method I used to do this is still what should be used with modern Bro.
I brought up my kernel panic issues on the Security Onion support list and am hoping to report back to them how changing Bro’s snaplen can be safely used to save memory on systems where numerous Bro instances and/or large PF_RINGs are in use. Here is that thread for your reference:
Thanks again for a great tool!