# Adjusting Bro snaplen caused multiple Security Onion systems to sporadically kernel panic **URL:** \ **Category:** Zeek\ **Created:** [August 4, 2015, 2:18pm UTC](https://community.zeek.org/t/adjusting-bro-snaplen-caused-multiple-security-onion-systems-to-sporadically-kernel-panic/3749 "2015-08-04T14:18:52Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Kevin\_Branch](https://avatars.discourse-cdn.com/v4/letter/k/d26b3c/32.png) [@Kevin\_Branch](https://community.zeek.org/u/Kevin_Branch)\ **Post date:** [August 4, 2015, 2:18pm UTC](https://community.zeek.org/t/adjusting-bro-snaplen-caused-multiple-security-onion-systems-to-sporadically-kernel-panic/3749/1 "2015-08-04T14:18:52Z")
Hi Seth, 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: [https://groups.google.com/d/msg/security-onion/qDU23hx6Q5g/xFeRDJbi9LsJ](https://groups.google.com/d/msg/security-onion/qDU23hx6Q5g/xFeRDJbi9LsJ) … 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: [https://groups.google.com/forum/#!searchin/security-onion-testing/kernel$20panic/security-onion-testing/H\_21-0DGM6E/qnSt0BPA7lMJ](https://groups.google.com/forum/#!searchin/security-onion-testing/kernel%2420panic/security-onion-testing/H_21-0DGM6E/qnSt0BPA7lMJ) Thanks again for a great tool! Kevin ---
**Author:** ![Kevin\_Branch](https://avatars.discourse-cdn.com/v4/letter/k/d26b3c/32.png) [@Kevin\_Branch](https://community.zeek.org/u/Kevin_Branch)\ **Post date:** [August 12, 2015, 12:08am UTC](https://community.zeek.org/t/adjusting-bro-snaplen-caused-multiple-security-onion-systems-to-sporadically-kernel-panic/3749/2 "2015-08-12T00:08:37Z")
Seth, Is it still OK to use “redef snaplen = **N** ;” in my local.bro file if I want to drop Bro’s default snaplen to save PF\_RING memory? If so, how low would you say “ **N** ” can be set to safely when jumbo frames are not involved? I got burned with sporadic kernel panics when I set N to **1514**. I’d sure appreciate your input. Kevin ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [August 12, 2015, 12:43am UTC](https://community.zeek.org/t/adjusting-bro-snaplen-caused-multiple-security-onion-systems-to-sporadically-kernel-panic/3749/3 "2015-08-12T00:43:49Z")
Yes, it should be fine to do that but I really don’t know how that change in snap length affects pf\_ring. It may not actually do anything (except apparently cause crashes!?).   .Seth ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:42pm UTC](https://community.zeek.org/t/adjusting-bro-snaplen-caused-multiple-security-onion-systems-to-sporadically-kernel-panic/3749/4 "2022-05-06T15:42:56Z")