See here for this error : Cannot define table bogonsv6: Cannot allocate memory

bingo600

Are you getting this error/alarm ?
Note: The line numbers could be different , but the key message is : bogonsv6: Cannot allocate memory

There were error(s) loading the rules: /tmp/rules.debug:35: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [35]: table <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-01 14:49:30

Seems like this is a spreading error

Increase the bogons/alias space as described here
https://forum.pfsense.org/index.php?topic=145990.msg793804#msg793804

/Bingo

LaUs3r

same here….no changes so far to the config. It appeared this morning. I upgraded afterwards to 2.4.3, but the error still persists. I got 8GB RAM and increased the Firewall Maximum Table Entries to 1.000.000. No effect.
Reboot did not help either.

bingo600

Have you checked that the table is increased ?

My first attempt did not seem to be "taken" , and pfsense was still showing 200K entries (greyed … default)

Note: I'm still on 2.4.2-p1 , but got the error too

/Bingo

LeiShen

I got this error too - just now :(
I increased the bogons/alias space as described in the thread link above and rebooted.
Dumb Question: How do I test if it fixed this issue?

bingo600

@LeiShen:

.
Dumb Question: How do I test if it fixed this issue?

I'd excpect : if you didn't get the error on boot (the alarm bell at top) , it has been fixed

/Bingo

LaUs3r

mmmh, I did now 2 additional things and the issue disappeared:

cleared my snort alerts
reboot via console and not webui

After an additional reboot, I got no notification anymore strange

njh

Hi,

I have also just started getting these errors. A few days ago I upgraded to pfsense 2.4.3.
I have the Bogon Networks Update Frequency set to 'Monthly' - so maybe the bogonsv6 table updated on the 1st April and triggered this problem?

Looking at Diagnostics -> Tables -> bogonsv6 it reports:

"Table last updated on Mon Apr 2 04:50:01 2018 GMT. 95,955 records."
(I have refreshed it manually today)

That is a lot of rows!

Having set the 'Firewall Maximum Table Entries' to 500000 and rebooting, the errors have stopped.
I guess pfsense might need a new higher default?

jimp

We are increasing the default to 400k

https://redmine.pfsense.org/issues/8417

bingo600

@jimp:

We are increasing the default to 400k

https://redmine.pfsense.org/issues/8417

Thank you jimp :D :D

/Bingo

revengineer

On my system with 8 GB RAM, the set default is 2,000,000 entries. This is a v2.4.2_1 install with upgrade to v2.4.3.

ryan87

@revengineer:

On my system with 8 GB RAM, the set default is 2,000,000 entries. This is a v2.4.2_1 install with upgrade to v2.4.3.

Did you set it to 2,000,000? The description seems to claim the current value is the default if you manually set it. I added a note to the bug linked by jimp.

Can anyone elaborate on how (or if) the filter reload fails? What happens if I reboot a firewall right now? I've gotten notifications from a couple firewalls already and I was still able to log in to update the setting. Is it possible for me to get locked out? IE: Should I be proactively updating the setting on all firewalls ASAP?

revengineer

@ryanjaeb:

@revengineer:

On my system with 8 GB RAM, the set default is 2,000,000 entries. This is a v2.4.2_1 install with upgrade to v2.4.3.

Did you set it to 2,000,000? The description seems to claim the current value is the default if you manually set it. I added a note to the bug linked by jimp.

Can anyone elaborate on how (or if) the filter reload fails? What happens if I reboot a firewall right now? I've gotten notifications from a couple firewalls already and I was still able to log in to update the setting. Is it possible for me to get locked out? IE: Should I be proactively updating the setting on all firewalls ASAP?

Nope, I did not touch the value. Underneath the entry field it reads:"Note: Leave this blank for the default. On this system the default size is: 2000000" So it seems that the value is system specific. I assume that it is related to memory, but it is an assumption only.

cybrnook

@revengineer:

@ryanjaeb:

@revengineer:

On my system with 8 GB RAM, the set default is 2,000,000 entries. This is a v2.4.2_1 install with upgrade to v2.4.3.

Did you set it to 2,000,000? The description seems to claim the current value is the default if you manually set it. I added a note to the bug linked by jimp.

Can anyone elaborate on how (or if) the filter reload fails? What happens if I reboot a firewall right now? I've gotten notifications from a couple firewalls already and I was still able to log in to update the setting. Is it possible for me to get locked out? IE: Should I be proactively updating the setting on all firewalls ASAP?

Nope, I did not touch the value. Underneath the entry field it reads:"Note: Leave this blank for the default. On this system the default size is: 2000000" So it seems that the value is system specific. I assume that it is related to memory, but it is an assumption only.

Not sure that is the case. My system has 32GB of RAM, and a clean install on 2.4.3 yielded me a 200,000 default value. Hence my thread on the issue :-)

