☰

内核：dst 缓存溢出

tag-icon • tag-icon networking kernel overflow
内核：dst 缓存溢出

我有时会遭遇持续不断的洪水，但洪水通常程度较低。我经常发现我的系统在网络上完全没有响应，而我在日志中也观察到了这种情况，

kernel: [455951.513204] __ratelimit: 1771 callbacks suppressed
kernel: [455951.513207] dst cache overflow

我对此进行了大量研究，但没有找到合适的答案。顺便说一下，我在 Debian 6 系统上运行内核版本 2.6.32-5-amd64。

答案1

这一页 （http://bluecoat.force.com/knowledgebase/articles/Solution/CB-IPdestinationcacheoverflowdstcacheoverflowipdstcachemessage) 中有关于增加与此消息相关的缓存的说明 - 如下所示。

但是，如果您“处于持续洪泛状态”，增加此缓存可能只会使洪泛问题更加严重，最好在问题进入您的系统之前解决它。也许可以通过在路由器/防火墙处丢弃有问题的流量。

使用以下步骤评估情况并更改目标缓存的大小。以下所有命令均假定您已连接到 VAP 控制台。

检查当前情况：cat /proc/slabinfo |grep ip_dst_cache

和设置： cat /proc/sys/net/ipv4/route/max_size

设置一个新的最大值（即 2621440）并验证它是否被接受：echo 2621440 > /proc/sys/net/ipv4/route/max_size; cat /proc/sys/net/ipv4/route/max_size

再次检查当前情况：cat /proc/slabinfo | grep ip_dst_cache

过一会儿，CPU 负载就会下降。

客户可能遇到的另一个问题是防火墙连接表已满。发生这种情况时，系统需要更多内存。

如果防火墙未部署在网络核心部分，则不应发生此问题。如果客户仍然看到这种情况，则可能是由于有人试图通过使用欺骗的 IP 地址或类似方式进行 nmap 扫描来欺骗内部网络中的 IP 地址。对于服务器和/或外围防火墙前面的典型数据中心，不应观察到这种情况。原因可能是某种 DoS/DDoS 攻击。无论问题的来源是什么，上述过程都可以解决问题。

所有 sysctl 参数都是在启动时通过 /etc/init.d/network 脚本加载的。命令是：

sysctl -e -p /etc/sysctl.conf

该脚本在检查点进程之前启动，这就是为什么更改在重启后无法继续存在的原因。

安装 Check Point 后，当防火墙通过 fwstart 脚本启动时，此值配置为 524288。因此，即使我们在 /etc/sysctl.conf 文件中更改了该参数，并且 Linux 在启动时对其进行了配置，当防火墙启动时，此值也会再次更改。然后，如果我们只是停止 (cpstop) 并启动 (cpstart) 防火墙，这些值将再次更改。

Check Point 正在更改此值 - $ cd $FWDIR/bin $ grep -n max_size fwstart echo 524288 > /proc/sys/net/ipv4/route/max_size

为了确保内核在重新启动或防火墙重新启动后具有正确的值，请执行以下操作：

  1. 配置以下文件以反映正确的值

    • /etc/sysctl.conf

  2. 禁用 fwstart 脚本中的行 ($FWDIR/bin/fwstart)

    回显 524288 > /proc/sys/net/ipv4/route/max_size

注意：应用 Check Point HFA 或升级 Check Point 后，fwstart 脚本可能会被覆盖。

要获取实时变化，请使用以下命令：

$ sysctl -w net.ipv4.route.max_size = 2097152

相关内容