Chapter 3 · The Link Layer, Ethernet, ARP & RoutingThe student-friendly guide + hands-on Kali labs

Chapter 3 · The student-friendly guide

The Link Layer:
frames, Ethernet, ARP & routing

Layer 2 carries a frame one hop to the next device — catching errors, sharing the wire, and (with ARP) finding the right MAC. Then we follow a packet across subnets and meet the golden rule of addressing.

Link-Layer ServicesError DetectionCSMAEthernet & MACARPRouting

Use ← → arrows, the dots, or the ☰ menu. Switch to the Lab Guide up top.

The big picture

Your journey through Chapter 3

💡
Think of it like… the last-mile courier. The network layer plans the whole cross-country route; the link layer just carries each parcel one hop — to the next-door node — and shares the road politely.
🔗

The Link Layer

Its one job (node → next node), frames & the NIC.

🐞

Catching Errors

EDC bits, parity & checksums.

👥

Sharing the Wire

Collisions & MAC protocols (CSMA).

🔌

Ethernet, ARP & Routing

Frames, IP→MAC, and hop-by-hop delivery.

Part 1 · The Link Layer

One job: get a frame to the next node

Move a datagram from one node to the physically ADJACENT node, over a single link.

Nodes = hosts & routers. Links = the channels between them (wired or wireless). The layer-2 packet is a frame — your datagram wrapped with a header & trailer.

💻 Node A
HeaderDatagramTrailer
🖥️ Node B

a FRAME hops one link, from A to its adjacent neighbour B

💡
Think of it like… a relay race. The network layer plans the whole race; the link layer is just ONE runner carrying the baton to the very next runner — one hop, then done.

Part 1 · The Link Layer

What the link layer does for you

📦 Framing & MAC access

Wrap the datagram in a frame; MAC addresses name src & dst (not IP!).

✅ Reliable delivery

Optional node-to-node guarantee (mostly on error-prone wireless).

🚦 Flow control

Pace the sender so it doesn’t swamp the receiver.

🔎 Error detection

Spot bits flipped by noise; drop or resend.

🔧 Error correction

Fix the flipped bit on the spot — no resend.

↔️ Half / full duplex

Take turns, or both directions at once.

💾
Where it lives: on the NIC (network interface card) in every host — a mix of hardware, software & firmware. The sending side wraps & adds checks; the receiving side checks & unwraps.

Self-Test #1

The Link Layer

Tap a green answer to reveal it.

Q What is the ONE job of the link layer?
A Move a datagram from one node to the physically adjacent node — a single hop over one link.
Q What’s a layer-2 packet called, and what does it carry?
A A frame — it wraps the network-layer datagram with a header & trailer.
Q Where is the link layer implemented?
A On the NIC in every host — hardware + software + firmware.

Part 1 · Catching Errors

The big idea: add check bits (EDC)

Send the data D plus some Error-Detection bits (EDC). The receiver re-checks them to spot flipped bits.

D | EDC
noisy link ⚡
check?
⚠️
Not 100% reliable: a protocol can miss some errors (rarely). A bigger EDC field = better detection & correction.
💡
Think of it like… the last digit of a credit-card or ISBN number: a built-in check digit that flags most typos the moment someone re-adds the maths.

Part 1 · Catching Errors

Parity checking

1-D parity

Add ONE bit so the number of 1s is even (or odd). The receiver re-counts — a mismatch = error. Detects a single-bit error (can’t fix it).

01110001101010111

2-D parity

Parity on every row AND column pinpoints the flipped bit → detect AND correct it!

10111
01101
11011
1011
💡
Think of it like… Battleship: the flagged row and the flagged column cross at exactly one square — that’s your flipped bit, so you can flip it back.

Part 1 · Catching Errors

The Internet checksum

Sender

● Chop the segment into 16-bit integers
● Add them up (one’s-complement sum)
● Put the result in the checksum field

Receiver

● Re-add all the 16-bit words
● Compare with the checksum field
● Equal → OK · Not equal → error!

Used by UDP & TCP. Cheap & fast — but it can still miss some error patterns.