revengineer

@cybrnook:

Not sure that is the case. My system has 32GB of RAM, and a clean install on 2.4.3 yielded me a 200,000 default value. Hence my thread on the issue :-)

I saw your memory and that puzzled me too. Maybe it's CPU based or a combination of RAM and CPU.

jimp

The old default for everyone was 200,000, no matter how much memory you had. The text by the option that lists the "default" value appears to be incorrectly listing whatever the current active value is in pf, not the default value.

breakaway

I just thought I'd add my 2 cents to this.

I'm responsible for 40-50 pfSense installs, most of them are 2.3.x and some are 2.4.x

The most heavily utilised ones are running fine; But I recently started getting this error two of our installs.

First one is a small office with about 15 users. The second one is a very, very small office with 1-2 users.

The error in the system log reads

/rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [19]: table <bogonsv6> persist file "/etc/bogonsv6"
/rc.filter_configure_sync: New alert found: There were error(s) loading the rules: /tmp/rules.debug:26: cannot define table AUSPRODDCK1: Cannot allocate memory - The line in question reads [26]: table <ausproddck1> { 10.10.10.10 }</ausproddck1></bogonsv6>

The 2nd line above seems to relate to a port forward.

The users on site have not really mentioned any issues with connectivity.

Both pfSense installs are running on Intel Celeron N3150 (AES-NI capable) with 4GB RAM and at least a 64GB SSD, so its not a low spec box by any means.

I have gone to System > Advanced > Firewall/NAT and updated "Firewall Maximum Table Entries" to 1,000,000 - seems to be OK for the last few hours. Before that the system log was full of "cannot allocate memory" events.

Ironically, these two machines having issues are on the least utilised out of our fleet. We have idnetical equipment in offices with 100+ staff and our datacenter routing/firewalling is also handled by pfSense - those instances of pfsense have no issue, and they're pushing 200 mbps all day every day at a bare minimum. Of these 2 pfSenses having this problem, one is 2.3.3-RELEASE (amd64) and the other is 2.4.1-RELEASE (amd64).

The only difference between the "working" pfsenses and the ones that had issues with allocating memory is both these pfSenses use PPP - one uses PPPoE and the other one uses PPP (cellular wan). Not sure if related.

Thought I'd add that I'm not running any packages like Snort or Suricata or anything. All these 2 pfSense instances do is provide NAT so that users can connect out to the internet. The hardware is good, I stress tested it just the other day.

AR15Dude

I'm confirming that after I upgraded from 2.4.2_1 to 2.4.3, I had the same type of error:

Filter Reload
There were error(s) loading the rules: /tmp/rules.debug:19: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [19]: table <bogonsv6> persist file "/etc/bogonsv6"
@ 2018-04-09 09:15:46

Changing the Firewall Maximum Table Entries from 200000 to 500000 and rebooting solved the problem.

nhs7000

Same happened to me after I upgraded to version 2.4.3

Increasing the firewall maximum table entries fixed the problem for now.

sot010174

Just happened today with my v2.1 firewall. The firewall would not route in this state. As I was under pressure from clients, I ended up disabling all IPV6 conectivity (Unchecking Allow IPV6) as a drastic solution. Seems to work fine now. I'll wait a bit before raising the table limit from 200k to 400k and re-enabling the IPV6.

Accessing the firewall via SSH revealed /etc/bogonsv6 having 97k lines (entries). All other tables combined barely exceeds 5k entries.