ARP Cache Calculator
Estimate ARP cache entry count, memory footprint, and gc_stale_time-driven expiry.
Inputs
Default net.ipv4.neigh.default.gc_stale_time is 60s
Estimated ARP Cache Entries
180
Estimated Cache Memory (KB)
17.58
Stale Timeout (seconds)
60
Est. Total Re-resolutions per Hour
10,800
Step by step
Values used
Hosts on Subnet (active neighbors) = 180; gc_stale_time (seconds) = 60; Memory per ARP Entry (bytes) = 100
ARP cache entries
entries = hosts_on_subnet (bounded by neigh gc_thresh limits)
Estimated ARP Cache Entries
= 180
Estimated Cache Memory (KB)
= 17.58
Stale Timeout (seconds)
= 60
Est. Total Re-resolutions per Hour
= 10,800
How it works
The ARP (or IPv6 neighbor discovery) cache maps IP addresses to MAC addresses for hosts on the same local subnet, growing roughly in proportion to the number of distinct neighbors a host has actually communicated with recently, up to gc_thresh limits. Entries age out after gc_stale_time seconds of inactivity (triggering a re-resolution probe on next use rather than immediate deletion), and each entry carries a small but nonzero kernel memory cost — on subnets with very high host counts (large flat L2 networks), ARP cache sizing and gc_thresh tuning become relevant to avoid table exhaustion warnings.
Formula
ARP cache entries
entries = hosts_on_subnet (bounded by neigh gc_thresh limits)
- H_{subnet}
- distinct hosts recently communicated with on the subnet
Frequently Asked Questions
How do I view and check the size of the ARP cache on Linux?
`ip neigh show` lists all current neighbor table entries with their state (REACHABLE, STALE, etc.); `cat /proc/net/arp | wc -l` gives a quick count (subtract 1 for the header row).
What happens when the ARP cache hits its gc_thresh3 limit?
The kernel logs 'neighbour table overflow' and drops the oldest/least-recently-used entries to make room, which can cause brief connectivity hiccups on very large flat networks — raising `net.ipv4.neigh.default.gc_thresh1/2/3` is the standard fix for legitimately large subnets.
Why does an entry go STALE rather than being deleted immediately at gc_stale_time?
Marking an entry STALE (rather than deleting it outright) lets the kernel keep using the cached MAC address optimistically while probing to confirm it's still valid, avoiding a lookup stall on every single packet — only entries that fail to be confirmed and haven't been used are eventually garbage collected.