Lesson
ARP and Local Delivery
Learning objective
Explain how IPv4 nodes resolve a local next-hop IP address to a MAC address.
Why ARP exists
An IPv4 application may know a destination IP address, but Ethernet needs a destination MAC address for the next local link. The Address Resolution Protocol (ARP) supplies that missing association: it asks which local interface owns a next-hop IPv4 address and learns the MAC address in the reply.
Think of the IP address as the destination written on a journey plan and the MAC address as the delivery label needed for the next room. The analogy has a limit: ARP is a local evidence exchange, not a trusted identity check and not a way to discover every router on the end-to-end path.
ARP is carried directly inside an Ethernet frame with EtherType 0x0806; it is not carried inside
an IPv4 packet. ARP resolves IPv4 next hops. IPv6 uses Neighbor Discovery instead.
Choose the next hop first
Before sending ARP, a host applies its interface prefix and routing table:
- If the destination is on-link, the host resolves the destination host's IPv4 address.
- If the destination is remote, the host resolves the selected gateway's local IPv4 address.
- The final IP destination remains unchanged when the Ethernet destination becomes the gateway MAC.
For example, 192.0.2.10/24 treats 192.0.2.20 as local, so it asks for 192.0.2.20. To reach
198.51.100.50, it instead asks for its gateway such as 192.0.2.1. A host does not ARP for a
remote server across a router.
Request, reply and cache
ARP packet format
Swipe sideways to see all fields
| Hardware type · 2 bytes | Protocol type · 2 bytes | ||||||||||
| Hardware length · 1 byte | Protocol length · 1 byte | Operation · 2 bytes | |||||||||
| Sender hardware (MAC) address · 6 bytes | |||||||||||
| Sender protocol (IPv4) address · 4 bytes | |||||||||||
| Target hardware (MAC) address · 6 bytes | |||||||||||
| Target protocol (IPv4) address · 4 bytes | |||||||||||
When no usable neighbour entry exists, the normal exchange is:
- The sender creates an ARP request: “Who has the next-hop IP? Tell the sender.”
- Ethernet carries it to
FF:FF:FF:FF:FF:FF, so the switch floods eligible interfaces except ingress. - Every local receiver can inspect the request, but normally only the owner answers.
- The owner returns an ARP reply, normally by unicast, containing its IPv4-to-MAC mapping.
- The sender caches the mapping and can finally build the data frame.
The ARP message includes hardware and protocol types, address lengths, an operation, and sender and target hardware/protocol addresses. In a request the target MAC is unknown inside the ARP message, while the enclosing Ethernet destination is broadcast. These two fields must not be confused.
Cache entries age because local evidence can change. A usable cached mapping avoids a fresh broadcast; an unanswered request can leave an incomplete entry and prevents the original frame from being built.
Interactive ARP journey
Follow the next-hop decision, open the Ethernet and ARP information at each stage, and watch the broadcast request fan out before the unicast reply returns. The player starts automatically unless reduced motion is enabled, and every stage remains available through manual controls.
Watch ARP resolve the next hop
Change the situation, then follow the next-hop decision, ARP evidence, cache state and resulting Ethernet delivery.
Host A resolves Host B's IPv4 address before it can build the Ethernet frame that carries the original packet.
- Host A: Host A eth0Switch: Switch Gi0/1
- Switch: Switch Gi0/2Host B: Host B eth0
- Switch: Switch Gi0/3Gateway: Gateway Gi0/0
Active: Host A
Step 1 of 9
1. Choose the local next hop
Host A applies /24 to 192.0.2.20 and identifies an on-link destination. The next hop is Host B itself, not the gateway.
Packet inspector
Inside the packet
Host or device decision
No frame is crossing a link during this step.
- Source
- 192.0.2.10/24
- Destination
- 192.0.2.20
- Next-hop IP
- 192.0.2.20Changed at this hop
Technical packet details
- Decision
- On-link: resolve the destination host
ARP variants and boundaries
| Term | Purpose | Important boundary |
|---|---|---|
| Standard ARP | Resolve a local IPv4 next hop to a MAC address | Request is broadcast; reply is normally unicast |
| Proxy ARP | A router answers for another IPv4 destination using its own local MAC | Can provide reachability while hiding an addressing mistake |
| Gratuitous ARP | Announce or probe the sender's own mapping | Used for conflict detection, cache updates and failover; acceptance is implementation-dependent |
| RARP | Historically asked for an IPv4 address using a known hardware address | Obsolete predecessor displaced by BOOTP and DHCP |
| Inverse ARP | Historically learned a protocol address from a known virtual-circuit identifier | Not ordinary Ethernet ARP; revisited with legacy Frame Relay |
Explore ARP variants packet by packet
Select a journey to see what is already known, what must be discovered and where the exchange is allowed to travel.
A host discovers the MAC address of an IPv4 neighbour on its local Layer 2 network.
- Host A: Host A eth0Switch: Switch Gi0/1
- Switch: Switch Gi0/2Host B: Host B eth0
- Switch: Switch Gi0/3Gateway: Gateway Gi0/0
Active: Host A
Step 1 of 4
1. Check the neighbour cache
Host A has no usable mapping for 192.0.2.20, so it must ask the local broadcast domain.
Packet inspector
Inside the packet
Host or device decision
No frame is crossing a link during this step.
- Lookup
- 192.0.2.20 → incompleteChanged at this hop
Technical packet details
- Next action
- Send a local ARP request
Standard ARP: resolve the next local hop
Scenario: Host A wants to send to Host B on the same subnet, but it knows only Host B's IPv4 address. Host A first checks its neighbour cache. If no usable mapping exists, it sends an ARP request inside an Ethernet broadcast frame. The switch floods a copy through every eligible port except the ingress port. Host B recognizes its own IPv4 address and normally sends a unicast ARP reply containing its MAC address. Host A caches the mapping and can then send the original data frame.
The important sequence is choose next hop → resolve its MAC → send the data. ARP does not find an end-to-end route, test whether an application is listening, or prove that the reply is trustworthy. For a remote destination, standard ARP resolves the gateway's local address rather than the remote server's address.
Proxy ARP: a router answers for another address
Scenario: a host treats a destination as local because of its subnet mask, even though reaching that destination actually requires a router. When Proxy ARP is enabled and the router has a suitable route, the router can answer the host's ARP request using the router interface's own MAC address. The host then sends the frame to the router, which routes the enclosed IP packet onward.
Proxy ARP can preserve connectivity for legacy systems or during a migration, but it can also conceal an incorrect mask, missing gateway, or poor network design. It increases ARP dependence and makes the Layer 3 boundary less obvious during troubleshooting. Do not confuse Proxy ARP with forwarding an ARP broadcast through a router: the request remains local; the router deliberately generates an answer.
Gratuitous ARP: announce your own mapping
Scenario: an active gateway takes over a shared virtual IP after the previous gateway fails. The new active device sends a Gratuitous ARP so nearby hosts and switches can learn that the IP-to-MAC ownership has changed. A device may also use this form of ARP while checking for a duplicate IPv4 address or refreshing neighbour caches after an interface change.
Unlike a normal resolution exchange, the sender announces or probes its own address without first receiving a matching request. The message is commonly broadcast so the local domain can inspect it, but whether a receiver updates its cache is implementation- and policy-dependent. Gratuitous ARP is useful operational evidence, not authenticated ownership; attackers can forge it, which we will examine in the later security pathway.
RARP: historical address discovery
Reverse ARP (RARP) was designed for a device that knew its hardware address but did not yet know its own IPv4 address. A diskless workstation could broadcast a request and depend on a RARP server to return a configured IPv4 address. The exchange was tied to the local link and provided far less configuration than modern bootstrapping requires.
RARP does not perform ordinary next-hop resolution. Its direction and purpose are different: it asks “Which IP address belongs to my known MAC?” rather than “Which MAC should receive traffic for this known next-hop IP?” BOOTP and then DHCP replaced RARP because they can provide addressing plus gateway, DNS, lease, and other configuration information.
Inverse ARP: discover an address across a virtual circuit
Inverse ARP starts with a known virtual circuit—such as a Frame Relay DLCI—and asks which network-layer address is reachable across it. That is the inverse of the information problem solved by ordinary ARP: the link or circuit identifier is already known, while the peer's protocol address must be learned.
Inverse ARP is not part of a normal switched-Ethernet host exchange and should not be used to explain today's Ethernet neighbour cache. It appears here so learners can recognize the term and its relationship to legacy non-broadcast multi-access networks. The full Frame Relay packet journey belongs in the later WAN lesson, where DLCIs, virtual circuits, mappings, and hub-and-spoke behavior can be shown accurately.
Compare the variants
- Standard ARP: “I know the next-hop IPv4 address; which local MAC should receive the frame?”
- Proxy ARP: “A router is answering locally on behalf of another IPv4 destination.”
- Gratuitous ARP: “I am announcing or probing my own IPv4-to-MAC mapping.”
- RARP: “I know my MAC but historically need a server to tell me my own IPv4 address.”
- Inverse ARP: “I know a virtual-circuit identifier but need to learn the peer's protocol address.”
Across these cases, keep the boundary visible: ARP broadcasts remain inside their Layer 2 broadcast domain; routers do not ordinarily forward them. A reply or announcement is local evidence and must not be treated as proof of identity.
Inspect neighbour evidence
I know this—proceed to advancedUse the operating system's neighbour table and a capture together. A cache entry reports local state; it does not prove that the application works or that the mapping is legitimate.
- Windows legacy view:
arp -a - Windows PowerShell:
Get-NetNeighbor -AddressFamily IPv4 - Linux:
ip neigh show
Common states include reachable/validated, stale, probe or delay transitions, and incomplete/failed. Names and timers vary by operating system, so interpret the state with recent traffic and capture evidence.
Basic Wireshark check
Display filter: arp
Fields to inspect
frame.numbereth.srceth.dstarp.opcodearp.src.proto_ipv4arp.src.hw_macarp.dst.proto_ipv4arp.dst.hw_mac
Normal evidence: A request uses Ethernet broadcast and asks for one target IPv4 address. A normal owner reply associates that IPv4 address with its MAC and is usually unicast to the requester.
Try it: Clear only the relevant dynamic neighbour entry in a safe lab, generate one ping, and correlate the cache miss, request, reply, cache update and first data frame.
Troubleshoot ARP methodically
- Record the source address, prefix, destination and selected route.
- Decide whether the intended next hop is the destination or a gateway.
- Inspect the relevant neighbour entry without clearing unrelated evidence.
- Capture on the correct local interface and verify the request leaves.
- Confirm the switch floods within the correct VLAN and excludes ingress.
- Check whether an owner or configured proxy replies with the expected mapping.
- Compare the reply with the cache and then test the original traffic in both directions.
If no request appears, investigate route selection, interface state and an already-usable cache entry. If requests appear without replies, verify VLAN membership, target availability, duplicate addressing, host filtering and whether the target IP is actually local. Repeated incomplete entries show failed resolution; they do not by themselves identify which device or link caused the failure.
Proxy ARP deserves special suspicion when an incorrectly masked host still reaches another subnet. Compare the host's prefix and intended gateway with the router's proxy configuration before accepting reachability as proof that addressing is correct.
Interview scenario
A host can reach a remote server, but its neighbour table contains only the gateway and not the server. Is that a fault?
Show answer and reasoning
No. The IP destination is remote, so the host resolves only the local next hop—the gateway. The router uses separate Layer 2 delivery on later links. Confirm the route, gateway mapping and packet's unchanged remote IP destination rather than expecting a remote-server MAC in the local cache.
Interview scenario
Two devices report the same IPv4 address after a failover. What ARP evidence would you collect?
Show answer and reasoning
Capture gratuitous announcements and ordinary requests/replies, compare sender MACs and timing, inspect neighbour-cache changes, and identify the intended owner. A failover announcement can legitimately refresh a shared address, while alternating or conflicting replies may indicate duplicate ownership.
Knowledge check and summary
Remember: choose the next hop, inspect the cache, resolve only when necessary, then build the frame. Always distinguish the ARP target IP from the final packet destination and the Ethernet broadcast field.