Nil*_*ann 5 networking linux routing icmp ip-routing
如果 Linux 主机接收并接受 ICMP 重定向（accept_redirects=1在有问题的接口上），该路由被缓存和观察多长时间？我可以降低那个时间吗？
我之所以这么问，是因为我有许多系统被虚假路由毒害，这些路由很可能源于不幸的 ICMP 重定向：
$ ip route get 10.2.2.2
10.2.2.2 via 10.2.2.2 dev eth0 src 10.1.1.2
cache <redirected>
并且他们根本没有忘记重定向，即使在收到最后一个 ICMP 重定向后超过 12 小时！我必须手动ip route flush cache删除条目并恢复正确的路线：
$ ip route get 10.2.2.2
10.2.2.2 via 10.1.1.1 dev eth0 src 10.1.1.2
cache
我知道首先发送、接收和接受 ICMP 重定向的方式和原因，这个问题与此无关。
我认为这与问题无关，但这里有一些细节：
我们有一个内部网络，比如说 10.1.0.0/16。其中一台机器 10.1.1.1 是 OpenVPN 服务器，远程客户端在 10.2.0.0/16 内获得分配的地址。其他内部机器有一个静态路由 10.0.0.0/8 --> 10.1.1.1。它故意比 10.2.0.0/16 更宽，因为 VPN 服务器将来可能会服务更多的客户端。
不幸的是，我们的配置管理将更广泛的静态路由 10/8-->10.1.1.1 也推送到 VPN 服务器本身，它被建立为 10/8-->eth0。这种不必要的路线通常没有任何效果。
在正常情况下，此设置工作正常。但后来发生了这样的事情：
send_redirects=1在其内部接口上有 eth0，并且由于不幸的路由 10/8->eth0，它将相应的 ICMP 重定向发送回 10.1.1.2accept_redirects=1在其内部接口上缓存 ICMP 重定向中宣布的路由，并拼命向内部网络发送 10.2.2.2 的 ARP 请求：不久之后，VPN 服务器建立其 VPN 路由并停止发送重定向，所有其他 VPN 连接都正常工作。
到现在为止还挺好。我想我明白发生了什么以及为什么，我知道各种短期（ip route flush cache在内部主机上）和长期（当然摆脱 VPN 服务器上更广泛的路由；但我们也可以accept_redirects=0在内部主机上设置）的补救方法; 或send_redirects=0在 VPN 服务器上设置），所以这不是我的问题。
笔记：
accept_redirects=1），因为它也开始向目的地发送本地 ARP 请求。但至少只要那些没有得到答复，它就会继续将 IP 数据包发送到原始下一跳，并且ip route get 10.2.2.2仍然显示原始的、未重定向的下一跳。net.ipv4.route.gc_interval可能在 2.6.38 (2011) 之前管理了这个，但从那以后就没有了。ICMP 重定向缓存的时间由 gc_timeout ( /proc/sys/net/ipv4/gc_timeout) 指定。但请注意，超时从最后一个活动开始，因此在某些情况下，故障可能会永远持续下去。
我不确定是否所有 Ubuntu 发行版都有此功能。