ARP
Address Resolution Protocol · Link layer helper
Every machine has two addresses: an IP address that identifies it on the internet, and a MAC address that identifies one network interface on one wire. A network card can only deliver a frame to a MAC address — so before anything can be sent, something has to translate one into the other. ARP does that by shouting a question to the whole local network and caching the answer.
- Why does this protocol exist?
- A network card can only deliver a frame to a MAC address, but everything above the link layer is addressed by IP. Something has to translate one into the other, and nothing else in the stack does.
- Which problem does it solve?
- I know the IP address of a machine on my own wire. I need its MAC address before I can put a single frame on the cable.
- Who participates?
- Every host and router on one broadcast domain. There is no client and no server: whoever owns the address answers, everyone else ignores it.
- Which layer uses it?
- Between the link and network layers. It rides directly in an Ethernet frame with EtherType 0x0806 — there is no IP header on an ARP packet at all.
- What does it depend on?
- Only the ability to broadcast on a link. It has no IP, no transport, no ports.
- What depends on it?
- Everything that sends IPv4 over Ethernet. No ARP, no first packet — which is why an ARP failure looks like total loss of connectivity.
- What state does each participant maintain?
- Each machine keeps an ARP cache: IP → MAC, with an age. Entries expire after a few minutes so a machine that has been replaced can be re-found. Nothing is held about requests in flight beyond a short retry.
- Which fields matter?
- opcode — 1 is a request, 2 is a reply. It is the only thing distinguishing the two — the rest of the packet has the same shape.
- senderProtocolAddr / senderHardwareAddr — The pairing every receiver caches, including hosts that were not asked. This is why gratuitous ARP works.
- targetProtocolAddr — The address being asked about. In a request the target hardware address is zero, because that is the unknown.
- What does normal behaviour look like?
- A broadcast request to ff:ff:ff:ff:ff:ff asking who has 10.0.1.1, then a single unicast reply from the owner, then silence — every later frame goes straight to the cached MAC.
- What does failure look like?
- Requests repeating with no reply. The requester retries a few times and gives up, and the application above sees a timeout with no error, because ARP has no way to report failure upward.
- How can I prove the diagnosis from packets?
- Find the ARP request in the trace and check three things: is anyone replying, is the reply for the address actually asked about, and does the cache entry that follows match the reply. An unanswered broadcast is conclusive.
- How does it interact with the rest of the stack?
- It sits underneath IPv4 and is invisible to everything above it. The local-versus-remote decision decides whether ARP asks for the destination or for the gateway — which is the single most misunderstood thing about it.
ARP is the smallest complete protocol in this curriculum: one question, one answer. It is a good first module for exactly that reason.
Guided course — 4 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1ARP-01Why ARP ExistsTwo address systems, and the translation between them≈10 min · 7 steps · 3 questions · guidedNot started
- 2ARP-02Local or Remote? The Decision That Drives EverythingWhy you never ARP for a server on the other side of the world≈10 min · 8 steps · 4 questions · guided · after arp-why-it-existsNot started
- 3ARP-03Troubleshooting Lab: Nothing Reaches the InternetWhen resolution fails, no IP packet is ever sent at all≈10 min · 8 steps · 4 questions · guided · diagnosis lab · after arp-why-it-exists, arp-local-vs-remoteNot started
- 4ARP-04The Cache, and What It Will BelieveGratuitous ARP, static entries, and why the protocol cannot say no≈10 min · 7 steps · 3 questions · guided · after arp-why-it-exists, arp-caching-and-failureNot started
Troubleshooting labs — 1
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Packet explorer — 11 scenarios, no coaching
PC1 pings PC2 on the same subnet with an empty ARP cache. Broadcast request, unicast reply, then the data — the shape of almost every first packet on a LAN.
Resolving the default gatewayPC1 pings a server on another subnet. Watch which address it ARPs for — it is NOT the server's. This is the single most important ARP lesson.
Cache hit — no ARP at allIdentical to the first scenario except both hosts already know each other's MAC. Two packets instead of four: this is what your capture looks like most of the time, and it is why ARP seems rarer than it is.
Only one side has the mappingPC1 knows PC2's MAC, but not the other way round. PC1 sends the ping with no ARP — and then PC2 has to ARP backwards before it can reply. Warming one cache does not remove ARP; it reverses it.
Nobody answers the ARP requestPC1 tries to reach 10.0.1.99 — an address no host owns. Three requests, no replies, then the send fails. Notice that no IP packet is ever transmitted.
Wrong subnet maskPC1 is configured /16 instead of /24. It now believes the server on the other subnet is a local neighbour, so it ARPs for the server itself — and gets silence. A configuration error that looks exactly like a network fault.
Gratuitous ARPThe printer announces its own address without being asked. Sender IP equals target IP — the signature of a gratuitous ARP. Everyone's cache updates.
Duplicate IP addressA second machine is configured with PC2's address and announces it. PC2 sees its own address claimed by another MAC — the detection that gratuitous ARP exists for.
Proxy ARPPC1 has a /16 mask and ARPs for a server on another subnet. This time the router has proxy ARP enabled — it answers with its OWN MAC and forwards the traffic. It works, and it hides the misconfiguration.
Cache expiry and re-resolutionPC1 pings PC2, the cache is cleared, then it pings again. The second exchange has to start with ARP all over again — which is why a long-idle flow sometimes shows ARP before its next packet.
Troubleshooting: cannot reach the gatewayPC1 tries to reach the internet. Its ARP requests for the gateway are dropped. Every remote destination now fails, and the capture shows why in the first two packets.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can say what ARP is for, what it cannot do, and why a correct routing table is still not enough to put a frame on a wire.
Where ARP sits in a real request
These captures run ARP as one stage of a longer chain, and hand its result to whatever comes next.
You plug in a laptop and type a name. Four protocols run before a single byte of the page is requested, and each one exists because the one before it could not do this job. Watch what each stage hands to the next.
Opening a secure websiteThe same four stages, plus one: before any request is sent, the server has to prove it is the server. Note what a capture can still read after encryption starts — and what it cannot.
A routed enterprise application, end to endThe office journeys stop at the gateway. This one starts before it: two routing protocols fill one routing table, then ARP and DNS do their usual jobs, then an application opens a connection across the result. Nothing in the application's packets refers to a routing protocol — and that is what the routing protocols are for.
Diagnosis: local machines work, the internet does notPrinting works. The intranet works. Anything outside this LAN times out. The laptop has an address, so the problem is further along.
Diagnosis: the settings look correctAddress, mask, gateway and resolver all match the documentation. Traffic off the LAN still fails. The configuration is not the problem.
Diagnosis: one site fails, everything else is fineOther sites load normally. This one fails instantly — not slowly, instantly. That timing is a clue in itself.
Diagnosis: the site is reachable but refusesThe name resolves and the server is clearly alive — it answers immediately. It just will not accept the connection.