Why ARP exists
A network card thinks in mac-addresses, not in IP. For host A to send an IP packet to host B in the same subnet, A must know B's MAC. ARP (RFC 826) is the protocol that resolves this mapping.
The algorithm:
- A wants to send to
192.168.1.20. It checks the neighbor table - If there is no entry, A sends an ARP request as a broadcast: "who has 192.168.1.20? tell 192.168.1.10 (my MAC AA:BB:...)"
- B sees the request (it is addressed to B) and answers with a unicast:
"192.168.1.20 is
00:1c:42:..." - A caches the IP↔MAC pair in the neighbor table
- Now A can send an ethernet-frame straight to B
ARP works only inside one broadcast domain (one L2 network). It does not cross a router. There the routing-table takes over.
ARP in IPv6
In IPv6, ARP is replaced by NDP (Neighbor Discovery Protocol). The concept is the same, but it runs over ICMPv6 and multicast instead of broadcast. Linux merges both tables:
bash
ip -4 neigh # IPv4 ARP
ip -6 neigh # IPv6 NDP
ip neigh # both together
Neighbor entry states
- REACHABLE: the IP↔MAC pair was confirmed recently
- STALE: not confirmed for a while, but the entry is still there
- DELAY / PROBE: transitional, a probe is in progress to check the entry
- FAILED: no reply, the entry is marked unreachable
Linux moves an entry from STALE to REACHABLE on its own when it sees confirming traffic (for example ACK packets from the neighbor).
ARP problems in production
- Duplicate IP in one network: ARP conflicts, and some hosts log
"duplicate address detected" in
dmesg - Gratuitous ARP during failover (VRRP, keepalived): the new IP owner sends an unsolicited ARP so that switches and neighbors update their tables quickly
- ARP poisoning: an attacker sends forged ARP replies to intercept traffic. You defend against it with static entries or 802.1x