💡
Think of it like… totting up a shopping receipt and writing the total at the bottom. The receiver re-adds the items — if the total doesn’t match, something got changed along the way.

Self-Test #2

Catching Errors

Tap a green answer to reveal it.

Q Is error detection 100% reliable?
A No — a few errors slip through (rarely); a bigger EDC field improves the odds.
Q What can 2-D parity do that 1-D parity can’t?
A Detect AND correct a single-bit error — the bad row & column pinpoint it.
Q How does the Internet checksum work at the sender?
A Treat the segment as 16-bit integers, take the one’s-complement sum, put it in the checksum field.

Part 1 · Sharing the Wire

Two kinds of link — and the problem

Point-to-point

Just two nodes on the link (switch ↔ host). No one to clash with — easy.

Broadcast (shared)

Many nodes share ONE medium (old Ethernet, Wi-Fi, 4G/5G). Two talking at once = collision ⚡.

🧩
The challenge: on a shared channel we need a distributed rule for who transmits when — and the only way to coordinate is over the channel itself (no separate control line).
💡
Think of it like… a conference call with no moderator: if two people speak at once, nobody can be heard. A MAC protocol is the etiquette for who talks, when.

Part 1 · Sharing the Wire

Multiple-access protocols: 3 families

🔲

Channel partitioning

Cut the channel into fixed pieces (time, frequency) — each node gets its own. TDMA · FDMA

⚡

Random access

Don’t divide it. Transmit freely, allow collisions, recover. ALOHA · CSMA

🔄

Taking turns

Nodes take turns; busy nodes get longer turns. Polling · Token passing

🧠
Memory hook: three ways to share a room — give everyone a fixed slot (partitioning), let people jump in & retry if they clash (random), or pass a talking-stick (taking turns).

Part 1 · Sharing the Wire

CSMA — listen before you talk

Carrier Sense Multiple Access: sense the channel first. Idle? transmit. Busy? wait and retry.

CSMA/CD — Collision Detection

Listen WHILE sending; on a clash, stop, send a jam, back off a random time. Collisions are detectable on a wire. Used in Ethernet (802.3).

CSMA/CA — Collision Avoidance

Can’t hear clashes over the air, so signal intent first and avoid them. Used in Wi-Fi (802.11).

🧠
Memory hook: “Detection for wires, Avoidance for air.” CD = wired Ethernet (802.3); CA = wireless Wi-Fi (802.11).

Part 1 · Sharing the Wire

Taking turns: polling & token passing

Polling

A central controller invites each node to transmit in turn (used with “dumb” devices — e.g. Bluetooth).

Token passing

A control “token” is passed node-to-node around a ring. Only the holder may transmit (Token Ring, FDDI).

💡
Think of it like… a classroom: polling = the teacher calls on each student in turn; token passing = only whoever holds the “talking stick” may speak, then passes it on.

Part 2 · Ethernet, MAC & ARP

Ethernet topology: bus → switched

Bus (old)

All nodes share ONE cable = one collision domain. Any two can collide ⚡.

Switched (today)

A layer-2 switch in the centre. Each spoke is its own link — no collisions between nodes, full-duplex.

💡
Think of it like… bus = one loud room sharing a single megaphone (talk together → clash). Switched = private phone booths routed by an operator — each call stays separate.

Part 2 · Ethernet, MAC & ARP

Anatomy of an Ethernet frame

Preamble + SFD
8 B
Dest MAC
6 B
Src MAC
6 B
Type
2 B
Data + Pad
46–1500 B
FCS
4 B
🔎
The Type field demuxes to IP (0x0800) or ARP (0x0806). The FCS is a CRC error-check the receiver verifies (a failed frame is dropped). Preamble & FCS are usually stripped by the card before you see it.
💡
Think of it like… a shipping crate: a heads-up it’s coming (preamble), to/from labels (MACs), a contents tag (type), the goods (data), and a tamper seal checked on arrival (FCS).

Part 2 · Ethernet, MAC & ARP

Unreliable, connectionless — and two sublayers

No handshake, no receipt

