我们有一台OpenBSD服务器作为防火墙使用着名的pf。 防火墙从一端连接到互联网，另一端连接到本地networking。 我们正在经历连接中断，因为pf正在达到其最大状态数目（即20000），这发生了不到一个小时，然后认为恢复正常。 有无论如何确定正在打开这些国家的主机。 增加pf.conf中的状态数量是否有帮助？
非常感谢
在这里你可以做很多事情。
要查看哪些主机负责大量的状态表条目，可以执行pfctl -vs state 。
要添加更多的状态表条目，你可以做你所build议的（ set limit states成一个更大的数字），但是如果有一个潜在的问题，你可能不想这样做。
您也可以考虑调整状态超时值（ set timeout超时值），可能使用自适应超时，以更快速地摆脱陈旧/陈旧的状态。
有关更多信息，请参见pf.conf的联机帮助页和pfctl的联机帮助页
[参考： 打开PF状态表限制 ]
PF状态表设置了已被授权的连接的限制，从而限制了防火墙接受的新连接的数量。 你可能有多余的带宽可用，但是如果州表中没有空闲容量，那么你的防火墙将成为一个瓶颈。
状态信息的configuration限制可以通过“pfctl”
＃pfctl -sm
国家硬限制10000 src-nodes硬限制10000 碎片硬限制5000 表硬限制1000 表项硬限制200000
上述限制预先将分配的存储器设置为定义的结构，使得它们始终可用，并且还限制了所述数据结构的增长。 如果您的防火墙stream量超过上述设置，则会影响性能。
现在重要的是要监视你的stream量对柜台的影响是否达到上述限制。 通用的“-s info *”输出为我们提供了线索，让我们可以进一步研究防火墙中潜在的瓶颈。
＃pfctl -si
状态：已启用XXXXXXXXXXXXXXXXdebugging：紧急 州表总费率 当前条目34 search96379206 15.2 /秒 插入726196 0.1 / s 删除726162 0.1 /秒
在上面的网关上，连接到两台不常使用的笔记本电脑，相对于10000以上的硬限制 ， 当前条目非常低。 显然， 当前的条目会由于使用而stream动，并且在更繁忙的网关上可能显着地stream动。
[参考： 打开 PF状态表限制 ， 达到打开BSD状态硬限制 ]
从pfctl -si监控的重要计数器是“ 内存 ”计数器。 同样的细节应该可以通过systat pf获得
从连接我们的6个站点的活动网关，我们从标准安装得到以下内容，不修改状态表。
＃pfctl -si | grep内存
内存209230 0.1 / s
该计数器突出显示了PF至less有一个“池（9）”失败的频率。数字越高，到达防火墙的数据包最有可能由于其中一个硬件限制而丢失的频率越高。
我们上面的例子显示了209,230次的内存限制。
下一个检查是使用“vmstat”检查内核内存分配。 为了缩小search范围，我们检查pfstatepl的条目。
下面，我们抓住状态或失败的行（所以我们可以得到列标题）
＃vmstat -m | grep -E“状态|失败”
名字大小请求失败InUse Pgreq Pgrel Npage Hiwat Minpg Maxpg闲置 pfstatepl 296 213123877 209235 5075 1050 0 1050 1050 0 2308 526 pfstatekeypl pfstateitempl
pfstatepl是分配给struct pf_state （/usr/src/sys/net/pf_ioctl.c）的内存标签。失败似乎很重要。
pfctl -vvsi | grep拥塞