ARP
To put an IP packet on a local segment, a host needs the destination's MAC address — the IP tells it who, but the frame needs a layer-2 where. ARP, the Address Resolution Protocol, fills that gap: it broadcasts "who has 10.0.0.5?" onto the wire, the owner answers with its MAC, and the asker caches the mapping. ARP is the glue between layer-3 addressing and layer-2 delivery, and it runs constantly under every connection you make on a LAN.
ARP was designed in 1982 to trust everyone on the segment, and that assumption never got fixed. There is no authentication: any host can answer any question, or volunteer an answer nobody asked for, and every other host will believe it. That single design choice is the root of ARP spoofing and a recurring theme in LAN security — the protocol that makes the network work is also one of its softest attack surfaces.
The Request and Reply Exchange
ARP resolution is one broadcast question and one unicast answer. A host with a packet for 10.0.0.5 on its own subnet sends an ARP request to the broadcast MAC ff:ff:ff:ff:ff:ff, carrying the target IP and its own IP and MAC. Every host on the segment receives it; only the one that owns 10.0.0.5 replies, unicast, with its MAC. The asker caches the result and finally sends the frame it was holding.
The key subtlety: ARP only ever resolves an address on the local subnet. For a destination off-subnet, the host does not ARP for the remote IP at all — it ARPs for its default gateway and sends the frame there, leaving the IP header addressed to the far server. This is why a server logs its last-hop router's MAC, never the original client's. ARP answers "what is the next-hop MAC," not "what is the destination's MAC."
# watch a resolution happen, request then reply tcpdump -n -i eth0 arp # ARP, Request who-has 10.0.0.5 tell 10.0.0.2, length 28 <- broadcast # ARP, Reply 10.0.0.5 is-at dd:ee:ff:44:55:66, length 28 <- unicast
The ARP Cache
Every resolved mapping is cached so the next packet to the same host skips the broadcast. On Linux the cache is the neighbor table, inspected with ip neigh (or the older arp -a). Entries carry a state — REACHABLE, STALE, DELAY, FAILED — and age out after a few minutes of silence, at which point the next packet triggers a fresh request to confirm the host is still there and still at the same MAC.
Aging is what lets a network recover from a host moving or changing its MAC, but it is also why a stale entry can misdirect traffic for the lifetime of the cache. If a host fails over to a standby and the standby does not announce itself, every cached sender keeps shipping frames to the dead MAC until the entry expires — which is the failure the next section exists to prevent.
# the neighbor (ARP) table and its per-entry state ip neigh show # 10.0.0.5 dev eth0 lladdr dd:ee:ff:44:55:66 REACHABLE # 10.0.0.9 dev eth0 lladdr 11:22:33:44:55:66 STALE ip neigh flush dev eth0 # drop cached entries, force re-resolution
Gratuitous ARP and Failover
A gratuitous ARP is an unsolicited announcement — a host broadcasts "I am 10.0.0.5 at this MAC" without anyone asking. Its purpose is to update every other host's cache immediately. The textbook use is IP takeover: when a standby server claims a floating virtual IP after the primary dies, it sends a gratuitous ARP so the whole segment rewrites its cache to the new MAC in one broadcast, instead of waiting minutes for the old entries to age out.
This is the mechanism under almost every VIP failover — keepalived, VRRP, cloud floating IPs, clustered databases. The handoff is only as fast as the gratuitous ARP reaching every cache; a switch that drops or rate-limits it, or a host that ignores unsolicited updates, leaves traffic flowing to a machine that is already gone. The same mechanism is also what an attacker abuses to redirect traffic.
ARP Spoofing
Because ARP has no authentication, any host can send a gratuitous ARP claiming to own the gateway's IP, and every cache on the segment will believe it. The attacker poisons each victim's cache so traffic for the gateway flows to the attacker instead, who relays it onward — a textbook man-in-the-middle that sees and can modify everything crossing the segment. Nothing in the protocol detects it; the victims have no reason to doubt an answer.
The defenses live outside ARP itself. Dynamic ARP Inspection on managed switches drops ARP replies that disagree with the DHCP snooping table; static ARP entries pin critical addresses so a spoofed reply is ignored; and segmenting untrusted hosts off sensitive segments limits who can even send the poison. On any segment you do not fully control, treat ARP as untrustworthy by default.
ARP is IPv4-only and relies on layer-2 broadcast to ask its question, so every host on the segment is interrupted by every request. It carries no authentication and is a separate EtherType (0x0806) sitting beside IP rather than inside it.
NDP, the Neighbor Discovery Protocol, replaces ARP in IPv6 and rides inside ICMPv6 using multicast solicited-node groups, so only the likely owner is interrupted, not the whole segment. It folds in router discovery and address autoconfiguration too, and can be secured with SEND — but in practice most deployments leave it as trusting as ARP.
- Failing over a floating IP without a gratuitous ARP. The standby owns the VIP, but every sender's cache still points at the dead primary's MAC, so traffic blackholes until the entries age out minutes later instead of recovering in seconds.
- Trusting ARP on an untrusted segment. With no authentication, any host can claim the gateway's IP and silently man-in-the-middle the whole segment; treating a shared or public LAN as if ARP were trustworthy invites traffic interception.
- Forgetting that hosts ARP for the gateway, not the remote IP, for off-subnet traffic. Debugging why a server sees the "wrong" source MAC wastes time until you remember the frame's source is always the last-hop router, by design.
- Getting surprised by proxy ARP. A router answering ARP on behalf of hosts it can reach can make two subnets look like one and mask a misconfigured netmask, so connectivity "works" in a way that hides the real topology and breaks subtly later.
- Leaving a stale static ARP entry after a NIC swap. A pinned mapping does not age out, so replacing a host's network card without updating the static entry sends its traffic to a MAC that no longer exists, with no automatic recovery.
- Send a gratuitous ARP on every VIP failover (keepalived and VRRP do this automatically) so the whole segment rewrites its cache to the new MAC immediately instead of blackholing until entries age out.
- Enable Dynamic ARP Inspection with DHCP snooping on access switches to drop forged ARP replies that disagree with the leased bindings, which shuts down the common cache-poisoning man-in-the-middle.
- Pin static ARP entries for critical gateways and infrastructure on hosts that must never be redirected, so a spoofed reply claiming the gateway's IP is simply ignored.
- Inspect ip neigh when local connectivity is flaky and check for a FAILED or wrong-MAC entry before suspecting routing, because a poisoned or stale neighbor entry looks exactly like a higher-layer outage.
- Keep untrusted hosts off segments carrying sensitive traffic, since ARP's trust-everyone design means anyone sharing the broadcast domain can attempt to intercept it.
Knowledge Check
A host needs to send a packet to a server on a different subnet. What does it ARP for?
- Its default gateway's MAC, since ARP only resolves addresses on the local subnet
- The remote server's own MAC address, obtained by broadcasting the ARP request out across both subnets at once
- The DNS server's MAC, to look up the server's address first
- A single end-to-end MAC that stays valid across every hop
A standby claims a floating VIP after the primary dies but sends no gratuitous ARP. What breaks?
- Senders keep using the old cached MAC, so traffic blackholes until the cache ages out
- The standby never actually manages to acquire the floating IP at all unless it first sends an explicit ARP request for it
- Two hosts answer for the VIP at once, causing an address conflict
- The switch routing table never updates to the standby's subnet
What makes ARP spoofing possible in the first place?
- ARP has no authentication, so any host can answer for any IP and be believed
- ARP replies are encrypted by default, so an attacker only succeeds by forging a cryptographically valid signature on the reply
- The cache never expires, so one forged entry lasts forever
- ARP traverses routers, letting an attacker poison a remote subnet
You got correct