Free lesson · Computer Networking

Linux / macOS

Easy10 min readnetworkingcomputer-networkstcp-ip

The Gap Between Layer 2 and Layer 3

You have learned that IP addresses handle routing across networks (Layer 3) and MAC addresses handle delivery within a local network (Layer 2). But this creates an immediate practical problem: when a device wants to send a packet to another device on the same local network, it knows the destination IP address but does not know the destination MAC address. And it needs the MAC address to build the Ethernet frame for local delivery.

Consider a simple scenario: your laptop (IP 192.168.1.10) wants to send an HTTP request to a local server (IP 192.168.1.50). Your laptop knows the destination IP. But to create the Ethernet frame that carries the IP packet across the local network, it needs the server's MAC address in the destination MAC field. Without that MAC address, the frame cannot be created, and the packet has nowhere to go.

ARP (Address Resolution Protocol) bridges this gap. It translates a known IP address into the corresponding MAC address on the local network. ARP is one of the most fundamental protocols in networking - every device on every IPv4 network uses it constantly, even though users and application developers are rarely aware of it.

ARP operates at the boundary between Layer 2 and Layer 3. It uses Ethernet broadcast at Layer 2 to find the MAC address associated with an IP address at Layer 3. It is defined in RFC 826 (published in 1982) and has remained essentially unchanged since - a testament to the simplicity and effectiveness of its design.

The ARP Request/Reply Cycle

ARP works through a simple two-step broadcast-and-response process:

Step 1: ARP Request (Broadcast)

The requesting device (say, your laptop at 192.168.1.10) constructs an ARP request that says: "Who has IP address 192.168.1.50? Tell 192.168.1.10." This ARP request is encapsulated in an Ethernet frame with the destination MAC set to FF:FF:FF:FF:FF:FF - the broadcast address. The switch forwards this frame to every port in the same VLAN (the same broadcast domain).

Every device on the local network receives the ARP request and examines it. Each device checks whether the requested IP address (192.168.1.50) matches its own IP address. All devices except the one with IP 192.168.1.50 silently discard the request.

Step 2: ARP Reply (Unicast)

The device with IP 192.168.1.50 recognizes the request as being for its address. It constructs an ARP reply that says: "192.168.1.50 is at MAC address dc:a6:32:11:55:99." This reply is sent as a unicast frame directly back to the requester's MAC address (not broadcast, because the requester's MAC address was included in the ARP request).

The requesting device receives the reply, extracts the MAC address, and can now build the Ethernet frame to send the original IP packet. It also stores the IP-to-MAC mapping in its ARP cache for future use, so it does not need to broadcast another ARP request the next time it communicates with the same device.

sequenceDiagram
    participant A as Laptop<br/>192.168.1.10<br/>aa:bb:cc:11:22:33
    participant SW as Switch
    participant B as Server<br/>192.168.1.50<br/>dc:a6:32:11:55:99
    participant C as Other Device<br/>192.168.1.20

    Note over A: Need MAC for 192.168.1.50<br/>Not in ARP cache

    A->>SW: ARP Request (broadcast)<br/>"Who has 192.168.1.50?"
    SW->>B: ARP Request (forwarded)
    SW->>C: ARP Request (forwarded)

    Note over C: Not my IP - discard

    B->>SW: ARP Reply (unicast)<br/>"192.168.1.50 is at dc:a6:32:11:55:99"
    SW->>A: ARP Reply (forwarded)

    Note over A: ARP cache updated:<br/>192.168.1.50 → dc:a6:32:11:55:99

    A->>SW: IP Packet in Ethernet frame<br/>Dst MAC: dc:a6:32:11:55:99
    SW->>B: Forwarded to correct port

This sequence diagram shows the ARP request and reply cycle. The laptop at 192.168.1.10 needs to find the MAC address for 192.168.1.50. It sends a broadcast ARP request through the switch. The switch forwards the request to all devices. The server at 192.168.1.50 recognizes the request and sends a unicast ARP reply back with its MAC address dc:a6:32:11:55:99. The other device at 192.168.1.20 discards the request because it is not for its IP. The laptop updates its ARP cache and can now send IP packets to the server using the correct destination MAC address.

The ARP Cache

Every device maintains an ARP cache (also called an ARP table) - a local store of IP-to-MAC mappings that it has learned through ARP. When a device needs to send a frame, it first checks its ARP cache. If the destination IP address is in the cache, it uses the stored MAC address without sending an ARP request. If the destination is not in the cache, it initiates the ARP request/reply cycle.

