Neighbour Cache Staleness and Peers That Become Unreachable

The neighbour cache is the only place where a network-layer address is bound to a link-layer address, and it is the only piece of forwarding state that is populated by asking rather than by configuration. Its entries are created by traffic, aged by timers, and validated by probe exchanges, and each of those mechanisms can leave the cache asserting a binding that no longer holds. Because the binding is consulted after the route is chosen and before the frame is built, a stale entry produces a failure that looks like a path problem at the exact moment the path is fine.

The entry states and what transitions between them

An IPv6 neighbour entry moves through a small state machine. A new entry begins in an incomplete state while solicitations are being sent and no advertisement has arrived. On receiving an advertisement, the entry becomes reachable and stays there for a period derived from the reachable-time value advertised by the router, whose base defaults to thirty seconds and is scaled by a random factor between one half and one and a half, so that neighbouring hosts do not probe in step. When that period expires without confirmation, the entry becomes stale: the binding is retained and used, but it is no longer trusted.

A stale entry is used for transmission without any delay. The first packet sent through it triggers a reachability confirmation, which the node performs by sending a Neighbor Solicitation to the cached link-layer address as a unicast probe. If an advertisement arrives, the entry returns to reachable. If the probe goes unanswered after the configured number of retransmissions, the entry is deleted and the next packet starts resolution from the incomplete state, sending a multicast solicitation.

The design reason for keeping stale entries rather than deleting them at expiry is that most bindings do not change. Deleting on expiry would force a multicast resolution for every peer after a quiet interval, and multicast resolution costs every host on the link an interrupt. Keeping the entry and confirming it lazily means the common case, where the binding is still correct, costs one unicast probe rather than a broadcast. The trade is that the first packet after a stale period is sent to an address that may be wrong, before the probe has had a chance to correct it.

IPv4 uses a simpler scheme with the same effect. An ARP entry has a reachable lifetime after which it is considered stale but retained, and the next transmission through it triggers a unicast ARP request. The terminology and the default timers differ between implementations, and the defaults are configurable, so the specific intervals should be read from the running system rather than assumed.

The window in which a stale binding is used

The interval between a binding becoming wrong and the node learning that it is wrong is the failure window, and its length is determined by the probe schedule. A stale entry is used for transmission immediately, so the first packet after the peer’s address moved is sent to the old link-layer address. Whether that packet is lost depends on what now owns the old address: if nothing does, the frame is discarded by the switch; if a different host has taken the address, the frame is delivered to the wrong host and silently dropped there, unless that host happens to answer.

The window closes only when the probe fails and the entry is deleted. Probing begins on the first transmission after the entry becomes stale, not at the moment it becomes stale, so a cache with no traffic through it can hold a wrong binding indefinitely. This is the mechanism behind a class of failure where connectivity breaks at the moment traffic resumes after an idle period: the entry was stale, the peer had moved, and the first exchange after the pause is what exposes it.

The unicast probe adds its own delay. Each probe waits for a retransmission interval before the next, and several probes are sent before the entry is abandoned. The total is on the order of seconds, which is short for a person and long for a protocol whose retransmission timers are also on the order of seconds. A transport connection attempting to send during that interval experiences loss and may reduce its congestion window, so a brief neighbour cache problem can leave a lasting mark on the connection’s throughput.

Address conflicts look like cache flapping

When two hosts claim the same IPv4 address, the cache entry for that address alternates between their link-layer addresses. Each host answers ARP requests for the address, and whichever answers last wins the binding. The observable symptom is a connection that works, stalls, and resumes, with the peer’s identity changing underneath.

The pattern is distinctive in a capture: the same network address appears bound to two different link-layer addresses within a short interval, and the frames from the two are interleaved. No single host can detect this reliably from its own state, because each host’s cache is internally consistent at any instant. Detection requires either a capture on the link or a host that watches the cache over time and notices the alternation.

IPv6 has a defence that IPv4 lacks: duplicate address detection prevents a host from claiming an address another node is defending, and a defending node answers the detection probe, which causes the newcomer to mark the address as duplicated and refuse to use it. The defence is only effective if the probes reach the defender, which depends on the link carrying the solicited-node multicast group, and on switches that honour multicast forwarding.

Cache size and the cost of eviction

The cache is a bounded table, and its replacement policy is not least-recently-used in every implementation. When the table is full, entries are removed to make room, and the removal is unobservable to the protocols above: the next packet through a removed entry triggers fresh resolution, which succeeds after a round trip of solicitation and advertisement.

On a link with many peers, a host that communicates with more addresses than the table holds will evict entries it is still using. The symptom is elevated resolution traffic and occasional latency spikes on the first packet of a conversation, without any loss. The link-layer multicast traffic from solicitations also rises, which on a busy segment is visible as an increase in broadcast or multicast frame counts at the switch.

The fix is a larger table where the implementation permits it, but the more common cause is a scan or a monitoring probe that touches many addresses in sequence and pushes out the entries that matter. Recognising the pattern means correlating resolution traffic with the activity of the scanner rather than with the application whose latency increased.

Deliberate invalidation

Every mainstream stack allows an entry to be removed administratively, and doing so is the standard remedy when an address has moved and waiting for the probe schedule is unacceptable. Removing the entry forces resolution on the next transmission, which uses the multicast path and reaches whatever now holds the address.

ip neigh show                      # current bindings and their states
ip neigh flush dev eth0            # drop all entries for one interface
ip neigh del 192.0.2.10 dev eth0   # drop one entry
ip neigh replace 192.0.2.10 lladdr 02:00:00:00:00:01 dev eth0 nud permanent

The last form installs a static binding, which is appropriate for a peer whose address genuinely does not move, such as a router on a stable segment. Static entries are not probed, so a static binding to an address that later moves becomes a permanent failure rather than a temporary one. That is the trade: immunity to the probe schedule in exchange for immunity to correction.

Flushing an entire interface is a blunt action on a busy host because it discards bindings that are still correct and forces multicast resolution for every active peer, which briefly loads the link and every host on it. Removing the single entry that is wrong is preferable where the specific peer is known, and where the wrong binding is instead suspected from a capture, the sampling artifacts that make a capture trustworthy at that point are the ones described in packet capture placement.

Why the cache outlives the reason it was built

A neighbour entry has no association with the configuration that made the address reachable. If an address is moved from one interface to another on the same host, or a router is replaced with one that answers on a different link-layer address, the cache retains the old binding until a probe fails. Nothing in the address assignment or the route installation invalidates it.

This is why the inspection sequence for a connectivity fault places the neighbour check after the address and route checks rather than before: a wrong binding is only reachable as an explanation once the configuration is known to be right. The full sequence, and the point at which each piece of state is installed, is laid out in interface configuration order. When the configuration is right and a single peer is unreachable while its neighbours on the same link are fine, the cache entry for that peer is the first thing to look at, and removing it is the cheapest test available.