Lessons (6, study in order)

Lesson 1 · How does a switch know which port to send out

Beginner · about 8 min

Goal: Understand everything an L2 switch does — just three things: learn, look up, forward.

First, clear up a misconception: a switch isn't smart

A lot of people assume a switch runs some complex algorithm. In reality it does exactly three things:

① Learn — on receiving a frame, record the "source MAC" and "which port it came in on" into a table
② Look up — when it needs to send, look up the outgoing port by "destination MAC" in that table
③ Forward — send it out the port it found

★ It never looks at IP, port numbers, or content — only the two MAC addresses in the Ethernet frame header.
That's exactly why a switch is "transparent" to the two communicating ends — when PC1 sends a frame to PC3, it has no idea how many switches it passed through.

⚠️ The easiest thing to get backwards

It learns the "source" MAC, and looks up the "destination" MAC.

Why does this work? Because an L2 link is bidirectional.
The fact "PC1's frame came in on GE0/0/1" is exactly equivalent to
"to send to PC1 in the future, go out GE0/0/1."

★ One line to remember: wherever it came from is where you send it back.

Hands-on: watch an empty table fill up

Go to the Topology & MAC Table page, and first click "Clear MAC table" — you'll see all four tables go empty.

Then go to the Frame Forwarding Simulation page and send a frame from PC1 → PC3, then come back and check the tables.
★ Notice what each switch learned: SW1 learned both PC1 and PC3, and SW2 learned the same two — but on different ports.

Key takeaways

• A switch only does three things: learn (source MAC → incoming port), look up (destination MAC), forward
• ⚠️ Learn source, look up destination — don't mix up these two directions
• A switch never looks at IP, and is transparent to both communicating ends

Lesson 2 · What if the table can't find it: flooding

Beginner · about 10 min

Goal: Understand flooding — L2's most counterintuitive, and most important, behavior.

Right after power-on, the table is empty

A switch just powered on has a completely empty MAC table — it has no idea where any device is.

Now a frame arrives whose destination MAC can't be found. It has two choices:
· Drop it — but then the network could never work, because the table could never learn anything
· Take a gamble: send a copy out every port except the one it came in on

★ It picks the latter. This action is called flooding.

★★ The most counterintuitive part of flooding

A unicast frame addressed to one specific device ends up delivered to everyone.

There are three costs:
· Every unrelated host's NIC has to accept it, check the destination MAC, realize it isn't theirs, and drop it → wasted CPU
· Every link has a slice of its bandwidth consumed
· The content might get captured by someone who shouldn't see it → a security concern

★ But note: this isn't a fault — it's a necessary part of L2's design. Without flooding, the table could never get built in the first place.

★ Three situations that trigger flooding — don't mix them up

· Broadcast frame — destination MAC is ffff.ffff.ffff, which by definition must go to everyone (normal behavior)
· Unknown unicast — destination MAC is a specific device, but not found in the table (this is the one worth watching)
· Multicast — sent to a group of devices; without multicast optimization configured, it also degrades into flooding

★ If you see a lot of unknown unicast flooding in a real packet capture, that's a sign something's off — Lesson 5 covers its real cause.

Hands-on: watch the fan-out with your own eyes

Go to the Frame Forwarding Simulation page, first clear the MAC table, then send PC1 → PC3.

★ Watch the first step at SW1: several lines light up at the same time on the canvas — that's flooding's fan-out.
Only one direction is actually useful, and the UI marks it.

Key takeaways

• Not found → flood (send one copy out every port except the incoming one)
• Flooding isn't a fault — without it the table could never get built
• ★ But unknown unicast flooding is worth watching: a unicast frame delivered to everyone
• Flooding's cost: unrelated hosts waste CPU + links waste bandwidth + content might get sniffed

Lesson 3 · A host only has the IP: ARP fills that gap

Beginner · about 10 min

Goal: Understand ARP's one and only reason to exist, and why it must use broadcast.

Where's the gap

You ping an IP, or your browser hits a URL — the application layer hands you an IP address.
But the NIC needs to send a frame, and the frame header needs a MAC address.

★ There's a gap here: you know the IP, but not the MAC.
ARP (Address Resolution Protocol) exists for exactly one reason: to close that gap.

★ Why it has to be a broadcast

ARP wants to ask "who is 10.0.0.3". But there's a chicken-and-egg problem here:

I want to ask, but I don't know who to ask — because knowing "who to ask" itself requires a MAC address.

There's only one way to break this loop: broadcast, and ask everyone.
The destination MAC is set to ffff.ffff.ffff, so every device in the broadcast domain receives it and checks:
"Is this IP me?" — whichever one it is replies via unicast.

★ Why can the reply be unicast? Because the request frame carried the source host's MAC, so the responder already knows exactly who to reply to.

★★ The most elegant part: the table gets built by ARP

Put Lessons 1 and 2 together and watch one full exchange:

① ARP request (broadcast) floods the whole network → every switch along the way learns the source host's MAC
② The target replies via unicast → since the table was just built, this hits a table match the whole way, with no more flooding
③ The actual data frame goes out → clean unicast the whole way

★★★ It's the first frame's (the ARP request's) flood that builds the table.
This is exactly why real packet captures rarely show flooding — not because it never happened, but because it happened before you started watching.

★ When crossing subnets, ARP asks for the gateway

A host makes one check before sending a frame: "is the destination IP on my subnet?"

· Same subnet → ARP for the peer's MAC; the frame header's destination MAC is the peer's
· Cross-subnet → ARP for the gateway's MAC; the frame header's destination MAC is the gateway's

⚠️ The second one is a common mistake point: when crossing subnets, the destination host's MAC never appears at all in the frame header.
L2 is only responsible for getting the frame to the gateway — the rest is layer 3's job.

Hands-on: walk through ARP

Go to the ARP Protocol page and have PC1 resolve PC3's IP.
Watch the two frames: the request (broadcast, flooded) and the reply (unicast, a hit the whole way).

★ Then be sure to look at the two side-by-side tables in the lower half of the page — the next lesson is exactly about them.

Key takeaways

• The gap ARP fills: you know the IP, but the frame header needs a MAC
• ★ The request must be broadcast (you don't know who to ask yet); the reply can be unicast (the request already carries the source MAC)
• ★★ The table gets built by the flood of the first frame
• ⚠️ When crossing subnets, ARP asks for the gateway; the frame header's destination MAC is the gateway's

Lesson 4 · ★★ Don't mix up two tables: ARP cache vs MAC table

Beginner · about 8 min

Goal: Cleanly separate L2's most commonly confused pair of concepts.

Side by side

| | ARP cache | MAC address table |
|---|---|---|
| Lives on | a host | a switch |
| Key → value | IP → MAC | MAC → port |
| Solves what | I know the IP, but the frame header needs a MAC | I know the MAC, I need to pick a port to send it out |
| How it's built | asked for via ARP | self-learned from the source MAC of received frames |
| Default timeout | 20 minutes | 300 seconds |
| View command | display arp | display mac-address |

★ Mnemonic: the ARP cache spans layer 3 and layer 2 (IP→MAC); the MAC table is purely internal to layer 2 (MAC→port).

One ARP resolution updates both tables at once

This is exactly why they're so easy to mix up — they're often filled in at the same time.

After PC1 resolves PC3 once:
· PC1's ARP cache gains one entry: 10.0.0.3 → PC3's MAC
· SW1 / SW2's MAC tables each gain two entries: PC1's MAC → some port, PC3's MAC → some port

★ Same operation, two completely different tables. Go check those two side-by-side tables on the ARP page.

⚠️ But they age out independently — foreshadowing Lesson 5

Notice the last row of that table above: the timeouts are different — 20 minutes vs 300 seconds.

This mismatch causes a very specific real-world phenomenon, covered in the next lesson.

Hands-on: separate them yourself

Go to the Topology & MAC Table page — there are two independent buttons there:
· Clear MAC table (clears only the switches')
· Clear ARP cache (clears only the hosts')

★ Click each one separately and see which table changed and which didn't.

Key takeaways

• The ARP cache lives on hosts, IP → MAC
• The MAC table lives on switches, MAC → port
• One ARP resolution fills both tables at once — which is why they're easy to confuse
• ⚠️ But they age out independently, with timeouts 4× apart

Lesson 5 · Tables forget things: aging, and the real cause of unknown unicast flooding

Intermediate · about 10 min

Goal: Understand the aging mechanism, and where unknown unicast flooding really comes from in the real world.

Why aging has to exist

A MAC table can't just grow forever, for two reasons:

· Table capacity is limited — a switch's MAC table is a hardware table with a few thousand to a few hundred thousand entries, and it can fill up
· Devices move — a laptop moves from the 3rd floor to the 5th; if the entry doesn't update, frames get sent the wrong way

So every dynamic entry carries a timer: if this MAC hasn't been seen again in 300 seconds, delete it.
★ Note "seen" means receiving a frame it sent (where it's the source MAC) — as long as it keeps talking, the entry keeps refreshing and never ages out.

★★★ And that's how this real-world phenomenon comes about

Put the two timeouts side by side:

· Switch MAC table: 300 seconds
· Host ARP cache: 1200 seconds (20 minutes)

The MAC table forgets first.

Consider a device that "speaks rarely" — a backup server, a printer, a monitoring probe:
① It hasn't sent any frame in 10 minutes → the switch ages out its table entry
② But other hosts' ARP caches still remember its MAC (that takes 20 minutes to expire)
③ So a host sends it a unicast frame as usual
④ The switch looks it up → not found → floods it

★★ This is the real cause of unknown unicast flooding.
It's not a misconfiguration — it's the inevitable result of two default values not matching.

Hands-on: reproduce it yourself

Go to the Topology & MAC Table page:
① First send PC1 → PC3 once, so the table gets built
② Click "Clear MAC table" — but don't clear the ARP cache
③ Go back to the Frame Forwarding Simulation page and send PC1 → PC3 again

★ This time you'll see: PC1 doesn't send ARP (it's in the cache) — it sends unicast directly;
but the switch can't find it → unknown unicast flooding. The UI will clearly flag it.

★ You can also use the "Advance time" button to watch aging actually happen once.

How to fix it

· Extend the MAC table's aging time — so it isn't shorter than the ARP cache by so much
· Configure a static MAC entry for critical devices — static entries never age out
· Have the device speak periodically (many monitoring probes refresh their entry as a side effect of heartbeat packets)

★ In practice, the second option is usually preferred: pin the server's / gateway's MAC to a specific port, which also happens to guard against MAC spoofing.

Key takeaways

• A dynamic entry ages out if it hasn't been seen in 300 seconds; it keeps refreshing as long as it keeps talking
• ★★★ The real cause of unknown unicast flooding: the MAC table forgets first at 300 seconds, while the ARP cache still remembers at 1200
• It's not a misconfiguration — it's the inevitable result of two mismatched defaults
• Fixes: extend the aging time / configure a static entry (never ages out)

Lesson 6 · ★★★ Flooding + a loop = disaster

Troubleshooting · about 12 min

Goal: See L2's most severe failure mode, and why it's far scarier than a layer-3 loop.

★★★ The root cause in one sentence: the Ethernet frame header has no TTL

First compare with layer 3: the IP header has a TTL field, decremented by 1 at every router, dropped at 0.
So an L3 loop, while still a fault, at least lets packets kill themselves, and the network can keep breathing.

Now look at the Ethernet frame header — it only has these fields:
Destination MAC | Source MAC | Type | Payload | FCS

★ No TTL, no hop count, no record of "how long it's been alive" at all.
A broadcast frame that enters a loop just circulates forever.

And it grows exponentially

Worse still, it's not just "circulating" — it's doubling constantly:

① PC1 sends out 1 broadcast frame
② The first switch floods it into N copies
③ Each copy reaches the next switch, and each in turn gets flooded into N more → N² copies
④ One more round → N³ copies...

★ After six or seven rounds it's an astronomical number. And nothing exists to reduce them.

Three symptoms hit at once

· A broadcast storm — link bandwidth saturates instantly, every service goes down
· MAC table flapping — the same MAC keeps arriving from multiple ports, and the entry keeps getting overwritten.
★ This is worse than "the table being empty": the table looks full and populated, so the switch thinks it knows where to send things, but that answer keeps changing and is often wrong
· CPU pegged — the switch is too busy copying frames

⚠️ That last point is the scariest part in the real world: you usually can't fix it remotely — you can't even log into the management port, so someone has to walk into the datacenter and unplug a cable.

Hands-on: take down a network once

Go to the Loop & Broadcast Storm page (the current scenario is already a triangle loop) and click "Start simulation".

★ Watch three things:
① The frame copy count each round — exponential growth
② Link utilization — quickly exceeds 100%
③ The MAC table flapping list — the same MAC jumping between two ports

★ You can also try the "④ Redundant dual links" scenario — that's the most common real-world cause: someone plugged in an extra cable just to be safe.

★ The fix: STP, and its cost

There's a tension worth thinking through here: redundant links are a good thing — the whole point of plugging in a second cable is "if one breaks, the other takes over."

So the right move isn't "don't have redundancy" — it's "have redundancy, but only use one path at a time."

STP (Spanning Tree Protocol) does exactly that:
· Computes a spanning tree across all links
· Blocks the extra links (not forwarding, but still listening)
· If the primary link goes down, the blocked port takes over automatically

★ The cost is that the blocked links are paid for but unusable — half the bandwidth sits idle.
This is exactly why datacenters later replaced STP with L3 + ECMP (see that comparison on the "Architecture comparison" page of the "Datacenter Spine-Leaf" module).

★★ While you're here, keep two easily-confused abbreviations straight:
· STP (Spanning Tree, layer 2) → computes a tree, blocks redundant links
· SPF (Shortest Path First, layer 3) → computes shortest paths, every link can forward
The OSPF and IS-IS modules use the latter.

Key takeaways

• ★★★ Root cause: the Ethernet frame header has no TTL, so a frame that enters a loop circulates forever
• Copies double exponentially, with nothing to reduce them
• Three symptoms: broadcast storm + MAC table flapping + CPU pegged
• ⚠️ A pegged CPU means you can't fix it remotely — someone has to walk into the datacenter
• ★ The fix is STP: keep the redundancy but only use one path, at the cost of half the bandwidth sitting idle