ARP cache entries have a timeout (typically 60 seconds to 4 hours, depending on the operating system - Linux defaults to about 60 seconds for stale entries, Windows defaults to 15-45 seconds, and macOS defaults to 20 minutes). After the timeout, the entry is removed, and the next communication with that IP address will trigger a new ARP request. This timeout ensures the cache stays current - if a device's MAC address changes (due to a NIC replacement, a VM migration, or an interface failover), the stale cache entry will eventually expire and be replaced with the correct mapping.

The variation in timeout values across operating systems reflects different trade-offs between ARP traffic volume (shorter timeouts generate more ARP requests) and cache freshness (longer timeouts risk using stale mappings). In data center environments where virtual machine migration is common, shorter ARP cache timeouts reduce the window during which traffic is sent to an outdated MAC address after a migration event.

You can view your device's ARP cache right now:

# Linux / macOS
arp -a

# Example output:
# ? (192.168.1.1) at aa:bb:cc:dd:ee:ff on en0 ifscope [ethernet]
# ? (192.168.1.50) at dc:a6:32:11:55:99 on en0 ifscope [ethernet]

# Windows
arp -a

# Linux (modern tool)
ip neigh show

The output shows each entry as an IP address mapped to a MAC address, along with the network interface and the entry's state (reachable, stale, delay, etc.).

Gratuitous ARP

A gratuitous ARP is an ARP message where a device announces its own IP-to-MAC mapping without being asked. The device sends an ARP reply (or request) with its own IP address as both the source and target. This serves two purposes:

Announcing a new or changed mapping. When a device boots up, changes its IP address, or performs a failover (e.g., a server taking over a floating IP from a failed primary), it sends a gratuitous ARP so all devices on the network update their ARP caches immediately, without waiting for the old entries to time out.
Detecting IP conflicts. If a device sends a gratuitous ARP for its own IP address and receives a reply, it means another device on the network already has that IP. The device can then alert the user or take corrective action.

Gratuitous ARP is critical in high-availability setups. When a primary server fails and a secondary server takes over its IP address, the secondary sends a gratuitous ARP to tell all devices on the network to update their ARP caches with the secondary's MAC address. Without this, traffic would continue being sent to the failed primary's MAC address until ARP cache entries expired naturally - potentially minutes of downtime that could have been resolved in milliseconds.

ARP and the Default Gateway

ARP behaves differently depending on whether the destination is on the local network or a remote network:

Local destination (same subnet): If your device at 192.168.1.10/24 wants to reach 192.168.1.50, the destination is on the same subnet. Your device ARPs directly for 192.168.1.50 to get its MAC address, then sends the frame directly to that MAC.

Remote destination (different subnet): If your device at 192.168.1.10/24 wants to reach 10.0.3.15 (on a completely different network), the destination is not on the local subnet. Your device cannot ARP for 10.0.3.15 because that device is not on the local network and will never see the broadcast. Instead, your device ARPs for the default gateway (your router, say 192.168.1.1) to get the router's MAC address. It then sends the IP packet to the router's MAC address, with the destination IP still set to 10.0.3.15. The router receives the frame, strips the Ethernet header, reads the IP destination, makes a routing decision, and wraps the packet in a new Ethernet frame for the next hop.

This two-level addressing scheme is one of the most elegant designs in networking, and it is a crucial concept: the destination MAC address changes at every hop, but the destination IP address stays the same throughout the entire journey. From your laptop to the router, the destination MAC is the router's MAC. From the router to the next hop, the destination MAC changes to the next hop's MAC. But the destination IP remains 10.0.3.15 at every step, because the IP address is what guides the routing decisions.

graph LR
    subgraph LocalNetwork["Local Network 192.168.1.0/24"]
        LAPTOP["Laptop<br/>192.168.1.10<br/>MAC: AA"]
        ROUTER["Router<br/>192.168.1.1<br/>MAC: RR"]
    end

    subgraph RemoteNetwork["Remote Network 10.0.3.0/24"]
        SERVER["Server<br/>10.0.3.15<br/>MAC: SS"]
    end

    LAPTOP -->|"Frame 1<br/>Dst MAC: RR<br/>Dst IP: 10.0.3.15"| ROUTER
    ROUTER -->|"Frame 2<br/>Dst MAC: SS<br/>Dst IP: 10.0.3.15"| SERVER

    style LAPTOP fill:#4f46e5,stroke:#4338ca,color:#fff
    style ROUTER fill:#7c3aed,stroke:#6d28d9,color:#fff
    style SERVER fill:#8b5cf6,stroke:#7c3aed,color:#fff

This diagram shows how MAC addresses change at each hop while IP addresses stay constant. The laptop at 192.168.1.10 sends a frame to the router with destination MAC set to the router's MAC (RR) and destination IP set to the remote server at 10.0.3.15. The router then creates a new frame with destination MAC set to the server's MAC (SS) but the same destination IP of 10.0.3.15. The destination MAC changes at each hop to handle local delivery, while the destination IP stays constant to guide routing across the entire path.

