All About ARP
How a device turns an IP into a MAC — broadcast, reply, and cache
We now know a device needs a MAC address to deliver data locally, and that it usually only starts with an IP. ARP is the protocol that fills the gap. This chapter walks the full mechanism step by step, for both same-network and out-of-network cases, and ends with a command you can run right now.
Interactive — ARP: broadcast, reply, cache
animated figureA1 needs A3's MAC address. Watch the broadcast reach everyone, the single reply, and the cache that makes the second send instant.
A1 wants to send to 192.168.1.4 — same network, but a frame needs a MAC address. The ARP table is empty.
What is ARP?
ARP (Address Resolution Protocol) is beautifully simple: give it an IP address, and it returns the MAC address of the device holding that IP. That is its entire job.
ARP is like DNS
You already know a resolver like this: DNS takes a domain name and returns a public IP. ARP takes an IP and returns a MAC. Both are simple input → output lookups — just at different layers.
The setup
Our network: a router (the default gateway) plus hosts A1, A2, A3 with IPs ending .2, .3, .4, all using the subnet mask 255.255.255.0. A1 wants to send data to A3.
Step 1 — Same network?
A1 already knows A3’s IP (you always know the IP before making a request — just like a frontend knows the backend’s address after DNS). It applies the subnet mask to its own IP and to A3’s: both give 192.168.1.0. Same network → A1 can send directly. But to actually deliver, it first needs A3’s MAC. Enter ARP.
Step 2 — ARP broadcast
A1 sends an ARP request as a broadcast — it goes to every device on the network (A2, A3, and the router all receive it). The request asks: "Who has 192.168.1.4? Tell me your MAC." (Compare: DNS asking "what is the IP of api.example.com?")
Step 3 — Only the owner replies
Every device checks the requested IP against its own. A2 and the router do not match, so they ignore the request. Only A3 — the actual owner of 192.168.1.4 — replies, sending back its MAC address.
The ARP table (cache)
Every device keeps an ARP table in cache memory — a simple key-value map of IP → MAC. Initially a device’s table holds just its own IP↔MAC (which is how A3 knew what to answer). When A1 gets A3’s reply, it caches the 192.168.1.4 → MAC entry so it can skip the broadcast next time.
Why cache?: Re-broadcasting for every packet would be wasteful. The cache makes repeat sends instant.
Out-of-network case
What if the target (say 10.0.0.1) is not on the network? The mask check fails, so A1 must send to its default gateway. A1 already knows the gateway’s IP (pre-configured on every machine). So it ARP-broadcasts for the gateway’s IP — and this time only the router replies with its MAC. A1 then uses that MAC to hand the packet to the router.
See it yourself: arp -a
This is not abstract — you can inspect your own ARP table right now. On macOS/Linux, run arp -a in a terminal. You will see the IP-to-MAC entries your machine has cached, including your router/default gateway’s IP and MAC.
Try it: Run arp -a after browsing for a bit — you will see entries your machine learned via exactly the broadcast-and-reply process above.