我一直处于持续的洪水之下，一般都是低的。 我观察到我的系统经常在networking上完全没有响应，而我在日志中观察到这一点，
kernel: [455951.513204] __ratelimit: 1771 callbacks suppressed kernel: [455951.513207] dst cache overflow 我已经研究了很多，但没有find任何合适的答案。 我正在Debian 6系统上运行内核版本2.6.32-5-amd64。
这个页面（ http://bluecoat.force.com/knowledgebase/articles/Solution/CB-IPdestinationcacheoverflowdstcacheoverflowipdstcachemessage ）有增加与这个消息相关联的caching的指令 – 引用如下。
但是，如果你是在“持续洪水”的情况下增加这个caching，可能只会使泛滥问题变得更糟，在问题到达你的系统之前解决这个问题可能会更好。 也许在路由器/防火墙上放置违规stream量。
使用以下过程来评估情况并更改destcaching的大小。 以下所有命令都假定您已连接到VAP控制台。
检查当前的情况：cat / proc / slabinfo | grep ip_dst_cache
和设置：cat / proc / sys / net / ipv4 / route / max_size
设置一个新的最大值（即2621440）并validation它是否被接受：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负载应该下降。
客户可能遇到的另一个问题是防火墙连接表已满。 发生这种情况时，系统需要更多的内存。
如果防火墙未部署在networking核心部分，则不应出现此问题。 如果客户仍然看到这种情况，可能是有人试图通过伪造IP地址或类似的东西来进行nmap扫描来欺骗内部networking中的IP地址。 对于服务器和/或外围防火墙之前的典型数据中心，不应该被观察到。 原因可能是某种DoS / DDoS攻击。 不pipe问题的来源如何，上述程序都可以解决问题。
所有的sysctl参数在启动时通过/etc/init.d/network脚本加载。 该命令是：
sysctl -e -p /etc/sysctl.conf
此脚本在Check Point进程之前启动，这就是为什么这些更改无法在重新启动后存活。
当安装Check Point时，当防火墙以fwstart脚本启动时，该值被configuration为524288。 因此，即使我们更改/etc/sysctl.conf文件中的参数，并且Linux在启动时对其进行configuration，但防火墙启动时，此值会再次更改。 然后，如果我们只是停止（cpstop）并启动（cpstart）防火墙，这些值将被再次更改。
Check Point正在改变这个值 – $ cd $ FWDIR / bin $ grep -n max_size fwstart echo 524288> / proc / sys / net / ipv4 / route / max_size
要确保在重新启动或防火墙重新启动后内核将具有正确的值，请执行以下操作：
configuration下面的文件以反映正确的值
- /etc/sysctl.conf中
在fwstart脚本中禁用行（$ FWDIR / bin / fwstart）
echo 524288> / proc / sys / net / ipv4 / route / max_size
注意：应用Check Point HFA或升级Check Point后，fwstart脚本可能会被覆盖。
要获得实时更改，请使用以下命令：
$ sysctl -w net.ipv4.route.max_size = 2097152