linux – 从未使用STALE arp条目何时变为FAILED?

前端之家收集整理的这篇文章主要介绍了linux – 从未使用STALE arp条目何时变为FAILED?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
root@openwrt:~# ip -s -s -4 neigh show dev lan
10.64.42.121 lladdr b8:20:00:00:00:00 used 6387/6341/6313 probes 1 STALE
10.64.42.157 lladdr b8:20:00:00:00:00 used 24/813/19 probes 1 STALE
10.64.42.12  used 29066/30229/29063 probes 6 Failed
10.64.42.1 lladdr e8:00:00:00:00:00 ref 1 used 10/5/5 probes 1 REACHABLE


root@openwrt:~# cat /proc/sys/net/ipv4/neigh/default/gc_interval 
30

root@openwrt:~# cat /proc/sys/net/ipv4/neigh/default/gc_stale_time
60

root@openwrt:~# cat /proc/sys/net/ipv4/neigh/lan/gc_stale_time
60

局域网中的主机(b8:20:00:00:00:00)具有IP地址10.64.42.121.此IP现在无效,同一主机的IP现在为10.64.42.157(新的DHCP租约).

我试图找出旧的arp缓存条目何时将状态更改为Failed(提供没有人尝试联系IP).

该条目的最后一次确认是6341年前(1小时45分钟前).这大于60秒.为什么此条目仍处于STALE状态,何时更改为Failed状态(或被删除)(如果没有人尝试使用该条目)?

解决方法

gc_stale_time是调整从ARP表中逐出STALE条目的正确参数.但还有更多:

ARP垃圾回收在定期neigh_periodic_work功能中运行.可以通过/ proc / sys变量gc_interval调整间隔.

然后它将检查是否有at least gc_thresh1 entries in the ARP table.如果表太小而无法在内存方面看到任何实际好处,这将避免消耗额外的cpu周期.

在你的情况下,我怀疑gc_thresh1是你想要调整的变量.降低它将迫使GC更频繁地运行.但这可能会对性能产生负面影响,具体取决于运行间隔.

注意:gc_thresh3是硬阈值.该表永远不会保留比此值更多的条目.仔细调整它.

猜你在找的Linux相关文章