What happens when the state table is full? <Solved>
-
ATT blessed me with a new router thing and it has a smaller state table than the old one. I reduced the state table in pfSense to 8100, the router has a table that is 8192.
How does pfSense handle running out of states?I found many old threads about pfSense crashing, hanging or doing other non-desirable things, but those were all older versions. I am running 24.11.
o||||o
7100-1u -
This post is deleted! -
@tinfoilmatt When the state table is full no new states can be created.
It's kind of painful for performance, but there are no known bugs on hitting the state limit. That's expected to just work.Also, the default state limit is rather more than 8192 states. I believe the default depends on memory size, but should be at least 25600.
-
@kprovost Default states for pfSense would be plenty, but I have to account for the ATT router that is fixed at 8192.
On a side note, has anyone tried the programable XG-PON that emulates the ATT equipment in a Netgate device? A friend is getting one to see if it works. If it does, I may go that route and remove the ATT router entirely.
-
@kprovost There's a difference between maximum firewall state table size specifically, and maximum table entries (which includes the firewall state table plus all other system tables). I could be wrong, but I don't believe it's true that the firewall state table 'rejects'/'blocks'/'refuses' new states once it reaches its configured maximum size. Only once it reaches the 'purge all' value (i.e., 120% of the configured maximum size by default) does anything occur—at which point all existing states are flushed all at once.
-
@tinfoilmatt No, that's not how it works. The state limit is implemented through the uma memory allocator. States are allocated from the V_pf_state_z zone: https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf.c#n2796
Limits are set (via ioctl/netlink) here: https://cgit.freebsd.org/src/tree/sys/netpfil/pf/pf_ioctl.c#n2517
Once that limit is hit no new states can be allocated, so new connections will be rejected. Eventually states will time out or be freed and then new states can be allocated.
That state allocator mechanism is also why I say there's a performance impact to hitting the state limit. The uma allocator keeps space per CPU core, but when it's out it will ask other cores if they have space left. So when you're at the limit every allocation attempt will end up blocking other cores for a while, while they check for space.
-
@kprovost Appreciate that explanation. My initial reply deleted for containing bad information about how the state table works (i.e., that it will continue to accept new connections past the configured max limit since it, in fact, does not).
-
Solved the problem. I have a "special" XGS-PON installed now. The ATT router is dark, no longer wasting power. Proudly running with the default 811,000 states.
-
@AndyRH said in What happens when the state table is full? <Solved>:
ATT blessed me with a new router thing and it has a smaller state table than the old one. I reduced the state table in pfSense to 8100,
I'm not convinced crippling pfsense to a similar degree to your second router would help performance. I would have left pfsense settings at their default and only suffered from the ATT router limits (not also an artificial pfsense limit).
@AndyRH said in What happens when the state table is full? <Solved>:
Solved the problem. I have a "special" XGS-PON installed now. The ATT router is dark,
Agree that's the best solution
-
@Patch said in What happens when the state table is full? <Solved>:
I'm not convinced crippling pfsense to a similar degree to your second router would help performance
I did not do it for performance, I did it to stop crashing the ATT router.
Removing the thing is great, slightly improved my latency as a bonus. I am super happy it worked in the 7100 with no problems.
