ARP — address resolution, ARP cache, gratuitous ARP: Question bank

Ground the vocabulary first (three pictures)

Before the traps, three words below get thrown around a lot. Let's see them so the questions land.

Figure — ARP — address resolution, ARP cache, gratuitous ARP

Look at the frame in the figure: the orange EtherType box sits right after the two MAC-address boxes. It is the only thing that distinguishes an ARP frame from an IP frame at Layer 2 — same envelope, different label.

In the figure, the shaded region is one broadcast domain: A's ARP shout reaches B, C, D freely (they share a switch). The router on the right is a solid wall — the shout is dropped there, so the host beyond it never hears it. That wall is the picture of "link-local".

True or false — justify

The ARP Request is sent directly to host B's MAC address.

False. If A already knew B's MAC there would be nothing to resolve — the Request goes to the broadcast MAC FF:FF:FF:FF:FF:FF so every host on the LAN hears it.

The ARP Reply is a broadcast so everyone learns B's MAC.

False. The Reply is unicast back to A only, because B learned A's MAC from the sender field of the Request and has no reason to bother the whole LAN.

ARP runs on top of IP.

False. ARP sits beside IP and rides directly inside an Ethernet frame, marked by EtherType 0x0806 in the frame's type label — it needs no IP header, because its whole job is to make IP delivery possible.

A router will forward an ARP Request to the host on the other side of it.

False. ARP is broadcast-based and link-local; the router is a wall that drops ARP broadcasts, which is exactly why ARP can't reach across networks.

A gratuitous ARP is just a normal ARP that happened to arrive at a convenient time.

False. It is defined by Sender IP == Target IP — the host is announcing its own mapping unsolicited, not answering anyone's question.

Static ARP entries eventually expire like dynamic ones, just more slowly.

False. Static entries are manually pinned and never time out; only dynamic (learned) entries expire on the timeout.

Because only the true owner replies, ARP is trustworthy.

False. ARP has no authentication — any host can forge a Reply claiming another IP is at its MAC, which is the whole basis of ARP spoofing.

IPv6 uses ARP with bigger addresses.

False. IPv6 abandons ARP entirely and uses NDP over ICMPv6 multicast — no broadcasts at all.

A shorter ARP cache timeout is strictly better because the data is fresher.

False. Fresher, yes, but it forces more broadcasts — it's a trade-off between freshness and LAN noise, not a free win.

A gratuitous ARP is always sent as an ARP Reply.

False. It comes in two flavors: a gratuitous Request (broadcast question about your own IP) and a gratuitous Reply (an unsolicited answer nobody asked for). Both carry Sender IP == Target IP; which one a host sends is a choice of the OS/stack.

Spot the error

"To ping a server in another data centre, my PC ARPs for that server's IP."

The error: you never ARP for a remote host. Your PC uses the subnet mask to see the target is remote and instead ARPs for the default gateway's MAC. See Default gateway & routing.

"Every host on the LAN that sees the ARP Request should send a Reply."

The error: only the host owning the target IP replies. All others compare the target-IP field to their own IP, see a mismatch, and stay silent.

"When B replies, A has to broadcast again to confirm the mapping before caching it."

The error: no confirmation round exists. A caches the mapping straight from the single unicast Reply and immediately sends its data frame.

"A gratuitous ARP asks 'who has this IP?' expecting no answer."

Half-wrong: the gratuitous Request flavor really is a broadcast query, but its purpose is to announce, not query. If it does get a reply during boot-time duplicate detection, that reply signals an IP conflict.

"The switch reads the target IP inside the ARP Request to decide which port to send it to."

The error: switches operate on MAC addresses, not IPs. Seeing the broadcast destination MAC, the switch floods the frame out every port. See Switching & MAC learning tables.

"ARP spoofing is stopped by using a longer cache timeout."

The error: a longer timeout makes it worse — a poisoned entry lingers longer. The real fixes are Dynamic ARP Inspection, static entries, and port security. See Network security — MITM & ARP spoofing.

"Since ARP maps IP to MAC, DHCP must run before ARP or ARP fails."

The error: they solve different problems. DHCP hands out an IP; ARP resolves an already-known IP to a MAC. A host with a static IP uses ARP with no DHCP at all.

"A frame with EtherType 0x0806 should be handed to the IP stack."

The error: 0x0806 is the ARP label; 0x0800 is IPv4. Handing an ARP frame to the IP stack means the receiver reads the wrong parser and drops it.

