Frontend Labs
⋯

Part 2 — Your local network (the link layer)

This is the bottom layer: getting a frame from one device to another on the same cable or the same Wi-Fi. It has no idea the internet exists.

Chapter 5 — MAC addresses and Ethernet frames

In one sentence

Every network card has a permanent-ish hardware address called a MAC address, and the link layer wraps your data in a frame addressed from one MAC to another.

The problem

Ten devices are plugged into the same switch, or associated with the same Wi-Fi access point. When one sends data, how does the right device pick it up and the others ignore it? They need names — and IP addresses aren't available yet at this level (that's a layer up).

The idea, in plain language

Give every network card a factory-assigned serial number. Put "from" and "to" serial numbers on every frame. Each card listens, checks the "to" field, and only processes frames addressed to it.

How it actually works: the MAC address

A MAC address (Media Access Control) is 48 bits = 6 bytes, written as six pairs of hex digits:

   a4:83:e7:2b:19:0c
   \______/  \______/
      |          |
      |          +-- serial number, chosen by that manufacturer
      +------------- OUI: identifies the MANUFACTURER
                     (a4:83:e7 = Apple, 00:1a:11 = Google, 52:54:00 = a VM)

Three things to know:

  1. ff:ff:ff:ff:ff:ff is the broadcast address — "everyone on this network, listen up". You'll see it in Chapter 6.
  2. MAC addresses are flat. There's no structure like "all European devices start with X". You can't route by them across the internet — there'd be a billion-row table. This is exactly why IP addresses exist (Chapter 9).
  3. They can be changed. Phones and laptops now use randomised MAC addresses on Wi-Fi to stop shops tracking you between visits. If your MAC's second hex digit is 2, 6, a, or e, it's a locally-assigned (often random) one.

How it actually works: the Ethernet frame

+-----------+-----------+-----------+---------------------+---------+
| Dest MAC  | Src MAC   | EtherType | Payload             | FCS     |
| 6 bytes   | 6 bytes   | 2 bytes   | 46 - 1500 bytes     | 4 bytes |
+-----------+-----------+-----------+---------------------+---------+
   who it's    who sent   what's       your actual data     error
   for         it         inside       (the IP packet)      check
  • EtherType tells the receiver what's inside so it can hand it to the right code: 0x0800 = IPv4, 0x86DD = IPv6, 0x0806 = ARP.
  • Payload max 1500 bytes — this number is called the MTU and it matters a lot (Chapter 15).
  • Payload min 46 bytes — short frames get padded. A tiny 1-byte message still costs a 64-byte frame.
  • FCS (Frame Check Sequence) is a checksum. If it doesn't match, the card silently throws the frame away. Ethernet does not retransmit — that's TCP's job, three layers up.

Worked example: what your machine actually has

# Linux
ip -br link

# macOS
ifconfig | grep -E '^\w|ether'

You'll see something like:

lo               UNKNOWN        00:00:00:00:00:00      <- loopback (fake, internal)
eth0             UP             a4:83:e7:2b:19:0c      <- wired
wlan0            UP             9a:1f:04:c8:22:7e      <- Wi-Fi (note the 'a' -> randomised)

Look up the first three bytes of your MAC at macvendors.com — it should name your laptop's manufacturer (unless it's randomised).

Practice (20 min)

A. See a real frame with its layers labelled:

sudo tcpdump -i any -c 3 -e -n

The -e flag shows the Ethernet header. You'll see aa:bb:cc:dd:ee:ff > 11:22:33:44:55:66, ethertype IPv4 (0x0800) at the front of each line. That's a real frame header.

B. Watch the MAC change but the IP stay the same. This is the key insight of Chapter 2, made visible:

# capture traffic to a website
sudo tcpdump -i any -c 5 -e -n 'host example.com'

Every packet you send to example.com has:

  • Destination MAC = your router's MAC (the next hop), always
  • Destination IP = 93.184.216.34 (the final destination), always

The MAC says "next door"; the IP says "eventually". Write that in notes.md.

C. Check for hardware errors (useful troubleshooting skill):

# Linux
ip -s link show eth0        # look for RX/TX 'errors' and 'dropped'
ethtool -S eth0 2>/dev/null | grep -Ei 'err|drop|crc'

# macOS
netstat -i                   # Ierrs / Oerrs columns

Non-zero and climbing CRC errors means a physical problem: a bad cable, a loose connector, interference. This is often the real cause of "the network is slow" and almost nobody checks it.

Common confusions

  • "MAC address vs IP address?" MAC = which device on this cable, assigned by the manufacturer, never routed. IP = which device in the world, assigned by the network you're on, routed globally. You need both, always.
  • "Is a MAC address permanent?" Traditionally yes (burned into the card). In practice modern devices randomise them for privacy, and you can change them in software.
  • "What if two devices have the same MAC?" On the same network segment, chaos — frames go to the wrong place intermittently. It happens with cloned VMs.

Check yourself

  1. How many bytes is a MAC address, and what do the first three bytes tell you?
  2. What does the EtherType field do?
  3. What happens to a frame whose FCS doesn't match?
  4. When you send a packet to a website, whose MAC address is in the destination field?

Further reading

  • Video (~10 min): "Ethernet Frames Explained" — Practical Networking.
  • Article: "What is a MAC address?" — Cloudflare Learning Center.
  • Book: Computer Networking: A Top-Down Approach (Kurose & Ross), Chapter 6 (the Link Layer).
  • Tool: macvendors.com — paste any MAC address, see the manufacturer.

Generated from real-life-guide-v1.md · 8 Oct 2026 16:36