Connectionless (no setup) and unreliable (no ACK/NAK). A dropped frame is just gone — only a reliable upper layer like TCP recovers it. Ethernet’s MAC = unslotted CSMA/CD + binary backoff.

Layer 2 = two sublayers

LLC (Logical Link Control): framing, addressing, error control — talks UP to software.
MAC (Media Access Control): who transmits & when — talks DOWN to the wire.

💡
Think of it like… posting a postcard with no tracking: you drop it in the box and hope. If it matters, it’s YOUR job (TCP) to notice it never arrived and resend.

Part 2 · Ethernet, MAC & ARP

MAC vs IP — two addresses per interface

🔧

MAC = identity

48-bit, burned into the card. Portable — move to any LAN, it goes with you. Like your Social Security Number.

📍

IP = location

32-bit, logical. Not portable — it depends on the subnet you’re plugged into. Like your postal address.

💡
Think of it like… your name (MAC) identifies you and never changes; your mailing address (IP) changes when you move. You need both to get a letter delivered.

Part 2 · Ethernet, MAC & ARP

ARP: turning an IP into a MAC

The problem

To build a frame I need the destination’s MAC — but I only know its IP. How do I get the MAC?

The answer: ARP

Address Resolution Protocol maps an IP address → its MAC address, for nodes on the same subnet.

Every node keeps an ARP table: < IP address | MAC address | TTL > TTL ≈ 20 min, then forgotten
💡
Think of it like… your phone’s contacts: you know the name (IP) but need the number (MAC). ARP is directory enquiries for the LAN — and entries expire, so they stay fresh.

Part 2 · Ethernet, MAC & ARP

ARP in action — 3 steps

📢

1 · Broadcast

A asks everyone: ARP query to ff:ff:ff:ff:ff:ff — “who has IP 137.196.7.14?”

↩️

2 · Reply

Only B answers, with a unicast ARP response carrying its MAC.

💾

3 · Cache

A stores B’s < IP, MAC, TTL > — no need to ask again until it expires.

🧠
Memory hook: “Shout to everyone, the owner whispers back, write it down.” Query = broadcast; reply = unicast; then cache it.

Self-Test #3

Ethernet, MAC & ARP

Tap a green answer to reveal it.

Q Is Ethernet reliable and connection-oriented?
A No — unreliable & connectionless. TCP recovers losses; MAC = CSMA/CD + backoff.
Q What does ARP do?
A Finds an interface’s MAC address from its IP, on the same subnet.
Q In an ARP query, what’s the destination MAC, and why?
A ff:ff:ff:ff:ff:ff (broadcast) — so every node on the LAN hears “who has this IP?”

Part 2 · Across Subnets

The big journey: A → R → B

A and B are on DIFFERENT subnets, joined by router R. The frame can’t go straight to B — it must hop via R. At each hop the router de-encapsulates the frame, then re-encapsulates with a fresh one for the next link.

A
192…111
R
router
B
222…222
💡
Think of it like… A already knows B’s IP and R’s MAC. The question this answers: whose MAC goes in the frame at each step? (Spoiler: R’s first, never B’s — until the very last hop.)

Part 2 · Across Subnets

The golden rule of addressing

IP addresses — END to END

Set by the sender, unchanged the whole way. They name the true source & final destination.

A → B, same IPs throughout

MAC addresses — HOP to HOP

Rewritten by each device for just the next link. They only mean anything on the local segment.

A → R → B, new MACs each hop
🧠
Memory hook: “IP end-to-end, MAC hop-to-hop.” The IP is the address on the parcel; the MAC is the “next stop” sticker a depot peels off and replaces each leg.

Self-Test #4

Routing Across Subnets

Tap a green answer to reveal it.

Q Sending A → B via router R, whose MAC is in A’s first frame?
A R’s MAC (the next hop) — NOT B’s. The IP destination is still B.
Q As a frame crosses each hop, what changes and what stays?
A MAC src/dst are rewritten every hop; IP src/dst stay the same end-to-end.
Q Which IEEE standard is Ethernet, and which is Wi-Fi?
A Ethernet = 802.3 (CSMA/CD); Wi-Fi = 802.11 (CSMA/CA).

