Short answer: On Ethernet, ARP finds the MAC address for an on-link IPv4 next hop. For a remote destination reached through a router, the sender resolves that router's local IP, not the remote server's IP.
Before this: Ethernet frames and IPv4 subnet boundaries.
The problem ARP solves
Every Ethernet frame needs a destination MAC (Media Access Control) address before it can be sent, but applications and routing tables only ever deal in IP addresses. Something has to bridge that gap on the local segment. That's the Address Resolution Protocol: given an IP address, find the MAC address of whatever device is actually holding it.
It works like calling out across an open-plan office: "Who has desk assignment 10.0.0.5?" You don't know or care who that is yet, you just want them to identify themselves. Whoever holds that assignment calls back directly: "That's me, and here's exactly which desk to walk to."
Request and reply
- ARP request: initial resolution normally uses a Layer 2 broadcast (destination MAC
FF:FF:FF:FF:FF:FF), meaning "who has 10.0.0.5? tell 10.0.0.1." The target normally replies; a router configured for proxy ARP can answer on another host's behalf. Some implementations also use unicast requests to recheck cached neighbors. - ARP reply: in this ordinary request/reply exchange, sent as a unicast straight back to the requester: "10.0.0.5 is at MAC AA:BB:CC:11:22:33."
The ARP cache
Doing this exchange for every single packet would be wasteful, so each device keeps an ARP cache: a table of recently resolved IP-to-MAC mappings with a timeout (commonly a few minutes, varying by OS). As long as an entry is cached, the device skips straight to sending the frame.
A device can also send a gratuitous ARP, an unsolicited announcement of its own IP-to-MAC mapping, for example after an address change or gateway failover. Neighbors may update existing cache entries; whether they accept or create an entry depends on their implementation and policy. In the office analogy, it's someone announcing a desk move. Not every listener necessarily writes it down.
| Initial resolution | ARP Request | ARP Reply |
|---|---|---|
| Destination MAC | Broadcast (FF:FF:FF:FF:FF:FF) | Unicast, straight to the requester |
| Who sends it | A device resolving a neighbor | Normally the owner; a configured proxy can answer for another host |
| Who processes it | Every device on the segment | Only the original requester |
ARP cache vs. the switch's CAM table
The ARP cache and a switch's CAM table (Content Addressable Memory table, also called the MAC address table) get mixed up constantly, because both are just small lookup tables sitting one layer apart. They solve two different problems.
The ARP cache lives on IPv4 hosts and routers and maps an IP address to a MAC address: "who do I send this frame to?" The CAM table lives on a switch and maps a MAC address and VLAN to a port: "which wire does this address live on in this VLAN?" Layer 2 learning watches source MAC addresses, not IP addresses, as covered in Ethernet Frame & MAC Addressing. The desk directory is ARP; the switch's table tells the building's internal delivery system which corridor reaches a desk.
| Property | ARP Cache | CAM Table |
|---|---|---|
| Lives on | IPv4 hosts and routers | Each switch |
| Maps | IP address → MAC address | MAC address and VLAN → switch port |
| Built by | ARP requests and replies | Watching source MAC addresses on incoming frames |
| Answers | "Who do I send this frame to?" | "Which wire does this address live on?" |
Worked example: whose MAC do you need?
A workstation is 10.0.0.10/24 with gateway 10.0.0.1. In this example its selected route to 192.0.2.80 uses that gateway. Assuming no cached mapping, it broadcasts an ARP request for 10.0.0.1. The gateway replies with 02:00:00:00:00:01. The outgoing frame targets that MAC, while the enclosed IP packet still targets 192.0.2.80. Asking for the gateway is like finding the office's exit desk before visiting another building.
| Field | Illustrative request | Reply |
|---|---|---|
| EtherType | 0x0806 (ARP) | 0x0806 |
| Operation | 1 (request) | 2 (reply) |
| Sender protocol address | 10.0.0.10 | 10.0.0.1 |
| Target protocol address | 10.0.0.1 | 10.0.0.10 |
| Ethernet destination | ff:ff:ff:ff:ff:ff | The workstation's MAC |
Diagnose neighbor resolution
On Windows PowerShell, Get-NetNeighbor -AddressFamily IPv4 lists neighbor entries. On Linux with iproute2, ip neigh show does the same job. Entries and state names vary by OS; a stale entry can remain usable while its reachability is checked.
| Observation | Next check | What it means |
|---|---|---|
| Repeated requests, no reply | Verify prefix, VLAN, interface state, and the target's address at both ends | Resolution did not complete at this capture point. A host firewall dropping ping is not the same as failed ARP. |
| Gateway resolves, remote service fails | Inspect the selected route, upstream reachability, and service connection | A local mapping does not prove end-to-end connectivity. |
| One IP changes MAC unexpectedly | Compare gateway failover events and duplicate-address evidence | A change may be legitimate or suspicious; ARP alone does not authenticate the sender. |
Normal initial ARP requests are link-layer broadcasts, not routed IP packets. Routers do not forward those requests into another broadcast domain. A host resolves the next hop chosen by its routing table, often its default gateway. Proxy ARP is a local reply on another host's behalf, not forwarding the original broadcast. IPv6 uses Neighbor Discovery rather than ARP.
Related topics and sources
Connect this to packet flow across networks and DHCP address assignment.