ARP — address resolution, ARP cache, gratuitous ARP: Visual walkthrough

We assume you know nothing. So first, the two kinds of address.

Step 1 — Two names for the same machine

WHAT. Every machine on a local network has two different addresses stuck to it at the same time:

an IP address — a logical label like 10.0.0.5, chosen by software, that can be changed, moved, or handed out by DHCP.
a MAC address — a physical label like AA:BB:CC:DD:EE:FF, burned into the network card (the NIC), that identifies the actual piece of hardware. See Ethernet & MAC addressing.

WHY two? Because two different jobs need two different labels:

PICTURE. Look at the board. One computer, two sticky labels: the blue IP tag ("what software calls me") and the pink MAC tag ("what my hardware really is"). The gap between them — the arrow with the question mark — is the entire problem ARP solves.

Step 2 — Look in your own pocket first (the cache)

WHAT. Before shouting to the whole room, host A checks its own ARP cache — a little table it keeps of IP↔MAC pairs it already learned.

WHY. Broadcasting bothers every machine on the LAN. If A already wrote down "10.0.0.5 → BB:BB:..." from a minute ago, it can skip the whole broadcast and send immediately. The cache exists purely to avoid asking twice.

PICTURE. The cache is a two-column notebook. On the left, IP addresses; on the right, MACs; each row has a tiny timeout clock. On a fresh boot the notebook is empty — so the row for 10.0.0.5 is blank. That blank row is why we must proceed to Step 3.

Step 3 — Shout the question to everybody (broadcast request)

WHAT. A builds an ARP Request and sends it with destination MAC FF:FF:FF:FF:FF:FF — the broadcast address, which means "deliver this to every NIC on the LAN."

WHY a broadcast? This is the subtle heart of ARP. A does not know B's MAC — that's the whole reason we're here. So A cannot address the question to B directly. The only way to reach an unknown recipient is to ask everyone at once.

PICTURE. One packet leaves A and the switch copies it out of every port (this is called flooding). Watch the four fields inside the packet — they matter for the next two steps:

Step 4 — Everyone reads it; only the owner reacts

WHAT. Every host on the LAN receives the broadcast. Each one compares the request's TgtIP to its own IP.

WHY. The broadcast is addressed to everyone, so C and D physically receive it too. But ARP has a filter rule: "reply only if the target IP is mine." C's IP is 10.0.0.7, D's is 10.0.0.9 — neither matches 10.0.0.5, so they silently drop it. Only B matches.

PICTURE. Three hosts hold up the same request. Two shake their heads (red ✗ — "not my IP"), one nods (yellow ✓ — "that's me"). This is why the LAN isn't flooded with replies: the match rule guarantees exactly one responder.

Step 5 — The owner answers privately (unicast reply)

WHAT. B sends an ARP Reply back, but this time as a unicast — straight to A's MAC only, not to everyone.

WHY unicast now? Because B learned A's MAC for free from the request's SndMAC field (Step 3). B now knows exactly where A is, so bothering the whole LAN again would be wasteful. The reply carries the answer we've been chasing since Step 1: B's IP paired with B's MAC.

PICTURE. A single blue arrow from B directly to A — no copies to C or D. Notice the sender/target fields have swapped roles: what was "target" is now "sender."

Step 6 — Write it down and finally send the data

WHAT. A stores 10.0.0.5 → BB:BB:... in its cache with a fresh timeout clock, then sends the real frame (e.g. the ICMP ping) using B's MAC as the destination.

WHY cache it? So the next packet to B skips Steps 3–5 entirely (back to the Step 2 "hit" branch). The timeout exists so that if B's NIC is later replaced, the stale row eventually expires and A re-learns the truth.

PICTURE. The notebook row is now filled, a clock ticks beside it, and a solid data frame flows A→B with the correct destination MAC. The loop from Step 2 is now closed.

Step 7 — Edge case A: the target is on another network

WHAT. Suppose A wants 8.8.8.8, which is not on the local LAN. A does not ARP for 8.8.8.8. Instead it ARPs for its default gateway's IP and sends the frame there.

WHY. ARP is link-local: routers do not forward ARP broadcasts, so shouting "Who has 8.8.8.8?" would never reach it. A uses its subnet mask (see IP addressing & subnetting) to decide local vs remote; if remote, the frame's destination MAC becomes the gateway's MAC, while the destination IP stays 8.8.8.8.

PICTURE. A fork in the road. If the target IP is inside A's subnet, the green path ("ARP for B directly"). If outside, the yellow path ("ARP for the gateway; IP stays remote, MAC becomes the gateway's").

Step 8 — Edge case B: nobody has to ask (gratuitous ARP)

WHAT. A Gratuitous ARP is a host announcing its own mapping without being asked — an ARP packet where Sender IP == Target IP.

WHY. Three degenerate-but-important situations need a proactive shout instead of a reactive reply:

Duplicate-IP detection — on boot A gratuitous-ARPs its own IP; if someone replies, there's a conflict.
Failover / VIP takeover — a backup server grabs 10.0.0.100 but has a different MAC; it shouts so every host overwrites the old cache row instantly instead of waiting for the timeout of Step 6.
Refreshing switch MAC tables so frames flow to the new active machine.

PICTURE. One host broadcasts "10.0.0.100 is at S2," and three notebooks overwrite their old S1 rows to S2. Note the tell-tale sign: SndIP and TgtIP are the same address.

The one-picture summary

Everything above collapses into a single timeline: Cache miss → Broadcast question → One host matches → Unicast answer → Cache it → Send data, with the two side-branches (remote → gateway; gratuitous → announce).

Recall Feynman retelling — the whole walkthrough in plain words

You want to hand a note to Sam, but you only know his name (IP), not his seat (MAC). First you check your sticky notes — maybe you wrote down Sam's seat last time (the cache). Empty? Then you shout to the whole room, "Who is Sam?" (broadcast request), telling everyone your own name and seat as you shout. Everyone hears it, but only Sam raises his hand — because only his name matches — and he walks straight over to you (unicast reply) since he heard where you sit. You write his seat on a sticky note with a timer (cache with timeout) and finally hand over the note. If Sam were in another room (different network), you'd instead hand the note to the doorway monitor (gateway), because your shout can't leave the room. And if Sam suddenly changes seats, he can stand up and yell "I'm in seat 5 now!" without anyone asking (gratuitous ARP) — everybody scribbles the update. The catch: nobody checks IDs, so a prankster can yell "I'm the monitor now" and steal your notes (spoofing).