ARP: how IPs become MACs
Address Resolution Protocol is the bridge between Layer 3 and Layer 2. Every time a host wants to send a packet, it must first learn the MAC address that corresponds to the next-hop IP. This lesson traces an ARP request and reply end to end.
Open this labWhy ARP exists
IP packets travel inside Ethernet frames. The IP header carries source and destination IPs; the Ethernet header carries source and destination MAC addresses. Switches forward by MAC, not by IP. So a host that knows it wants to send a packet to 10.0.0.5 still needs to know which MAC address to put in the Ethernet header.
ARP solves this. Given a target IP, ARP returns the MAC address of the device that owns it (if it lives on the same subnet) or of the default gateway (if it doesn't).
The request
When PC1 wants to send to 10.0.0.5, it builds an ARP request: a broadcast Ethernet frame asking 'who has 10.0.0.5? tell PC1's MAC'. Because the destination MAC is FF:FF:FF:FF:FF:FF, the switch floods the frame to every port. Every host in the broadcast domain receives it, but only the host owning 10.0.0.5 answers.
The reply
The owner of 10.0.0.5 sends a unicast ARP reply directly back to PC1. The reply contains its own IP and MAC. PC1 caches that mapping in its ARP table for a few minutes and uses it for subsequent frames. The switch, having seen PC2's MAC arrive on a specific port, also learns its forwarding entry — so subsequent unicast frames don't flood.
Where ARP fails
ARP fails when the target IP isn't on the local subnet AND no default gateway is configured. The host has nobody to ask; the broadcast cannot leave the broadcast domain. NetForge-AI logs this clearly: 'destination not on subnet and no default gateway'. Add the gateway, retry, and ARP resolves the gateway's MAC instead.
Practice this in the lab
Reading helps. Wiring it up yourself and breaking it makes it stick.
Open the lab