ARP answers one local question: which MAC address should receive this IPv4 packet next?
Address Resolution Protocol connects Layer 3 IPv4 addressing to Layer 2 Ethernet delivery. A host may know the IPv4 destination, but an Ethernet frame still needs a destination MAC address. ARP supplies that local next-hop mapping. The crucial phrase is local next hop: ARP does not discover the MAC address of a remote server several routers away.
Use AP Networking ARP and Address Conflicts Practice Test to connect local resolution with the selected route and actual switch forwarding. The 75 items separate neighbor bindings from MAC-to-port entries and require interface, VLAN and time when attributing an address claim.
ARP request is broadcast because the sender does not yet know the target MAC
Suppose a host at 192.168.1.25/24 wants to send to 192.168.1.1. It knows the target IPv4 address but not the Layer 2 address. The host sends an ARP request to the Ethernet broadcast MAC address, asking which device owns 192.168.1.1.
The device that owns 192.168.1.1 responds with its MAC address. The sender can then place the IPv4 packet inside an Ethernet frame addressed to that MAC.
For a local destination, ARP resolves the destination host itself
Host A is 192.168.10.20/24 and Host B is 192.168.10.50/24. Because both addresses fall inside 192.168.10.0/24, Host A treats Host B as local.
The default gateway is not the forwarding target for ordinary same-subnet communication.
For a remote destination, ARP resolves the gateway—not the remote server
Now Host A at 192.168.10.20/24 wants to reach 203.0.113.40. The host sees that 203.0.113.40 is outside its local /24, so it sends the packet to the default gateway, perhaps 192.168.10.1.
This is one of the clearest ways to separate Layer 2 forwarding from Layer 3 routing.
Routers break the ARP domain because each routed link has its own Layer 2 next hop
An ARP broadcast is not forwarded across ordinary router boundaries. Each router removes the incoming Layer 2 frame, makes a Layer 3 forwarding decision, then constructs a new Layer 2 frame for the next local segment.
ARP caches improve efficiency but should not be treated as permanent truth
Hosts keep recently learned mappings so they do not broadcast an ARP request before every packet. Dynamic entries age or refresh according to operating-system behavior. Static entries can also exist.
| Entry type | How created | Operational meaning |
|---|---|---|
| Dynamic | Learned from ARP exchange | Temporary and refreshable |
| Static | Manually configured | Persists until changed/removed |
| Incomplete | Resolution attempted | No usable reply learned yet |
Swipe horizontally to see the ARP-cache table.
An ARP table shows local neighbor knowledge—not the complete network path
Commands such as arp -a or modern neighbor-table commands can show IPv4-to-MAC mappings learned by the host. A remote Internet server will usually not appear because the client only needs the MAC address of its local gateway.
A wrong mask can make a host ARP for something that should have been routed
Suppose Host A is really on 192.168.10.64/27 but is mistakenly configured as /24. A destination at 192.168.10.100 should be remote under /27, yet the /24 configuration makes Host A believe it is local.
If no direct Layer 2 path exists, the host can fail even though the gateway and remote destination are healthy.
Missing ARP response is a Layer 2 clue, but not a complete diagnosis
If a client repeatedly ARPs for its gateway and receives no reply, check whether the gateway interface is up, the client is in the correct VLAN, the switch is forwarding the broadcast correctly, and the configured gateway address is valid.
One IPv4 address mapping to different MAC addresses over time can reveal a conflict
If two hosts claim 192.168.10.50, clients may alternately learn different MAC addresses for that same IP. Traffic can appear intermittent because packets go to whichever MAC is currently cached.
Compare ARP tables, switch MAC tables, DHCP lease records, and physical endpoint identity to locate the conflict.
ARP tables and switch forwarding tables answer different questions
| Artifact | Maps | Useful for |
|---|---|---|
| ARP/neighbor table | IPv4 address → MAC address | Who owns this local next-hop IP? |
| Switch MAC/CAM table | MAC address → switch port/VLAN | Where did the switch learn this MAC? |
Swipe horizontally to see the artifact comparison.
Used together, these tables can turn an IP symptom into a specific switch-port investigation.
ARP failure can expose wrong VLAN placement
A client can broadcast ARP only within its Layer 2 broadcast domain. If the client and gateway are in different VLANs because of a switchport or SSID mapping error, the request may never reach the intended gateway interface.
Bad DHCP settings can lead to perfectly normal ARP behavior for the wrong next hop
A DHCP server can give a client the wrong default gateway or wrong subnet mask. ARP may then resolve exactly what the client was told to resolve—even though the overall configuration is wrong.
If the gateway resolves correctly, preserve that known-good boundary
Suppose a client has a valid ARP entry for 192.168.10.1 and can ping the gateway. The local link between client and gateway is known-good enough to move outward.
Internet failure now points more strongly toward routing, NAT, DNS, firewall policy, WAN state, or the remote service rather than local ARP.
ARP carries enough information to identify both the requester and the target
Reading these fields in a packet capture can confirm whether the host is asking for the expected next hop.
A host can announce or probe its own address without first receiving a normal request
Gratuitous ARP can be used to update neighbor caches, announce a newly active address, or help detect address conflicts. High-availability systems may use such announcements when an IP moves from one device to another.
Seeing a gratuitous ARP is not automatically malicious. Interpret it in the context of the network design.
Traditional ARP trusts local claims more than modern security designs would prefer
ARP does not strongly authenticate that the device claiming an IPv4 address is truly authorized to own it. An attacker on the same Layer 2 segment may attempt to poison neighbor caches by sending false mappings.
DAI can validate ARP claims against trusted bindings on supported enterprise switches
Dynamic ARP Inspection can compare ARP messages against trusted IP-to-MAC-to-port information, often derived from DHCP snooping. Invalid claims can be dropped rather than blindly trusted.
A security control can be enabled and still require correct trusted state
If DHCP snooping bindings are missing or static-address devices are not accounted for, a legitimate ARP can be rejected. Security features depend on accurate source-of-truth information.
Client cannot reach gateway and has an incomplete ARP entry
The host is 10.10.20.25/24 with gateway 10.10.20.1. Repeated ARP requests for 10.10.20.1 receive no reply.
Inference: investigate Layer 2 path, VLAN membership, gateway interface state, and gateway address. Do not jump directly to DNS or Internet routing.
Client can ping gateway but not a remote server
The ARP table contains a valid gateway mapping and gateway ping succeeds. The remote server still cannot be reached.
Inference: local ARP and client-to-gateway Layer 2 reachability are known-good enough to continue with routing, firewall, NAT, or destination checks.
One IP alternates between two MAC addresses
Users report intermittent reachability to 10.10.30.50. ARP evidence shows two different MAC addresses for that IP over a short period.
Inference: duplicate address or failover behavior is plausible. Check DHCP leases, static assignments, high-availability design, and switch-port learning.
Wrong subnet mask causes direct ARP for a remote host
A host at 192.168.1.70 should be /27 but is configured /24. It repeatedly ARPs for 192.168.1.100 instead of sending to the gateway.
Inference: local/remote classification is wrong because of the mask. Correct the prefix, then verify the host now resolves the gateway MAC for that remote destination.
Camera is in the wrong VLAN
A camera expected in VLAN 30 cannot ARP for 10.10.30.1. Switch inspection shows the access port assigned to VLAN 20.
Inference: fix VLAN placement, not the camera's gateway. After correction, confirm the camera learns the gateway MAC and receives the intended policy.
ARP artifacts become powerful when paired with another layer's evidence
| ARP evidence | Pair with | What it helps isolate |
|---|---|---|
| No gateway reply | Switch MAC table + VLAN config | Layer 2 placement/path |
| Two MACs for one IP | DHCP leases + switch ports | Duplicate IP |
| Gateway mapping valid | Route table + ping/traceroute | Move beyond local Layer 2 |
| ARP for unexpected host | IP/prefix config | Wrong subnet mask/locality |
| DAI drop | DHCP snooping bindings | Security-binding mismatch |
Swipe horizontally to see the evidence matrix.
Use ARP traffic to verify what the host believes about the next hop
Capture traffic while a client tries to reach a remote IP. If the client correctly believes the destination is remote, you should expect ARP for the default gateway—not for the remote IP itself.
Choose the next artifact from the ARP symptom
Most ARP mistakes come from confusing local Layer 2 delivery with end-to-end Layer 3 routing
- ARP does not resolve domain names.
- ARP does not discover every router on a path.
- A remote server's MAC is normally not needed by the source host.
- A valid ARP mapping does not prove DNS, routing, or Internet access works.
- An empty or incomplete ARP entry is evidence to investigate, not proof a device is dead.
- A wrong subnet mask can change which IP the host ARPs for.
Build the answer from locality, next hop, Layer 2 evidence, and verification
Destination: identify the IPv4 target.
Local or remote: use the source prefix to classify it.
Next hop: destination host or default gateway.
ARP target: which local IPv4 address should be resolved?
Evidence: request, reply, cache entry, switch MAC table, or packet capture.
Boundary: state what ARP does not prove.
Verification: retry the original communication after the Layer 2 issue is corrected.
24 ARP digital flashcards
Practice ARP requests and replies, same-subnet vs. remote traffic, gateway resolution, caches, wrong masks, duplicate IPs, VLAN failures, ARP tables, spoofing, DAI, DHCP snooping, and evidence boundaries.
Connect ARP to addressing, duplicate IPs, subnet masks, switching, and CLI evidence
Related troubleshooting deep dive
For a narrower evidence-based scenario, use Same-Subnet Devices Cannot Communicate: A Layer 2 Troubleshooting Guide. It includes a free interactive reasoning activity and step-by-step diagnostic evidence.