One-page cheat sheet

Chapter 3 in a single glance

Link layer's job

  • Frame → adjacent node (one hop)
  • PDU = frame (header + trailer)
  • Lives on the NIC

Error detection

  • EDC check bits (not 100%)
  • Parity: 1-D detect, 2-D correct
  • Checksum (UDP/TCP) · FCS (CRC)

Sharing / MAC

  • Partitioning · random · turns
  • CSMA = listen before talk
  • CD = wired · CA = wireless

Ethernet (802.3)

  • Switched · full-duplex
  • Unreliable + connectionless
  • LLC + MAC sublayers

Ethernet frame

  • Pre·SFD·Dst·Src·Type·Data·FCS
  • Type = IP 0x0800 / ARP 0x0806
  • FCS = CRC error check

MAC vs IP

  • MAC = name (fixed, portable)
  • IP = address (per subnet)
  • Each interface has both

ARP

  • IP → MAC on same subnet
  • Query = broadcast (ff:ff…)
  • Reply = unicast · cache w/ TTL

Golden rule

  • IP: end-to-end (unchanged)
  • MAC: hop-to-hop (rewritten)
  • Frame to R first, not B

Router per hop

  • Accept frame → de-encapsulate
  • → re-encapsulate → forward
  • Packet inside stays the same

One hop at a time, error-free.

You can now explain how the link layer frames a datagram, catches errors, shares one channel, finds a MAC with ARP, and hands a packet hop-by-hop across subnets. Revise with the cheat sheet, test yourself with the quizzes.

Next up → Chapter 4 (the Network Layer / IP)

Ready to make it real? Switch to the 🧪 Lab Guide — watch frames, ARP and the “MAC hop-to-hop” rule on Kali Linux.

1 / 25

Chapter 3 · Hands-on labs

Frames, Errors, ARP & Routing — live on Kali Linux

Six small, beginner-friendly labs using only built-in Linux commands. Type the command, read the output. Each maps to a Chapter 3 idea — finishing with the one that ties the whole chapter together: IP end-to-end, MAC hop-to-hop.

SET-UP  ·  Open the Kali Terminal. A couple of labs use two terminals (A & B). Capturing packets needs sudo. Everything here is built into Kali (ip, tcpdump, ethtool, ping). The ❯ is just the prompt — Copy grabs only the command. Replace eth0 with your interface (from Lab 1) if it differs.
USE RESPONSIBLY  ·  Only capture traffic on networks you own or are allowed to test. These labs only ever look at your own machine and its traffic.
1 · Frames2 · Errors3 · Sharing 4 · ARP5 · MAC vs IP6 · Routing rule✓ Answers
1

The Link Layer: Frames & Your Neighbours

Maps to Ch.3:The link layer carries a frame one hop, to a directly-connected neighbour. You’ll learn:See the Layer-2 frame header (the two MAC addresses) and list who is one hop away. Tools:tcpdump, ip
1

Show the frame header on live traffic (-e prints the Layer-2 part):

sudo tcpdump -i any -e -c 5 -nn
Representative — dest MAC > src MAC, then the type
6c:f0:49:68:95:68 > 52:54:00:aa:bb:cc, ethertype IPv4 (0x0800), length 74

Every frame starts with dst MAC > src MAC, then the ethertype. Both MACs are on your local link — the link layer just moves the frame to the next device.

2

List your one-hop neighbours — devices you can reach directly (their IP and MAC):

ip neigh
Representative
192.168.1.1  dev eth0 lladdr 9c:1c:12:aa:bb:cc REACHABLE
192.168.1.42 dev eth0 lladdr 3c:5a:b4:11:22:33 STALE
Why it matters  ·  A frame only ever travels one hop, between two MAC addresses on the same link. ip neigh lists exactly those reachable neighbours — the nodes the link layer can hand a frame to directly.
Your turn  ·  In the tcpdump line, are the two MAC addresses both on your own network, or is one far away on the Internet? (answer below)
2

Catching Errors: The FCS & Error Counters

