The Link Layer: MAC, ARP and Switches

Article 2 told us IP identifies a device at the network layer. But inside a local network (LAN), actual data delivery uses a different kind of address: MAC. This article (layer 2 — link) explains MAC, the ARP protocol that links IP to MAC, and the switch — the backbone device of every LAN.

MAC address: the hardware address

Each network interface (NIC, wifi) has a MAC address — a 48-bit number, written as 6 pairs of hexadecimal digits:

ifconfig en0 | grep ether

ether fe:6f:15:fe:6d:67

Unlike an IP (assigned by network, can change), a MAC is tied to the hardware of the NIC (usually fixed from the manufacturer). MAC operates at layer 2 and only has meaning within a local network — it isn't routable across the Internet like an IP.

Why you need both MAC and IP

A natural question: we already have IP, so why MAC? Because the two addresses serve two different purposes, matching two layers:

• IP (layer 3) — a logical address, used to route between networks, across the Internet. It answers "which network, which machine, worldwide."
• MAC (layer 2) — a physical address, used to deliver data within one local network. It answers "which NIC on this LAN."

An analogy: sending an international letter. IP is like the full address "Vietnam, Ho Chi Minh City, District 1..." so the letter reaches the right country, the right city. But at the local post office, the carrier uses specific details to drop it in the right mailbox — that's the role of MAC on the final internal leg.

When a packet crosses multiple networks, the source/destination IP stays unchanged the whole journey, but the MAC changes at each hop (each time it crosses a router, the MAC is rewritten for the next leg). This is a subtle but important point — we'll meet it again in Article 4 (routing).

ARP: linking IP to MAC

The problem: your machine wants to send a packet to 192.168.71.1 (an IP), but to deliver it on the LAN it needs to know that machine's MAC. How does it find out? Through ARP (Address Resolution Protocol), defined in RFC 826.

ARP works simply by "asking the whole network":

   Machine A needs the MAC of 192.168.71.1 but doesn't know it yet:

   A ──── broadcast to the WHOLE LAN ────►  "Who has 192.168.71.1? Give me your MAC."
                                       (ARP request)
   192.168.71.1 ──── replies just to A ──►  "Here I am. My MAC is 40:ae:30:30:a6:48."
                                          (ARP reply)
   A stores the pair 192.168.71.1 → 40:ae:30:30:a6:48 in its ARP TABLE (cache)

Next time it sends to that IP, A looks up the ARP table and skips asking again. View the ARP table on your machine:

arp -a

? (192.168.71.1)   at 40:ae:30:30:a6:48 on en0   ← gateway (router)
? (192.168.71.151) at a:69:a2:81:6d:8a  on en0
? (192.168.71.158) at 4a:e4:13:3c:fa:9  on en0

Each line is an IP↔MAC pair your machine has learned on the LAN. Notice 192.168.71.1 — that's the network's router/gateway (Article 4); your machine has to know its MAC to send anything out to the Internet through it.

On security: because ARP trusts every reply, an attacker on the same LAN can "ARP spoof" — forge replies to wedge in the middle (man-in-the-middle). This is why, on an untrusted network, encryption at an upper layer (TLS — Article 9) is necessary: even if someone wedges in at layer 2, they can't read the encrypted content.

Switch: the LAN's switching device

Devices on a LAN connect to each other through a switch — a layer 2 device. The switch's job: receive an Ethernet frame on one port and push it out the right port toward the destination machine.

A switch does this by learning which MAC is on which port:

   The switch builds its own MAC ↔ port table:
   ┌────────────────────────────────┐
   │ port 1  ── MAC aa:.. (machine A)│
   │ port 2  ── MAC bb:.. (machine B)│
   │ port 3  ── MAC cc:.. (machine C)│
   └────────────────────────────────┘

   Frame sent to bb:.. → switch pushes it out PORT 2 only
   (doesn't bother machines A and C)

Compared to a hub (an older device that floods every frame out every port — slow and not private), a switch only sends to the exact port needed, so it's efficient and ubiquitous. A switch looks at MAC (layer 2); it doesn't care about IP — that's the router's job (layer 3, Article 4).

Putting it together: sending a packet on the LAN

When machine A sends data to machine B on the same LAN:

1. A has B's IP. Looks up the ARP table for B's MAC (asks ARP if it doesn't have it).
2. A encapsulates: Ethernet frame [src MAC=A | dst MAC=B | ... | IP/data]
3. A sends the frame to the switch.
4. The switch sees dst MAC=B, pushes the frame out B's port.
5. B receives it, peels the frame, processes it.

What if B is not on the same LAN (on a different network / on the Internet)? A can't send directly — it sends to the router/gateway (via the router's MAC), and the router takes care of moving the packet onward. That's exactly routing — Article 4.

Wrap-up

On a LAN, data is delivered by MAC address (layer 2, tied to hardware, 48-bit), distinct from IP (layer 3, logical, globally routable). You need both: IP to reach the right network, MAC to deliver within the local network — and MAC changes at each hop while IP stays the same. ARP resolves IP→MAC by broadcasting a question to the whole LAN and then caching the result (arp -a). A switch forwards frames to the right port based on the MACs it has learned.

But when the destination is on another network, the packet has to leave the LAN. Article 4 explains how: routing — routers, gateways, and routing tables.