Local or Remote? The Decision That Drives Everything

Why you never ARP for a server on the other side of the world

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Apply the subnet mask to decide whether a destination is local or remote
▸Explain why a host ARPs for its gateway instead of the far destination
▸Diagnose a wrong subnet mask from the ARP traffic alone

Before this lesson — it builds directly on:

Why ARP Exists

Before a machine sends anything, it answers one question: is this destination on my own wire, or somewhere else? The answer completely changes what happens next. Local means 'talk to it directly'. Remote means 'hand it to the router and let them deal with it'. And here is the part that catches people out: for a remote destination, the machine never asks about the destination at all. It asks about the router. The destination's MAC address is not just unknown — it is *unknowable* from here, and it does not matter.

✗ Common misunderstanding: ARP can find the MAC address of any machine you can reach.

Why that's wrong: ARP works by broadcasting, and a broadcast stops at the first router. It can only ever resolve addresses inside your own broadcast domain.

Correct model: ARP resolves the NEXT HOP, not the destination. For anything off your subnet that next hop is the gateway.

The packets prove it: In the gateway-resolution trace the host pings 10.0.2.30 and never once asks about it — every request names 10.0.1.1.

✗ Common misunderstanding: The source MAC address in a packet tells you which machine sent it.

Why that's wrong: Every router rewrites both MAC addresses when it forwards. By the time a packet has crossed one hop, the original sender's MAC is gone for good.

Correct model: Source MAC identifies the PREVIOUS HOP. Only for traffic from your own subnet is it also the origin.

The packets prove it: Compare the echo request on each side of the router in the gateway trace: same IP addresses, completely different MAC addresses.

Watch these fields in the lab: ipv4.destIp · eth.destinationMac

PC1 is 10.0.1.10 with a /24 mask. It wants to reach 10.0.2.30. Is that local?

  A /24 mask means: the first 24 bits are the network, the last 8 are the host.
  24 bits = the first three numbers.

     my address        10 . 0 . 1 . 10
     my network        10 . 0 . 1            ← first three

     destination       10 . 0 . 2 . 30
     its network       10 . 0 . 2            ← first three

     10.0.1  ≠  10.0.2   →   REMOTE

  So: resolve the GATEWAY (10.0.1.1), not 10.0.2.30.

  Now try the same host with a /16 mask (first TWO numbers):

     my network        10 . 0
     its network       10 . 0

     10.0  =  10.0     →   LOCAL  (and wrong)

Same two addresses, opposite answers, and the only thing that changed was the mask. That is why a wrong mask is such a destructive misconfiguration: the machine behaves perfectly correctly on a false premise, ARPs for something unreachable, and gets silence. Nothing in the error message points at the mask.

Watch these fields in the lab: ipv4.destIp

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

A packet leaves your PC for a server on the internet. As it crosses eight routers, which addresses change?

A host is 192.0.2.10 with mask 255.255.255.0. Which of these destinations does it ARP for DIRECTLY?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.