The one rule to remember
A device uses ARP to find its next hop, not the final destination.
Destination on my subnet → the next hop is the destination, so ARP for the destination.
Destination on another subnet → the next hop is my default gateway, so ARP for the gateway.
You learned how a single ARP request and reply work in ARP fundamentals. This lesson answers a question that confuses many beginners: when PC-A talks to a server on the internet, whose MAC address does it ask for?
💡 In simple terms: to post a letter to another country, you don't need to know the foreign postman's name. You only need to know where your local post box is. ARP finds the post box (the gateway), and the address on the envelope (the destination IP address) does the rest.
Why this matters
- ARP requests are broadcasts, and routers do not forward broadcasts. A request for a remote server could never reach it.
- A MAC address is only useful on one local link. Even if PC-A knew the server's MAC address, no switch on PC-A's network could deliver a frame to it.
- Once you understand this, you can read
arp -aoutput correctly and quickly spot a wrong gateway or a wrong subnet mask.
The example network
| Device | IP address | MAC address | Role |
|---|---|---|---|
| PC-A | 192.168.10.10/24 | 02:00:00:00:00:aa | The sender in every example |
| PC-B | 192.168.10.20/24 | 02:00:00:00:00:bb | Same subnet as PC-A |
| R1 inside (G0/0) | 192.168.10.1/24 | 02:00:00:00:00:01 | PC-A's default gateway |
| R1 outside (G0/1) | 198.51.100.2/24 | 02:00:00:00:00:02 | Towards the provider |
| Provider router | 198.51.100.1/24 | 02:00:00:00:00:fe | R1's next hop |
| Remote server | 203.0.113.20 | Never learned by PC-A | On the internet |
Step 0: local or remote?
Before it sends any ARP request, PC-A uses its subnet mask to decide what the next hop is:
Case 1: same subnet (PC-A → PC-B)
PC-B (192.168.10.20) is on PC-A's own subnet. PC-A sends an ARP request for PC-B's IP address, learns PC-B's MAC address and sends the frame straight to it. The router is not involved at all.
- 1. ARP request for PC-B. PC-A has no cache entry for 192.168.10.20, so it broadcasts: who has 192.168.10.20? Tell 192.168.10.10.
- 2. Everyone on the subnet hears it. R1 receives it too, but the target IP address isn't R1's, so R1 does not reply. It also does not forward the broadcast to other networks.
- 3. PC-B replies (unicast). PC-B replies directly to PC-A with its MAC address, 02:00:00:00:00:bb.
- 4. The data frame goes straight to PC-B. Destination MAC = PC-B, destination IP = PC-B. The router is not involved.
Case 2: remote destination (PC-A → 203.0.113.20)
The server 203.0.113.20 is on another network. PC-A does not send an ARP request for 203.0.113.20. It sends one for its default gateway, 192.168.10.1, and then sends the frame to the gateway's MAC address. The packet inside is still addressed to 203.0.113.20.
- 1. ARP request for the gateway. 203.0.113.20 is remote, so PC-A asks: who has 192.168.10.1? It never asks for 203.0.113.20.
- 2. The broadcast stays on the subnet. PC-B ignores it, and R1 recognises its own address. R1 does not forward the broadcast any further.
- 3. R1 replies (unicast). R1 tells PC-A: 192.168.10.1 is at 02:00:00:00:00:01. PC-A caches it.
- 4. Frame to the gateway, packet to the server. Destination MAC = R1, destination IP = the server.
- 5. R1 forwards in a new frame. R1 removes the old frame, uses its own ARP table to find its next hop (198.51.100.1) and sends the same packet on.
The frames side by side
Here are the two data frames PC-A sends after ARP has done its job. Compare the highlighted fields.
Case 1 · Local: PC-A → PC-B
ARP target was 192.168.10.20
Case 2 · Remote: PC-A → server
ARP target was 192.168.10.1 (the gateway)
| Case 1: local | Case 2: remote | |
|---|---|---|
| Next hop | PC-B itself | Default gateway R1 |
| ARP target IP | 192.168.10.20 | 192.168.10.1 |
| Frame destination MAC | 02:00:00:00:00:bb (PC-B) | 02:00:00:00:00:01 (R1) |
| Packet destination IP | 192.168.10.20 (PC-B) | 203.0.113.20 (server) |
| MAC and IP point at… | The same device | Different devices |
| Router involved? | No | Yes |
What happens at each hop
A new frame is built for every link, while the packet inside travels on unchanged. On each link, the sender uses ARP to find its own next hop.
| Link | Who sends ARP, for which IP | Src MAC → Dst MAC | Src IP → Dst IP |
|---|---|---|---|
| PC-A → R1 | PC-A for 192.168.10.1 | …:aa → …:01 | 192.168.10.10 → 203.0.113.20 |
| R1 → provider | R1 for 198.51.100.1 | …:02 → …:fe | 192.168.10.10 → 203.0.113.20* |
| Last router → server | That router for 203.0.113.20 | its MAC → server's MAC | 192.168.10.10 → 203.0.113.20* |
* If R1 is a home or edge router running NAT, it also replaces the private source IP address with its public address (here 198.51.100.2). The destination IP address still does not change. Only the last router, the one on the server's own subnet, ever sends an ARP request for the server's IP address.
The ARP cache before and after
Before PC-A sends anything:
C:\> arp -a Interface: 192.168.10.10 --- 0xb Internet Address Physical Address Type 192.168.10.255 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 static 255.255.255.255 ff-ff-ff-ff-ff-ff static
After ping 192.168.10.20 (Case 1):
C:\> arp -a Interface: 192.168.10.10 --- 0xb Internet Address Physical Address Type 192.168.10.20 02-00-00-00-00-bb dynamic 192.168.10.255 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 static 255.255.255.255 ff-ff-ff-ff-ff-ff static
192.168.10.20 → 02-00-00-00-00-bb. PC-A learned PC-B's MAC address with ARP. (Windows writes MAC addresses with hyphens.)After ping 203.0.113.20 (Case 2), and browsing a few websites:
C:\> arp -a Interface: 192.168.10.10 --- 0xb Internet Address Physical Address Type 192.168.10.1 02-00-00-00-00-01 dynamic 192.168.10.20 02-00-00-00-00-bb dynamic 192.168.10.255 ff-ff-ff-ff-ff-ff static 224.0.0.22 01-00-5e-00-00-16 static 255.255.255.255 ff-ff-ff-ff-ff-ff static
192.168.10.1 now appears, but 203.0.113.20 is not in the cache, and neither is any website. All remote traffic uses the single gateway entry. This proves that PC-A used ARP to find the gateway, not the server.$ ip neigh 192.168.10.1 dev eth0 lladdr 02:00:00:00:00:01 REACHABLE 192.168.10.20 dev eth0 lladdr 02:00:00:00:00:bb STALE
What goes wrong
1. The gateway address is wrong
PC-A's gateway is set to 192.168.10.99, which no device uses. Local traffic still works. For remote traffic, PC-A sends an ARP request for .99, nobody answers, and the packet is never sent.
- 1. PC-A sends ARP for the wrong gateway. To reach 203.0.113.20, PC-A needs its gateway's MAC address, so it broadcasts an ARP request for 192.168.10.99.
- 2. Nobody owns .99. PC-B and R1 both ignore it. R1 is the real gateway, but it only answers for its own address, 192.168.10.1.
- 3. No MAC, no frame. PC-A retries, then gives up. ping shows “Destination host unreachable” from PC-A's own address.
C:\> ping 203.0.113.20 Pinging 203.0.113.20 with 32 bytes of data: Reply from 192.168.10.10: Destination host unreachable. Reply from 192.168.10.10: Destination host unreachable. Reply from 192.168.10.10: Destination host unreachable. Reply from 192.168.10.10: Destination host unreachable.
192.168.10.10, PC-A's own address, not from a router. PC-A is reporting that it could not get a MAC address for its next hop, so the packets never left the PC.If the gateway is set to another PC (for example, PC-B), ARP succeeds. But PC-B is not a router, so it normally drops the packets and the ping simply times out. If the gateway address is in a different subnet, PC-A can't use ARP to reach it at all.
Learn more: The Default Gateway
2. The subnet mask is wrong
Suppose PC-A is set to /8 (255.0.0.0) instead of /24, and tries to reach a company server at 192.168.20.5 on another subnet behind R1. With /8, PC-A compares only the first octet: 192 = 192, so it believes the server is local. It sends an ARP request for 192.168.20.5 directly. That host is behind the router, so the broadcast never reaches it and nobody answers.
| PC-A's mask | 192.168.20.5 looks… | ARP target | Result |
|---|---|---|---|
| /24 (correct) | Remote | 192.168.10.1 (gateway) | Works |
| /8 (wrong) | Local | 192.168.20.5 (the server itself) | No ARP reply; fails |
Some routers run proxy ARP and answer such a request on the server's behalf, which can hide this mistake.
Learn more: Gratuitous ARP, Probes and Proxy ARP
3. ARP for a local host fails
If PC-B is switched off, unplugged, in a different VLAN or has a different IP address than you think, PC-A's ARP request gets no reply. The symptom is the same "Destination host unreachable" message, and ip neigh on Linux shows the entry as FAILED or INCOMPLETE.
$ ip neigh show 192.168.10.20 192.168.10.20 dev eth0 FAILED
lladdr (MAC address) on the line, and the state is FAILED. Linux sent ARP requests for 192.168.10.20 and got no reply.Troubleshooting checklist
- Decide local or remote yourself from the PC's IP address and subnet mask. Is the next hop the destination or the gateway?
- Check the gateway setting with
ipconfigorip route. On Linux,ip route get 203.0.113.20shows the next hop it will use. - Ping the next hop (PC-B, or the gateway).
- Look at the ARP cache with
arp -aorip neigh. The next hop should be listed with the correct MAC address. - Missing or FAILED entry: the next hop isn't answering ARP. Check the address, the cable and the VLAN, and check that the device is switched on.
- Want to see it happen? Start a Wireshark capture with the display filter
arp, then run the ping.
Common mistakes
- Expecting to see a server's MAC address in arp -a after visiting it. Remote hosts never appear; only the gateway does.
- Thinking the destination IP of remote traffic is the gateway's IP. The packet is still addressed to the server. The gateway's IP address is only the ARP target.
- Blaming the router when PC-A's gateway setting is wrong. With an unused gateway address, the router never even receives the packet.
- Forgetting that every router uses ARP too. Each router resolves its own next hop on each of its own links.
- ARP always resolves the next hop, which the PC chooses by comparing network parts using its subnet mask.
- Local destination: ARP for the destination itself; the destination MAC and IP point at the same device.
- Remote destination: ARP for the default gateway, never for the remote IP; destination MAC = gateway, destination IP = remote host.
arp -aon a PC shows local neighbours and the gateway, never internet servers.- Wrong gateway: the ARP request fails or reaches a device that isn't a router. Wrong mask: the PC sends ARP for remote hosts directly and gets no answer.
Check yourself
PC-A (192.168.10.10/24, gateway 192.168.10.1) pings 203.0.113.20 with an empty ARP cache. What is the target IP in its ARP request?
PC-A pings PC-B (192.168.10.20). What is the destination MAC address of the frame that carries the ping?
After browsing ten websites, how many entries for those websites appear in PC-A's ARP cache?
PC-A's gateway is set to 192.168.10.99 (unused). It pings PC-B and then 203.0.113.20. What happens?
PC-A has mask /8 by mistake and tries to reach 192.168.20.5 on another subnet. What does it ARP for?
Later lessons cover special ARP messages and put the whole journey together, step by step.
Learn more: Gratuitous ARP, Probes and Proxy ARPSame-Subnet CommunicationDifferent-Subnet Communication