ARP resolves IPv4 neighbors

Before sending an IPv4 packet over Ethernet, a host needs the MAC address of the next hop. The Address Resolution Protocol, or ARP, maps a local IPv4 address to an Ethernet address.

The sender broadcasts a request asking which interface owns an IPv4 address. The owner replies with its MAC address, and the sender stores the answer temporarily in its neighbor cache.

For a destination on the same subnet, the next hop is the destination itself. For a remote destination, the next hop is usually the default router. ARP resolves the router’s local address, not the remote server’s address.

Watch ARP on your own link

You can see the exchange with a short capture. In one terminal:

sudo tcpdump -ni eth0 -c 2 arp

In another, ping your router so your machine must resolve its address:

ping -c 1 192.168.1.1

ARP, Request who-has 192.168.1.1 tell 192.168.1.20
ARP, Reply 192.168.1.1 is-at 9c:53:22:aa:04:1e

The request goes to broadcast. The reply comes from the router with its MAC address. On macOS, sudo tcpdump -ni en0 arp shows the same pattern.

Inspect the neighbor cache

After resolution, the mapping lives in the cache until it ages out:

ip neighbor show 192.168.1.1
# 192.168.1.1 dev eth0 lladdr 9c:53:22:aa:04:1e REACHABLE

REACHABLE means the entry was confirmed recently. STALE or FAILED means the link layer may not know how to reach that next hop. On macOS, arp -a lists the same table.

A stale or missing neighbor entry can stop communication before the first packet leaves the LAN. If ping to a local address fails but routing looks correct, check the neighbor cache first. Clearing a bad entry with ip neigh flush dev eth0 forces a fresh ARP exchange on Linux.