Sending an IPv4 packet across an Ethernet network requires two different kinds of addresses. The IP layer selects a next-hop IPv4 address, while the Ethernet frame needs a destination MAC address that identifies the next hop on the local link.
Address Resolution Protocol (ARP) connects those two layers. A host can ask which MAC address corresponds to a local IPv4 address, receive a reply, and store the resulting mapping. Keeping that result in a neighbor cache avoids broadcasting the same question before every packet.
The cache is not simply a permanent table. Dynamic mappings age, reachability information changes, and operating systems can probe entries again when confidence in a cached neighbor falls.
ARP resolves the next hop on the local link
Suppose a computer wants to send traffic to another IPv4 host on the same Ethernet segment. Its routing decision identifies the destination as directly reachable, but an Ethernet frame cannot use the IPv4 address as its link-layer destination. The sender needs the peer’s MAC address.
If no suitable mapping is cached, the sender can transmit an ARP Request on the local broadcast domain. The request carries the target IPv4 address and asks the owner of that address to provide its hardware address. The matching host responds with an ARP Reply containing the mapping.
The sender can then construct Ethernet frames addressed to that MAC address. It also has useful information for later packets, so retaining the mapping saves another resolution exchange.
Traffic for a remote IPv4 network follows the same basic link-layer requirement, but the address being resolved is normally the next-hop router rather than the final remote server. A laptop reaching a public website through its home router usually needs the router’s local MAC address. The remote server’s MAC address is not carried across the Internet to the laptop.
Cached mappings cut broadcast traffic and setup delay
ARP Requests are commonly broadcast because a sender without a mapping does not yet know the target’s unicast MAC address. Every station in the broadcast domain may receive the frame even though only the relevant neighbor needs to answer.
Repeating that exchange for every outgoing packet would create needless broadcast traffic and add resolution latency to routine communication. A neighbor cache lets the host reuse a recently established IPv4-to-MAC association.
That reuse is especially valuable for a default gateway. Many flows to many remote destinations can share the same local next hop, so one cached gateway mapping can support a large amount of traffic without fresh ARP resolution for each Internet destination.
Caching also separates IP routing from repeated link-layer discovery. The routing table can keep selecting a next-hop IPv4 address, while the neighbor subsystem supplies the link-layer address associated with that next hop.
A cached entry can become stale without becoming useless
A dynamic mapping cannot be trusted forever. A device may disconnect, reboot, move behind different equipment, replace a network interface, or otherwise appear with a different MAC address. Network state can also change while an old mapping remains stored locally.
Operating systems therefore maintain state around neighbor entries rather than treating every cached value as permanently valid. On Linux, for example, neighbor entries can appear in states such as reachable, stale, delay, probe, incomplete, and failed.
A stale entry does not necessarily mean that the recorded MAC address is already incorrect. It means the system no longer has recent confirmation strong enough to regard the neighbor as currently reachable. Linux can still have a known link-layer address while arranging additional validation as traffic requires it.
This distinction avoids two costly extremes. Keeping every dynamic entry forever risks sending frames toward obsolete mappings. Discarding every mapping after a short quiet period would trigger unnecessary broadcasts even when the neighbor has not changed.
Reachability feedback can refresh confidence
Neighbor handling can use evidence beyond an ARP Reply. Linux can accept positive feedback from higher layers as evidence that communication with a neighbor is progressing. A successful TCP acknowledgment is one example of feedback that can support continued confidence in an existing mapping.
When that confidence expires, the kernel does not need to assume immediately that the stored MAC address is false. It can transition the entry through neighbor-state logic and probe when needed. If validation succeeds, communication continues with a confirmed mapping. If repeated validation fails, the entry can eventually reach a failed state.
This behavior explains a common packet-capture surprise: an active host does not necessarily emit periodic ARP Requests at a simple fixed interval for every neighbor. Cache state, actual traffic, higher-layer feedback, implementation settings, and probe timing all affect what appears on the wire.
A quiet mapping may age differently from one supporting continuous confirmed traffic. The cache is therefore both a mapping store and part of a reachability-management process.
ARP caching stays inside a broadcast domain
ARP is a local-link mechanism. Routers do not normally forward an ARP broadcast from one IPv4 subnet into another. Each routed link performs its own address resolution for neighbors directly reachable on that link.
Consider a client, a router, and a server on three different network positions. The client can cache a mapping between the router’s local IPv4 address and the router interface’s MAC address. On another Ethernet segment, the router may maintain a separate mapping for its next hop or for the server if that server is directly attached there.
The Ethernet headers are replaced as an IP packet moves through routers. The source and destination IP addresses can remain associated with the end-to-end conversation while link-layer addresses change from hop to hop.
This boundary is useful during troubleshooting. An ARP entry for a default gateway says something about local delivery to that gateway. It does not establish that routing, DNS, transport connectivity, or the remote application beyond the gateway is healthy.
Stale mappings can cause local connectivity symptoms
If a host continues using an obsolete MAC mapping, Ethernet frames can be sent to the wrong interface or to an address no longer present on the segment. The resulting symptom may look like an IP problem even though the routing decision itself is correct.
Neighbor-state inspection can help separate these cases. On Linux, ip neigh displays entries along with their link-layer addresses and state. An incomplete entry indicates that resolution has not yet produced a validated neighbor, while failed indicates that validation attempts have been exhausted. A stale entry still carries a mapping but lacks recent reachability confirmation.
Clearing a dynamic neighbor entry during diagnosis can force fresh resolution, but that action treats the cached symptom rather than identifying the event that made the mapping obsolete. Persistent recurrence can point toward address duplication, unusual failover behavior, virtual-machine movement, network-device changes, or another local-link condition that deserves separate investigation.
Static or permanent neighbor entries require extra care because normal aging behavior may not replace them automatically. A manually configured mapping that no longer matches the network can remain wrong until administrative action changes it.
ARP has no built-in authentication
Classic ARP was designed to resolve local addresses, not to provide cryptographic proof of a mapping. Hosts can process assertions about IPv4 and hardware-address associations without an authenticated identity system built into the protocol.
That property matters for both reliability and security. Unexpected ARP information can alter where a host sends local Ethernet frames, and duplicate IPv4 addresses can produce conflicting mappings. Networks can add controls around ARP behavior, but those controls are separate from the basic request-and-reply mechanism.
ARP announcements also allow a host to advertise an address mapping proactively in situations such as address configuration or movement. Such traffic can help peers update cached information sooner, but cache behavior still depends on the receiving implementation and network policy.
For IPv6, the equivalent neighbor-resolution job is handled by Neighbor Discovery rather than ARP. The surrounding goals are related, but the protocol messages and mechanisms differ.
The neighbor cache makes local delivery practical
ARP resolution provides the missing link between an IPv4 next hop and the MAC address needed for an Ethernet frame. The neighbor cache turns each successful resolution into reusable local state, reducing broadcast load and avoiding repeated setup work.
That reuse comes with a lifecycle. Dynamic entries can lose recent reachability confirmation, move through validation states, receive probes, and eventually be replaced or discarded. As a result, a cached mapping is best viewed as managed network state rather than a permanent fact.
The mechanism keeps ordinary local traffic efficient while giving the host a path to recover when the device behind an IPv4 address changes.