Linux 内核中的邻居缓存并不像人们想象的那么简单。我将尝试解释它的一些怪癖。
相邻缓存条目实际上完全从缓存中掉出或只是被标记为陈旧/无效之间存在细微差别。在 base_reachable_time/2 和 3*base_reachable_time/2 之间的某个时间点，该条目仍会在缓存中，但会被标记为 STALE 状态。您应该可以使用“ip -s neighbor show”查看状态，
pherricoxide@midigaurd:~$ ip -s neighbor list
192.168.42.1 dev eth0 lladdr 00:25:90:7d:7e:cd ref 2 used 184/184/139 probes 4 STALE
192.168.10.2 dev eth0 lladdr 00:1c:23:cf:0b:6a ref 3 used 33/28/0 probes 1 REACHABLE
192.168.10.1 dev eth0 lladdr 00:17:c5:d8:90:a4 ref 219 used 275/4/121 probes 1 REACHABLE
当处于 STALE 状态时，如果我 ping 192.168.42.1，它将立即将数据包发送到 00:25:90:7d:7e:cd。大约一秒钟后，它通常会向拥有 192.168.42.1 的人发送一个 ARP 请求，以便将其缓存更新回 REACHABLE 状态。但是，为了让事情更加混乱，内核有时会根据来自更高级别协议的积极反馈来更改超时值。这意味着如果我 ping 192.168.42.1 并且它回复了，那么内核可能不会打扰发送 ARP 请求，因为它假定 pong 意味着它的 ARP 缓存条目是有效的。如果条目处于 STALE 状态，它也会被它碰巧看到的未经请求的 ARP 回复更新。
现在，在大多数情况下，您只需要担心处于 STALE 状态的条目。 为什么需要将条目从缓存中完全删除？内核通过仅更改缓存条目的状态而不是始终将它们实际删除并将它们添加到缓存中来努力不破坏内存。
如果你真的坚持认为它不仅会被标记为 STALE，而且实际上会从邻居缓存使用的 hashmap 中删除，那么你必须注意一些事情。首先，如果该条目未被使用并且陈旧 gc_stale_time 秒，则它应该有资格被删除。如果 gc_stale_time 通过并将条目标记为可以删除，则在垃圾收集器运行时（通常在 gc_interval 秒后）将其删除。
现在的问题是 如果被引用，则不会删除邻居条目。您将遇到的主要问题是来自ipv4 routing table 的参考。有很多复杂的垃圾收集东西，但需要注意的重要一点是，路由缓存的垃圾收集器每 5 分钟才会使条目过期（/proc/sys/net/ipv4/route/gc_timeout秒）在很多内核上。这意味着必须将邻居条目标记为过时（可能需要 30 秒，具体取决于 base_reachable_time），然后在路由缓存停止引用该条目之前必须经过 5 分钟（如果您是幸运），然后是 gc_stale_time 和 gc_interval 的某种组合，然后才真正清理干净（因此，总的来说，大约需要 5-10 分钟）。
总结：您可以尝试将/proc/sys/net/ipv4/route/gc_timeout 减小到更短的值，但是变量很多，很难全部控制。通过不过早删除缓存中的条目（而只是将它们标记为 STALE 甚至 FAILED），我们付出了很多努力来使事情运行良好。