Maps to Ch.3:Error detection — the FCS (a CRC) lets the card drop corrupted frames; checksums protect IP/TCP. You’ll learn:Read your card’s error counters and watch tcpdump verify a packet’s checksum. Tools:ip, tcpdump
1

Your card’s error counters — how many frames failed their checks:

ip -s link show eth0
Verified format — note the “errors” and “dropped” columns
2: eth0: <BROADCAST,MULTICAST,UP> ...
    RX:  bytes packets errors dropped  missed   mcast
      12345678    9876      0       0       0      12
    TX:  bytes packets errors dropped carrier collsns
       2345678    4321      0       0       0       0

The errors column counts frames that failed the FCS / CRC check — the link layer’s error detection. On a healthy link it’s 0; a bad cable makes it climb.

2

Watch a checksum being verified. Capture with -vv and look for “cksum … (correct)”:

sudo tcpdump -i any -vv -c 3 -nn icmp

# in another terminal, generate one ping:

ping -c 1 8.8.8.8
Why it matters  ·  Error detection isn’t abstract — the FCS lets your NIC silently bin damaged frames (the errors counter), and IP/TCP carry their own checksum that tcpdump can re-check as “(correct).”
Your turn  ·  Run Lab 2’s first command twice with a few seconds between. Did the packet counts go up? What does that tell you about your link? (answer below)
3

Sharing the Medium: Duplex & CSMA

Maps to Ch.3:Multiple access — CSMA/CD (wired) vs CSMA/CA (wireless); switched full-duplex avoids collisions. You’ll learn:Check whether your link is full-duplex (so there are no collisions) and how fast it is. Tools:ethtool (wired), iwconfig (Wi-Fi)
1

Check speed & duplex on a wired link:

sudo ethtool eth0 | grep -E 'Speed|Duplex'
Representative
	Speed: 1000Mb/s
	Duplex: Full

Full duplex means you can send and receive at the same time — modern switched Ethernet, so there are no collisions and CSMA/CD isn’t needed. (Old shared “bus” Ethernet was half-duplex and used CSMA/CD.)

2

On Wi-Fi instead? Wireless can’t hear collisions, so it uses CSMA/CA (avoidance). Check your wireless link:

iwconfig
Why it matters  ·  “Detection for wires, Avoidance for air.” Wired Ethernet (802.3) used CSMA/CD; today’s switched full-duplex links sidestep collisions entirely. Wi-Fi (802.11) uses CSMA/CA because you can’t detect a collision over the air.
Your turn  ·  If your link shows Full duplex, do collisions happen on it? Which CSMA variant would a Wi-Fi card use instead? (answer below)
4

ARP: Turning an IP into a MAC (Watch It Live)

Maps to Ch.3:ARP — broadcast “who has this IP?”, get a unicast reply with the MAC, and cache it. You’ll learn:See the ARP table, clear it, and watch the request → reply → cache happen in real time. Tools:ip, ping, tcpdump (two terminals)
1

Look at the ARP table (IP ↔ MAC pairs your machine has learned):

ip neigh
2

Start watching ARP in Terminal A (-e shows the MACs):

sudo tcpdump -i any -e -nn arp
3

Clear the cache & ping your gateway in Terminal B — this forces a fresh ARP lookup:

sudo ip neigh flush all
ping -c 1 192.168.1.1
Representative — Terminal A shows the request → reply
... 6c:f0:49:68:95:68 > ff:ff:ff:ff:ff:ff, Request who-has 192.168.1.1 tell 192.168.1.23
... 9c:1c:12:aa:bb:cc > 6c:f0:49:68:95:68, Reply 192.168.1.1 is-at 9c:1c:12:aa:bb:cc
4

Confirm it was cached — the gateway’s MAC is now stored:

ip neigh
Why it matters  ·  You just watched all three ARP steps: a broadcast “who-has” (to ff:ff:ff:ff:ff:ff), a unicast “is-at” reply with the MAC, and the result cached in your ARP table.
Your turn  ·  In the request, why is the destination MAC all F’s, but the reply is sent to one specific MAC? (answer below)
5

MAC vs IP, and the Gateway

