How Does Address Resolution Protocol Work? | ARP Made Clear

You click a link, run a ping, or open an app, and your device starts sending packets. On an Ethernet or Wi-Fi LAN, those packets ride inside link-layer frames that need a destination MAC address. That’s where Address Resolution Protocol (ARP) shows up. It bridges “I know the IPv4 address” and “I can deliver a frame to the right network card.”

Below is the on-wire story, with the parts you can confirm in a packet capture: cache lookup, request, reply, and what happens when things go wrong.

What Problem ARP Solves On A LAN

IPv4 decisions use IP addresses. Ethernet delivery uses MAC addresses. A host can’t send an IPv4 packet inside an Ethernet frame until it knows the MAC address for the next hop on the same LAN segment.

Next hop keeps the logic tidy. If the destination IP is inside your subnet, the next hop is the destination host. If the destination IP is outside your subnet, the next hop is your default gateway. Either way, ARP maps next-hop IP to next-hop MAC.

How Address Resolution Protocol Works On A Local Ethernet

ARP is a request-reply exchange carried in a link-layer frame. The sender asks, “Who has this IP?” The owner answers, “I do, and here’s my MAC.” Requests are broadcast so every node on the segment can hear them. Replies are usually unicast back to the requester.

Step 1: The Host Checks The ARP Cache

Before any broadcast, the host checks a local table: the ARP cache. If there’s a fresh entry for the next hop IP, the host skips ARP and sends the frame right away.

Cache entries age out. They also refresh when traffic keeps flowing. That aging is why a test can pass once and fail later when the entry expires and ARP starts again.

Step 2: The Host Sends An ARP Request

If there’s no usable entry, the host crafts an ARP request. On Ethernet, it’s sent inside an Ethernet frame with the destination MAC set to broadcast (ff:ff:ff:ff:ff:ff). Switches flood that frame to all ports in the VLAN.

The ARP payload carries four addresses:

• Sender MAC and sender IP
• Target IP
• Target MAC (unknown in a request, often all zeros)

Step 3: The Target Replies

The device that owns the target IP returns an ARP reply that pairs its IP address with its MAC address. The reply is commonly unicast to the requester’s MAC.

Once the requester gets that reply, it writes a cache entry and sends the original IPv4 packet in an Ethernet frame addressed to the resolved MAC.

Step 4: Other Hosts Learn From Traffic They Hear

Many stacks also learn passively. When a device sees an ARP request or reply, it may record the sender’s IP-to-MAC mapping in its own cache. That side effect can cut later broadcasts on a busy segment.

ARP Packet Fields You’ll See In A Capture

On Ethernet + IPv4, the ARP message is short and predictable. It rides in an Ethernet frame with EtherType 0x0806. The message includes:

• HTYPE (hardware type): 1 for Ethernet
• PTYPE (protocol type): 0x0800 for IPv4
• HLEN and PLEN: 6 and 4 for MAC and IPv4 sizes
• OP: 1 request, 2 reply
• SHA/SPA: sender MAC and sender IP
• THA/TPA: target MAC and target IP

If you want the canonical field layout and the baseline request-reply rules, RFC 826 (An Ethernet Address Resolution Protocol) is the core spec.

What Triggers ARP And When It Stays Quiet

ARP shows up when a host needs a next hop MAC address and doesn’t have a valid cache entry. You’ll also see ARP during:

• First traffic after boot or after a cache flush
• Sleep, Wi-Fi roam, or link flap that resets state
• IP changes during DHCP renewals or manual edits
• Gateway failover that moves an IP to a new router MAC

On a stable LAN, ARP chatter stays low. When it spikes, it often points to a loop, a mask mismatch, an address conflict, or a device that keeps forgetting its cache.

Table: ARP Messages And What They Tell You

On-Wire Message	What You’re Seeing	Common Cause
Request: Who has 192.0.2.10?	Host needs a MAC for the next hop IP	Cache miss or entry expired
Reply: 192.0.2.10 is at 00:11:22:33:44:55	Target shares its MAC	Normal response
Request with SPA = TPA	Host announces or probes its own mapping	Boot, IP change, conflict check
Reply without a matching request	Announcement using a reply form	Some stacks update peers this way
Many requests for one IP, no replies	Resolution is failing	Host down, VLAN split, filtering
Conflicting replies for the same IP	Two MACs claim one IP	Duplicate IP or rogue device
Gateway replies for many non-gateway IPs	Proxy ARP behavior	Legacy subnet design or router setting
ARP table flips between two MACs	Mapping keeps changing	Failover pair or spoofing attempt

