Linux ARP Entries – When Do STALE Entries Become FAILED?

arplinux

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

A host in the lan (b8:20:00:00:00:00) had IP address 10.64.42.121. This IP is now invalid and this same host's IP is now 10.64.42.157 (new DHCP lease).

I try to figure out when the old arp cache entry will change state to FAILED (providing nobody attempts to contact the IP).

The last time the entry has been confirmed is 6341s ago (1h45 ago). This is greater than 60s. Why is this entry still in STALE state and when will it change to FAILED state (or be deleted) (if nobody ever tries to use the entry)?

Best Answer

gc_stale_time is the right parameter to tweak to evict STALE entries from the ARP table. But there is more:

ARP garbage collection is run in the periodic neigh_periodic_work function. The interval can be tweaked via /proc/sys variable gc_interval.

It will then check that there is at least gc_thresh1 entries in the ARP table. This will avoid consuming extra CPU cycles if the table is too small to see any real benefit in terms of memory.

In your case, I suspect gc_thresh1 is the variable you'll want to tweak. lowering it will force the GC to run more frequently. This may have a negative impact on the performance depending on the run interval though.

Note: gc_thresh3 is a hard threshold. The table will never keep more entries than this value. Tweak it with care.

Related Topic