如果 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。這種不必要的路線通常不會產生任何效果。
在正常情況下，這個設定工作得很好。但後來發生了這樣的事：
- VPN 伺服器 10.1.1.1 重新啟動
- 某些其他內部主機（例如 10.1.1.2）嘗試聯繫 VPN 用戶端（例如 10.2.2.2），就像 VPN 伺服器已建立其 IP 堆疊一樣，但在 OpenVPN 啟動之前，因此不會到達 10.2.0.0/16尚未建立
- VPN 伺服器
send_redirects=1在其內部介面 eth0 上，並且由於不幸的路由 10/8->eth0，它會將相應的 ICMP 重定向發送回 10.1.1.2 - 10.1.1.2
accept_redirects=1在其內部介面上快取了 ICMP 重定向中公佈的路由，並拼命向內部網路發送針對 10.2.2.2 的 ARP 請求：
不久之後，VPN 伺服器建立其 VPN 路由並停止發送重定向，並且所有其他 VPN 連線都運作正常。
到目前為止，一切都很好。我想我明白髮生了什麼以及為什麼，並且我知道短期（ip route flush cache在內部主機上）和長期（當然擺脫VPN伺服器上更廣泛的路由；但我們也可以accept_redirects=0在內部主機上設置）的各種補救方法；或者send_redirects=0在VPN伺服器上設定），這樣就可以了不是我的問題。
筆記：
- Ubuntu 核心 3.13.0-141
- Ubuntu 核心 4.4.0-116 的行為似乎有所不同：它還接受 ICMP 重定向（如果
accept_redirects=1），因為它也開始向目的地發送本地 ARP 請求。但至少只要這些沒有得到答复，它就會繼續將 IP 封包發送到原始下一躍點，並且ip route get 10.2.2.2仍然顯示原始的、非重定向的下一躍點。 - 根據https://vincent.bernat.im/en/blog/2011-ipv4-route-cache-linux，
net.ipv4.route.gc_interval可能在 2.6.38 (2011) 之前適用，但此後不再適用。
答案1
ICMP 重定向快取的時間由 gc_timeout ( ) 指定/proc/sys/net/ipv4/gc_timeout。但請注意，超時從最後一個活動開始，因此在某些情況下，故障可能會永遠持續下去。
我不確定是否所有 Ubuntu 發行版都有此功能。