Where ARP Works And Where It Stops

ARP is local by design. ARP frames stay inside one broadcast domain, tied to a VLAN on a switch or an SSID mapped to a VLAN on Wi-Fi. Routers do not forward ARP broadcasts between subnets. If two devices sit on different VLANs, they can still talk at layer 3, but ARP will only ever resolve the MAC of the local next hop, often the router interface for that VLAN.

This boundary is a gift when you’re debugging. If you’re seeing ARP requests for a target IP and you know that IP lives on another subnet, the sender’s routing or mask is wrong. If you’re seeing no ARP at all and traffic still fails, the break is not in ARP. You can then shift your attention to routing, firewall rules, or the app layer.

Gratuitous ARP And Why You’ll See SPA Equal TPA

Not every ARP request is asking a question. A host can send a “gratuitous” ARP where the sender IP is the same as the target IP. The frame still goes to broadcast, yet the goal is different: announce a mapping, probe for an address conflict, or refresh peer caches after a MAC change.

Switchovers make this show up a lot. Think of a redundant router pair where one box takes over a virtual IP. The new active router may send a burst of gratuitous ARP so hosts update their cache and start sending frames to the new router MAC with minimal delay.

ARP With A Default Gateway

Most traffic goes off-subnet. Your host still uses ARP, but the ARP target is the gateway’s IP, not the remote site’s IP. Once the gateway MAC is cached, your machine can reach many remote IPs without more ARP, since every off-subnet packet goes to that same next hop MAC.

If you want to confirm what your machine thinks the mapping is, inspect the ARP cache. On Windows, the built-in arp command reference shows how to list entries and clear stale ones.

This is the mental model that saves time in troubleshooting: ARP resolves the next hop on the local segment. Routing handles the rest.

Proxy ARP And What It Changes

Proxy ARP is when a router answers ARP requests on behalf of another host. A device asks, “Who has 192.0.2.50?” and the router replies with its own MAC, then forwards traffic at layer 3. It can make odd subnet layouts behave like one flat LAN.

It can also confuse people reading captures. Local-looking traffic may head to a router MAC even when the target IP isn’t on the segment. If you see a router replying for many IPs that are not its own, proxy ARP is a likely reason.

Security Notes: ARP Spoofing And Cache Poisoning

ARP has no built-in authentication. Any node on the LAN can send an ARP reply claiming “this IP is at this MAC.” If another host accepts it, traffic can be redirected.

Defenses live outside ARP itself. Managed switches can validate ARP using features tied to DHCP snooping tables. Static ARP entries can lock down small, fixed setups. Segmentation also helps because it shrinks the broadcast domain.

If you suspect spoofing, watch for ARP table churn, replies that arrive without a matching request, or a gateway IP that suddenly maps to a new MAC.

Table: Troubleshooting Checks For ARP Issues

Symptom	Fast Check	What It Points To
Can’t reach a host on the same subnet	Check your ARP cache for a MAC entry for the target IP	No entry suggests ARP failure or VLAN split
ARP requests repeat, no reply	Verify link, VLAN, and that the target is powered on	Down host, wrong port, wrong SSID
Intermittent reachability	Flush the ARP cache, retry, watch if the mapping changes	Duplicate IP or unstable L2 path
Gateway works, local peer does not	Compare subnet masks on both hosts	Mask mismatch makes one side ARP for the gateway
One IP maps to two MACs over time	Search for a second device using the same static IP	Address conflict
Many devices fail at once	Check switch loop indicators and broadcast counters	L2 loop causing broadcast flood
Need to view or edit ARP entries on Windows	Use the arp command to list and modify the cache	Windows arp command reference for syntax and switches

ARP And IPv6: Why You Don’t See It There

ARP is tied to IPv4. IPv6 uses Neighbor Discovery (NDP) for similar tasks, carried in ICMPv6. On a dual-stack network, you’ll see ARP for IPv4 flows and NDP for IPv6 flows.

Two Fast Lab Drills That Make ARP Click

1. Flush the ARP cache, then ping a peer on the same subnet while capturing traffic. You’ll see request, reply, then the ICMP frames.
2. Ping an off-subnet IP. You’ll see ARP for the gateway, then the IP traffic, with no ARP for the remote site.

Once you can predict which IP will appear in the ARP target field, you can read most LAN issues from one capture and a quick glance at the cache.