"A router can never answer an ARP for an IP that isn't its own."

The error: with Proxy ARP enabled, a router deliberately replies with its own MAC on behalf of a remote host, tricking the local sender into forwarding via the router. It's an exception, not the rule.

Why questions

Why must the ARP Request be a broadcast and not a unicast?

Because A does not know B's MAC yet — the only way to reach an unknown recipient is to address the frame to everyone and let the right host self-identify.

Why can the ARP Reply safely be unicast?

Because the Request carried A's IP and A's MAC in its sender fields, so B already knows exactly where to send the answer — no broadcast needed.

Why does the ARP cache exist at all?

Broadcasting interrupts every machine on the LAN. Caching recently learned IP↔MAC pairs means A only broadcasts once per host instead of once per packet.

Why does a failover server send a gratuitous ARP the moment it takes over a Virtual IP?

The VIP now maps to a new MAC. Broadcasting the new mapping makes every host overwrite their stale cache entry instantly, avoiding downtime while old entries slowly expire.

Why does ARP need Ethernet but Ethernet doesn't need ARP?

ARP's job is to produce the MAC that Ethernet demands, so it depends on Ethernet as the delivery layer — but Ethernet already has MACs and doesn't care how you obtained them.

Why is "IP works globally, so ARP works globally" a tempting but wrong chain of logic?

IP is routable across networks, but ARP is the link-local step that IP relies on inside one broadcast domain — routers replace that local hop with their own ARP, so the resolution never travels end-to-end.

Why does the EtherType field even need to exist?

A single Ethernet frame could carry IPv4, ARP, IPv6, and more; the EtherType is the label that lets the receiver dispatch the payload to the correct protocol handler instead of guessing.

Edge cases

What happens if two hosts on the same LAN are configured with the same IP?

A gratuitous ARP on boot triggers a Reply from the other holder — a duplicate-IP detection event — and the OS typically warns and refuses to bring the interface fully up.

What happens if a host's NIC is swapped (new MAC, same IP) but no gratuitous ARP is sent?

Peers keep the stale IP→old-MAC entry and misdeliver frames until the cache timeout expires, then they re-ARP and relearn the correct MAC.

What does the ARP cache do if it receives an unsolicited Reply it never requested?

It depends on the stack: some accept and update the entry on any gratuitous message (convenient, but the spoofing loophole), while stricter stacks only refresh an existing entry and ignore gratuitous Replies for IPs they've never talked to.

Do OS stacks treat a gratuitous Request and a gratuitous Reply the same?

Not always — a common policy is to update the cache from a gratuitous Request but be more cautious about an unsolicited Reply, since a Reply out of nowhere is a classic spoofing signature. This asymmetry is a subtle trap.

Can a host ARP for its own IP, and does it make sense?

Yes — that is a gratuitous ARP, used to announce its mapping or to detect whether someone else already claims that IP.

What if A's cache holds B's mapping but B is now offline?

A will happily send frames to B's cached MAC; they simply go unanswered until the stale entry times out and, on the next attempt, a fresh ARP finds no responder.

What happens to an ARP Request whose target IP belongs to no host on the LAN?

Everyone hears the broadcast, nobody owns that IP, so no Reply ever comes — A's resolution times out and the higher-layer send fails as "host unreachable."

When A talks to a host across a router, whose MAC ends up in the frame's destination field?

The gateway's MAC (obtained by ARPing the gateway), while the destination IP stays that of the remote host — Layer 2 and Layer 3 destinations legitimately differ.

When does a router answer an ARP for an IP it does not own (Proxy ARP)?

When Proxy ARP is configured: the router replies with its own MAC for a remote host's IP, so a host that wrongly believes the target is local still sends the frame to the router, which then routes it onward. It papers over a subnet-boundary mistake at the cost of hidden, confusing behavior.

Connections

Ethernet & MAC addressing — ARP produces the MAC that every Ethernet frame demands; the EtherType field lives here.
IP addressing & subnetting — the mask decides local (ARP the host) vs remote (ARP the gateway).
Default gateway & routing — remote destinations resolve to the gateway's MAC; Proxy ARP lives here too.
Switching & MAC learning tables — switches flood ARP broadcasts by MAC, not IP.
NDP — IPv6 Neighbor Discovery — IPv6's replacement for ARP.
Network security — MITM & ARP spoofing — the consequence of ARP's missing authentication.
DHCP — hands out the IP that ARP later resolves.