Tho*_*mas 35 linux arp linux-kernel
我正在尝试配置ARP年龄超时.我想我应该设置/proc/sys/net/ipv4/neigh/default/base_reachable_time_ms所需的超时.但是,尽管我将其设置为30000毫秒(30秒),但仍需要将近10分钟才能从ARP缓存中删除条目.在阅读了几篇文章后,我发现还有更多的设置会影响超时:
/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout
我不知道该为这些程序编程.该gc_timeout默认为在Linux下5分钟.我把它改为30秒,但我仍然没有看到条目被移除base_reachable_time/2或3*base_reachable_time/2.
如何设置ARP缓存的到期时间？
Phe*_*ide 90
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.大约一秒钟后,它通常会发送一个ARP请求,其中包含192.168.42.1,以便将其缓存更新回REACHABLE状态.但是,为了使问题更加混乱,内核有时会根据更高级协议的正反馈更改超时值.这意味着如果我ping 192.168.42.1并且它回复,那么内核可能不会打扰发送ARP请求,因为它假设pong意味着它的ARP缓存条目有效.如果条目处于STALE状态,它也会被它碰巧看到的未经请求的ARP回复更新.
现在,对于大多数情况,您需要担心的是处于STALE状态的条目.为什么需要完全从缓存中删除条目？内核通过更改缓存条目的状态而不是实际删除并将它们一直添加到缓存中而花费大量精力来不破坏内存.
如果你真的坚持它不仅会被标记为STALE,而且实际上会从邻居缓存使用的hashmap中删除,你必须要注意一些事情.首先,如果该条目尚未使用且对于gc_stale_time秒已过时,则应该有资格将其删除.如果gc_stale_time传递并将条目标记为可以删除,则在垃圾收集器运行时(通常在gc_interval秒之后)将删除它.
现在的问题是,如果正在引用邻居条目,则不会删除邻居条目.您将遇到问题的主要问题是来自ipv4路由表的引用.有很多复杂的垃圾收集内容,但需要注意的重要一点是,路由缓存的垃圾收集器只会在很多内核上每隔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),已经投入了大量精力来使事情表现良好.