Maps to Ch.3:MAC = a fixed name; IP = a location that changes per network; the gateway is the door out. You’ll learn:See both addresses on your own machine, and find the gateway you’ll need for the next lab. Tools:ip
1

Your MAC — the fixed “name” of your card (link/ether):

ip link show eth0
2

Your IP — your “address”, which depends on this network:

ip -br addr show eth0
3

Your gateway — the router that is your door to other networks:

ip route | grep default
Representative
default via 192.168.1.1 dev eth0
Why it matters  ·  Your interface has BOTH a MAC (fixed — move anywhere, it stays) and an IP (changes when you join a new network). For anything not on your LAN, your machine sends the frame to the gateway first — which the next lab proves on real packets.
Your turn  ·  Which of your two addresses would change if you joined a different Wi-Fi network — the MAC or the IP? (answer below)
6

Routing: IP End-to-End, MAC Hop-to-Hop

Maps to Ch.3:The golden rule — to reach a far host, the frame’s MAC points to the next hop (your gateway), but the IP points to the final destination. You’ll learn:Prove it on a real packet: the destination IP is far away, but the destination MAC is your gateway. Tools:ip, tcpdump, ping, traceroute (two terminals)
1

Note your gateway’s MAC (from Lab 4/5) — keep it handy:

ip route | grep default
ip neigh | grep "$(ip route | awk '/default/{print $3}')"
2

Capture one packet to a far host in Terminal A:

sudo tcpdump -i any -e -c 1 -nn 'icmp and dst 8.8.8.8'
3

Ping that far host in Terminal B:

ping -c 1 8.8.8.8
Verified format — read the two destinations carefully
6c:f0:49:68:95:68 > 9c:1c:12:aa:bb:cc, ethertype IPv4 (0x0800)
    192.168.1.23 > 8.8.8.8: ICMP echo request

Look closely: the destination MAC (9c:1c:12:…) is your gateway — the next hop — but the destination IP is 8.8.8.8, the final target. The MAC is local; the IP is end-to-end.

4

See the IP stay constant across many hops:

traceroute -n 8.8.8.8
Why it matters  ·  This is the whole chapter in one packet: the frame’s MAC = next hop (your gateway), the packet’s IP = final destination. Each router rewrites the MAC for the next link, but the IP never changes. IP end-to-end, MAC hop-to-hop.
Your turn  ·  If you ping a device on your OWN LAN instead of 8.8.8.8, would the destination MAC be the gateway or the device itself? (answer below)
✓

Answer Key & Where Next

Lab 1. Both MACs are on your own network — a frame only travels one hop, between two local devices. (Even traffic bound for the Internet shows your gateway’s local MAC, not a far one — that’s Lab 6.)

Lab 2. Yes, the packet counts rise as your machine sends/receives traffic. If errors stays 0, your link is clean; a climbing errors count points to a bad cable or interference.

Lab 3. No collisions on a full-duplex switched link (send & receive happen on separate paths). A Wi-Fi card would use CSMA/CA (collision avoidance).

Lab 4. The request is a broadcast (all F’s) because A doesn’t yet know who owns the IP — everyone must hear it. The reply is unicast because B now knows exactly who asked (A’s MAC), so it answers just A.

Lab 5. The IP changes on a new network; the MAC stays the same (it’s burned into the card).

Lab 6. For a device on your own LAN, the destination MAC would be that device itself (it’s one hop away). The gateway’s MAC only appears when the destination is on a different network.

This lab’s toolReturns in…
ip neigh / ARP (Lab 1, 4)Chapter 4 & 5 — addressing & how packets find their way
tcpdump dissection (Lab 1, 6)Chapter 4 & 5 — the IP header, TTL, ICMP
ip route / gateway (Lab 5, 6)Chapter 4–6 — routing, IP addressing & subnetting
error counters (Lab 2)Any troubleshooting — your first check for a flaky link
Nice work  ·  With nothing but built-in Linux commands you’ve seen frames on the wire, your card’s error checks, full-duplex links, ARP resolving live, and the golden rule proven on a real packet.
Chapter 3 — The Link Layer, Ethernet, ARP & Routing · Slides + Hands-On Kali Labs