Proxy ARP

Proxy ARP is a technique where a router answers ARP requests on behalf of devices on a different network. If a device sends an ARP request for an IP address that is not on the local network, a router configured with proxy ARP will respond with its own MAC address, effectively saying "send the traffic to me and I will forward it." The device then sends frames to the router's MAC address, and the router routes the packets to the actual destination.

Proxy ARP is used in situations where devices are not properly configured with subnet masks or default gateways. It can also be used to make two physical networks appear as a single logical network without reconfiguring the devices. However, proxy ARP has significant drawbacks: it increases ARP traffic, makes troubleshooting more complex because ARP responses do not reflect actual network topology, and can create security vulnerabilities if not carefully controlled. Most modern network designs avoid proxy ARP in favor of proper subnetting and routing configuration.

In cloud environments, proxy ARP takes on renewed importance. Cloud providers often use proxy ARP (or similar mechanisms) in their virtual networking layer to handle ARP for virtual machines. Instead of allowing broadcast ARP to flood through the virtualized network, the hypervisor intercepts ARP requests and responds with the appropriate virtual MAC address from its own database. This eliminates the scalability problems of traditional broadcast-based ARP in networks with thousands or millions of virtual machines.

ARP Spoofing - A Security Concern

ARP has no authentication mechanism. When a device receives an ARP reply, it trusts it unconditionally - there is no verification that the device sending the reply actually owns the IP address it claims to have. This trust makes ARP vulnerable to spoofing attacks.

In an ARP spoofing (or ARP poisoning) attack, a malicious device sends forged ARP replies to other devices on the network, claiming that a target IP address (such as the default gateway) maps to the attacker's MAC address. Devices that receive the forged reply update their ARP caches with the false mapping and start sending traffic intended for the gateway to the attacker instead.

This enables man-in-the-middle (MITM) attacks: the attacker intercepts traffic between victims and the real gateway, reads or modifies it, and then forwards it to the actual destination. The victims are unaware that their traffic is being intercepted because their network connections continue to work - the attacker is transparently relaying everything.

Defenses against ARP spoofing include:

Dynamic ARP Inspection (DAI): A switch feature that intercepts ARP packets and validates them against a trusted database (typically the DHCP snooping binding table). ARP replies that do not match known IP-to-MAC bindings are dropped.
Static ARP entries: For critical devices like routers and servers, administrators can configure static ARP entries that cannot be overwritten by ARP replies.
Encryption: TLS/HTTPS protects the content of traffic even if an attacker is performing MITM at Layer 2. The attacker can intercept the encrypted packets but cannot read them without the encryption keys.
802.1X port-based authentication: Requires devices to authenticate before gaining network access, preventing unauthorized devices from joining the network in the first place.

Interview: ARP itself is unlikely to be the subject of a System Design interview question, but the pattern it implements - discovering a peer's identity through broadcast and caching the result - appears at every layer of the stack:

DNS is the Layer 7 equivalent of ARP. DNS translates human-readable hostnames to IP addresses, just as ARP translates IP addresses to MAC addresses. Both use a request/reply pattern, both cache results with a TTL, and both have security concerns (DNS spoofing parallels ARP spoofing).

Service discovery (Consul, etcd, Kubernetes DNS) follows the same pattern: "I know the name of the service I want to reach, but I need its actual network address." The resolution mechanism and caching strategy are architecturally identical to ARP.

Understanding ARP helps you reason about these higher-level resolution systems and anticipate their failure modes (cache staleness, race conditions during failover, the cost of broadcast discovery at scale).

What Comes Next

The final topic in this module covers Wi-Fi and wireless networking - the Layer 1/Layer 2 technology that handles the same fundamental tasks as Ethernet (framing, addressing, media access) but over a radically different physical medium with its own set of challenges and trade-offs.

Exercise: Starter: Run arp -a on your device right now. How many entries are in your ARP cache? Can you identify which entry is your default gateway? Does the gateway's MAC address match the MAC address printed on your router (many routers print it on a label on the bottom)?

Intermediate: Clear your ARP cache (sudo arp -d -a on Mac, sudo ip neigh flush all on Linux, arp -d * on Windows as admin) and then immediately run arp -a again. The cache should be empty or nearly empty. Now browse to any website and check the ARP cache again. Which entries appeared? Why did they appear (hint: which device does your machine need to reach to send any traffic outside your local network)?

Advanced: Research how ARP behaves in large cloud environments. In a VPC with thousands of virtual machines, traditional ARP broadcast would not scale. How do cloud providers like AWS handle ARP for VMs in a VPC? Research concepts like "proxy ARP" and "ARP suppression in VXLAN" to understand how the broadcast problem is solved at scale.

Back to Computer Networking