Without the ARP cache, every single IP packet destined for a local host would require a broadcast and reply cycle—introducing latency, consuming bandwidth, and overwhelming the network with redundant traffic. The ARP cache is what transforms ARP from a constant overhead into an occasional lookup.

The cache is deceptively simple in concept: it's just a table mapping IP addresses to MAC addresses. But its implementation involves sophisticated data structures, careful timing policies, multiple entry states, and security considerations. A well-managed ARP cache is invisible; a corrupted or stale cache causes mysterious connectivity failures that frustrate even experienced engineers.

The ARP cache (also called the ARP table, neighbor cache, or ARP resolution cache) is a local database maintained by each host's operating system. It stores the results of successful ARP resolutions, allowing future packets to the same destination to be transmitted immediately without waiting for new ARP exchanges.

Fundamental Cache Properties:

Basic Cache Entry Structure:

Each cache entry typically contains:

Modern operating systems implement ARP cache entries as state machines. Rather than simple present/absent, entries transition through multiple states that affect how they're used and refreshed.

Linux Neighbor Cache States (also applicable to IPv6 NDP):

Key Concepts:

REACHABLE vs. Stale: An entry is REACHABLE when the operating system has recent evidence that the entry is correct. This evidence can come from:

• The initial ARP reply
• Upper-layer confirmations (e.g., TCP ACKs indicate the host is reachable)
• Subsequent ARP replies

Without confirmation, entries transition to STALE. Stale entries are still usable, but the system knows it should verify them soon.

The DELAY State: When a STALE entry is used, it doesn't immediately trigger ARP. Instead, the system enters DELAY, expecting upper-layer confirmation (like a TCP ACK). This optimization avoids ARP traffic when TCP already confirms reachability. If no confirmation arrives within the delay timeout, the system PROBES with a direct unicast ARP (not broadcast).

The PROBE State: Probing sends ARP directly to the cached MAC address (unicast, not broadcast). If the host is still there with the same MAC, it replies. This is more efficient than broadcast re-resolution.

ARP cache timeouts balance two competing concerns:

1. Performance: Longer timeouts mean fewer ARP broadcasts, lower overhead
2. Correctness: Shorter timeouts mean faster detection of changed mappings

Different operating systems and environments choose different balances.

Linux Timeout Parameters (sysctl tunables):

# View current settings
sysctl net.ipv4.neigh.default.base_reachable_time_ms
sysctl net.ipv4.neigh.default.gc_stale_time
sysctl net.ipv4.neigh.default.delay_first_probe_time

# Typical defaults:
# base_reachable_time_ms = 30000 (30 seconds)
# gc_stale_time = 60 (seconds, when stale entries can be garbage collected)
# delay_first_probe_time = 5 (seconds before probing a stale entry)

The Randomization Factor:

To prevent synchronized cache expirations (which would cause ARP broadcast storms as many hosts simultaneously re-resolve), operating systems randomize actual timeout values around the base timeout:

• Linux: actual timeout = base_reachable_time × random(0.5 to 1.5)
• Windows: random between ArpCacheMinReferencedLife and ArpCacheMaxReferencedLife

This spreads cache expirations over time, smoothing network load.

Every network professional must know how to inspect the ARP cache on various platforms. This is fundamental troubleshooting.

Linux:

Windows:

macOS:

Sometimes administrators need to manually modify the ARP cache—adding static entries for security, deleting stale entries for troubleshooting, or flushing the entire cache to force re-resolution.

Adding Static Entries:

Static entries never expire and take precedence over dynamic ones. They're useful for:

• Protecting critical hosts (gateways, DNS servers) from ARP spoofing
• Ensuring consistent mappings in high-availability configurations
• Working around hosts that don't respond to ARP properly

Deleting Entries:

Flushing the Entire Cache:

Complete cache flush forces all entries to be re-resolved—useful when troubleshooting widespread connectivity issues or after significant network changes.

The distinction between static and dynamic entries is fundamental to ARP cache management. Each has specific use cases and tradeoffs.

When to Use Static Entries:

1. Gateway/Router Protection

The default gateway is the most critical ARP entry. If an attacker spoofs the gateway's MAC, they can intercept all external traffic. Static entries for gateways prevent this:

# Linux: Protect gateway from spoofing
sudo ip neigh add 192.168.1.1 lladdr a0:b1:c2:d3:e4:f5 nud permanent dev eth0

2. Critical Server Protection

DNS servers, domain controllers, and other infrastructure should have static entries on client machines to prevent redirection attacks.

3. High-Availability Pairs

When two servers share a virtual IP and fail over between them, static entries ensure the MAC address handoff is controlled, not subject to racing ARP replies.

4. Embedded Systems

Devices with fixed network topology benefit from static entries that survive ARP cache timeout cycles.

Operating systems implement ARP caches using efficient data structures optimized for fast lookups. Understanding these internals helps explain behavior and performance characteristics.

Common Implementation Approaches:

Linux Neighbor Cache Implementation:

Linux uses a hash table with configurable bucket count. Each bucket contains a linked list of entries that hash to that bucket. Key parameters:

# View neighbor table size parameters
sysctl net.ipv4.neigh.default.gc_thresh1  # Minimum entries before GC
sysctl net.ipv4.neigh.default.gc_thresh2  # Soft limit (GC more aggressive)
sysctl net.ipv4.neigh.default.gc_thresh3  # Hard limit (refuse new entries)

# Typical defaults:
# gc_thresh1 = 128   (don't GC below this)
# gc_thresh2 = 512   (start considering GC)
# gc_thresh3 = 1024  (hard maximum)

Garbage Collection (GC):

When the cache grows beyond thresholds, garbage collection removes entries based on:

1. Age: Oldest stale entries removed first
2. Usage: Least recently used entries are candidates
3. State: FAILED and old STALE entries removed before REACHABLE

GC runs periodically (gc_interval, typically 30 seconds) or when hard limits are reached.

The ARP cache is a local data structure with no distributed coordination. This creates coherency challenges when network conditions change.

Problem 1: MAC Address Changes

When a host's MAC address changes (NIC replacement, VM migration, failover), cached entries across the network become stale. Until caches expire or are updated, traffic may be misdirected.

Solutions:

• Gratuitous ARP announces the new mapping
• Shorter cache timeouts accelerate discovery
• Some systems detect link-layer failures and invalidate entries

Problem 2: Host Movement (VM Migration)

Virtual machines can migrate between physical hosts, changing their Layer 2 location while keeping the same MAC/IP. Switches must update their MAC tables, and peers may need cache updates.

Solutions:

• RARP/GARP upon migration completion
• VMware vMotion sends GARP after migration
• SDN controllers can push updates to all switches

The ARP cache transforms ARP from a constant overhead into occasional lookups. Understanding its structure, states, and management is essential for network troubleshooting and optimization. Let's consolidate the key takeaways:

What's Next:

With the cache understood, we'll dive deeper into the ARP Request/Reply cycle—examining the specific packet formats, Ethernet frame construction, and the nuances of how requests and replies are matched and processed.