Inside the Switch: MAC Learning, VLANs and Loops

Inside the Switch: MAC Learning, VLANs and Loops

What you'll learn

• Trace a switch's MAC address table through learning, forwarding, filtering and flooding
• Explain port security — and why MAC randomization on modern devices complicates it
• Create broadcast domains administratively with VLANs, and name the standard behind them (802.1Q)
• Describe, at awareness level, why switching loops happen and how spanning tree prevents them
• Configure two VLANs on one switch in Packet Tracer and demonstrate the broadcast boundary

How a switch learns: the MAC address table

This lesson builds on Chapters 1 and 4 of Dr. Tahseen Al-Doori's Network Essentials — the chapters that first showed a switch memorizing "which machine lives on which port." Now we make that memory precise.

Inside every switch lives one crucial data structure: the MAC address table (you will also hear the older name CAM table), mapping MAC addresses to ports. The switch fills it by learning: every arriving frame carries a source MAC address, and the switch notes "that address entered on this port" — eavesdropping on return addresses, essentially, and building its map for free from ordinary traffic. Entries age out after a few idle minutes, so the map stays current as devices move.

For each arriving frame, the destination MAC then triggers one of three verdicts:

• Forward. Destination is in the table on a different port → send the frame out that one port. This is the micro-segment from lesson 3, now with its machinery exposed.
• Filter. Destination is in the table on the same port the frame arrived from (both machines sit behind the same port, perhaps via another switch) → drop it; delivery already happened locally, and the rest of the network never needs to know.
• Flood. Destination unknown — or the frame is a broadcast → copy it out every port except the arrival port. Generous, deliberate, and the reason a switch never fails to deliver merely because its table is young.

That is the entire intelligence of the device that runs every LAN on Earth: read source, remember; read destination, decide among three verdicts. Simple rules, executed millions of times a second — and one of them, flooding, is about to become this lesson's main character.

Managed switches and port security

Chapter 4 splits switches into two commercial tiers, and the split still matches the 2026 catalog. An unmanaged switch is plug-and-play: it learns and forwards exactly as above, offers no configuration at all, and serves homes and tiny offices honorably. A managed switch adds a brain you can talk to — command-line and web interfaces, remote access, monitoring — and with it the professional features: VLANs (this lesson's centerpiece), loop protection tuning, sometimes layer 3 routing, and port security.

Port security is the switch checking membership cards at the door: an administrator limits a port to specific MAC addresses (or a maximum count of them), and the port reacts to violations — typically by shutting itself down. Plug a rogue device into a lobby wall jack and the port goes dark instead of granting entry.

Two honest caveats before you trust it with your life. First, a MAC address is an identifier, not a credential — devices can present whatever address their driver is told to, so port security deters accidents and casual intrusion, not determined attackers (real admission control, 802.1X, appears in Module 7). Second, a 2026 wrinkle the book could not have seen: MAC randomization. The book could describe a MAC address as a burned-in, globally unique device identifier — and for wired NICs that default still holds. But modern phones, tablets and laptops deliberately randomize their Wi-Fi MAC addresses (default behavior on iOS and Android for years now, with newer Android versions able to rotate the address over time) precisely so their burned-in identity cannot be tracked across networks. Consequence: MAC-based recognition of wireless clients — for security or for network policy — is unreliable by design. Port security remains a reasonable wired-access-port hygiene measure; treat any MAC-based control of wireless devices as broken until proven otherwise.

VLANs: broadcast domains by decree

Now the module's ideas converge. Lesson 3 established that switches don't stop broadcasts — only routers do — and that oversized broadcast domains drown in their own noise. The obvious fix is physical: more switches, a router between them. But Chapter 1 poses a thought experiment that opens a second path, and it is worth retelling.

Picture two identical switches stacked one on the other, cabled together — logically one big switch, one broadcast domain. Now pull them apart and put a router between them: two broadcast domains, by hardware. Classic. But return to the stacked pair and try something subtler: instead of moving any cable, tell the switches that odd-numbered ports form one group and even-numbered ports another — a broadcast arriving on an odd port goes only to odd ports; even, only to even. No new boxes, no rewiring: two broadcast domains, drawn in configuration. That administrative grouping is a VLAN — a virtual LAN.

Definition, formally: a VLAN is a broadcast domain created administratively on a switch, by assigning ports to numbered groups. A frame entering a VLAN-10 port can reach only VLAN-10 ports; broadcasts included. Machines in different VLANs on the same physical switch are, for all layer-2 purposes, on different networks — as separated as if an ocean lay between them.

Why network designers reach for VLANs daily:

• Broadcast containment. Each VLAN's chatter stays home; the switch stops carrying every department's noise to every port.
• Security segmentation. Finance machines cannot even see frames from the guest VLAN. Remember lesson 2's twin wall jacks — PC and VoIP phone side by side? The phone's jack belongs to a voice VLAN; that mysterious "separate virtual network" now has a name.
• Organization by logic, not geography. Group by team or function even when members sit on different floors — membership is configuration, so moving a user is an edit, not a cable pull.

Two consequences complete the picture. First: if VLANs make groups unreachable to each other, how do odd ports ever talk to even ports when they legitimately must? The same way any two networks talk: through a router. The thought experiment's answer was one router connection per VLAN; the modern answer is inter-VLAN routing — a router (or layer 3 switch) hopping traffic between VLANs under policy — and its configuration belongs to your routing education in Module 5 and the capstone. For now, own the principle: within a VLAN, switching; between VLANs, routing, always.

Second: VLANs would collapse at building scale if each one needed its own cable between switches. The fix is the standard the book's era used but never named — IEEE 802.1Q (current). It defines a tag, a small field inserted into a frame that declares "I belong to VLAN 20," so one switch-to-switch link — called a trunk — can carry every VLAN's traffic simultaneously, each frame wearing its membership. Ports facing computers (access ports) belong to one VLAN and carry ordinary untagged frames; ports facing other switches (trunk ports) speak 802.1Q. That one-sentence distinction is all this course needs — but knowing the name 802.1Q, and where it sits in the 802.1 family from last lesson, marks you as someone who studied after 2007.

Loops and the spanning tree (awareness level)

One more piece of switch intelligence, and you have already seen it: the amber light in Packet Tracer #1.

Careful network designers connect switches with redundant links — two paths, so one failure doesn't isolate a floor. But redundancy at layer 2 hides a trap. Recall from Module 2 that an IP packet carries a TTL, a hop budget that eventually kills any packet circling the network. A frame has no such budget. Now replay lesson 3's flooding rule across two switches joined by two links: a broadcast arrives at switch A, which floods it out both links to switch B; B, following the same honest rule, floods each copy back toward A; copies multiply and circulate — forever, at wire speed. Within seconds the loop devours every port's capacity, MAC tables scramble (the same source address keeps arriving on different ports), and the network dies of enthusiasm. This is a switching loop, expressed as a broadcast storm — arguably the most dramatic self-inflicted failure a LAN can suffer.

The cure is the Spanning Tree Protocol (STP), and its idea fits in three sentences. The switches hold an election and agree on one switch as the root of a tree. Every switch then keeps its best path toward the root active and puts redundant links into a blocking state — still listening, forbidden to forward. If an active link dies, a blocked port wakes up and takes over: redundancy preserved, loops made impossible, because a tree by definition has no cycles.

That amber half-minute in Packet Tracer? A new port being checked before it may forward — STP making sure you didn't just create a loop. The protocol's deployed forms today are RSTP (Rapid STP — the modern replacement, converging in about a second rather than the original's leisurely pause) and MSTP (its multi-VLAN sibling). And here this course deliberately stops: root elections, port roles, priorities and timers are CCNA territory, beyond an essentials course by design. Your awareness-level takeaways: loops are lethal at layer 2 because frames never expire; spanning tree spends redundant links to prevent loops; RSTP is today's name. That is genuinely enough.

From the textbook to 2026

Every mechanism in this lesson has aged with unusual grace — the book's odd/even thought experiment could run unchanged in any 2026 classroom, and does, in ours. What the years added: the name 802.1Q for the tagging the book's VLANs already implied, and trunks as the way VLANs span switch fabrics; RSTP/MSTP as the spanning tree actually deployed (the original's slow convergence retired it); and MAC randomization, which quietly broke the "burned-in unique identifier" assumption for wireless clients and demoted MAC-based controls to wired-only hygiene. VLANs themselves grew from an advanced feature into the default texture of every network you will touch: guest Wi-Fi, voice phones, security cameras, IoT sensors — each lives in its own VLAN, and the capstone will have you designing exactly that.

Watch: VLAN Explained

Why this video earns its place. PowerCert Animated Videos — the same channel whose hub-switch-router animation anchored lesson 3 — gives VLANs the visual treatment: one physical switch dissolving into separate color-coded logical networks. Segmentation is inherently spatial, and watching ports change allegiance without a cable moving makes the "drawn in configuration, not copper" idea land in a way text cannot. The video dates from 2018, but VLAN fundamentals are among networking's most stable ground — 802.1Q has not changed underneath it.

As you watch, notice:

• The moment one switch becomes several logical networks — the odd/even thought experiment you just read, animated in color.
• Broadcasts stopping at the VLAN edge — the exact behavior your Packet Tracer lab below will prove frame by frame.
• Devices grouped by role rather than by where they sit — the "logic, not geography" benefit in motion.
• What the animation keeps light: it is a concepts video, so expect little or nothing on 802.1Q tagging, trunk-versus-access ports, or inter-VLAN routing — the sections above are your record of those, and Module 5 picks up the routing thread.

The video reinforces visually what you just learned — the lesson is complete without it.

Lab: Packet Tracer #2 — Two VLANs, one switch

Lesson 3's lab showed you flooding; this one lets you fence it. You will build a four-PC switch network, watch a broadcast reach everyone, then split the switch into two VLANs and prove — with the simulator's own animation — that the broadcast now stops at a boundary you created with five commands.

Objective. Configure two VLANs on one switch and demonstrate that VLAN membership, not addressing, decides who receives a broadcast.

Setup. Packet Tracer installed (lesson 3's lab covers the free download via Cisco Networking Academy). Start a new blank file — or reuse the switch half of m3-pt1 and simply re-address the PCs as below. Instructions stay version-agnostic.

Steps.

Build and baseline.

1. Place one 2960 switch and four PCs. Cable each PC to the switch with Copper Straight-Through, in order: PC0 → port Fa0/1, PC1 → Fa0/2, PC2 → Fa0/3, PC3 → Fa0/4. (The port-to-PC mapping is the whole game today — keep it exact.) Wait out the amber lights; you now know what they are.
2. Address all four PCs in one subnet — deliberately: PC0 = 192.168.1.11, PC1 = 192.168.1.12, PC2 = 192.168.1.13, PC3 = 192.168.1.14, mask 255.255.255.0 everywhere. As far as addressing is concerned, these four machines are one happy network.
3. Baseline in Realtime mode: from PC0, ping 192.168.1.13 (that's PC2). It succeeds — hold on to that.
4. Now watch a broadcast. Switch to Simulation mode, click Edit Filters, and tick ARP and ICMP only. From PC0's Command Prompt run ping 192.168.1.14 (PC3). Step through with the capture/forward button: before any ping can travel, PC0 must find PC3, so it sends an ARP request — a genuine layer 2 broadcast (Module 4 dissects ARP; today it is your broadcast specimen). Watch the switch flood it to every PC. All ports, one broadcast domain: the baseline truth.

Split the switch.

5. Click the switch and open its CLI tab — your first time at a real network operating system prompt. Press Enter, then type these commands, pressing Enter after each. (Type them exactly; the prompt shown at each stage tells you where you are.)

   codeCopy

   enable
   configure terminal
   vlan 10
   name TEAM-A
   vlan 20
   name TEAM-B
   exit
   interface range fastEthernet 0/1 - 2
   switchport mode access
   switchport access vlan 10
   interface range fastEthernet 0/3 - 4
   switchport mode access
   switchport access vlan 20
   end
   

6. Verify your work with the switch's own report: type show vlan brief. You should see VLAN 10 TEAM-A holding Fa0/1 and Fa0/2, and VLAN 20 TEAM-B holding Fa0/3 and Fa0/4. If the table says otherwise, redo step 5 — the switch believes its table, not your intentions.

Prove the boundary.

7. Realtime mode, same-VLAN test: from PC0 (VLAN 10), ping 192.168.1.12 (PC1, VLAN 10). Success — inside a VLAN, nothing changed.
8. Cross-VLAN test: from PC0, ping 192.168.1.13 (PC2 — same subnet as before, but now VLAN 20). Request timed out. The very ping that succeeded in step 3 now fails, though not one address changed. (If the first attempt oddly succeeds, PC2 may be remembered from the baseline: in PC0's Command Prompt run arp -d to clear the memory, then ping again.)
9. Now see why it fails. Simulation mode, filters still ARP + ICMP: repeat the ping to PC2 and step through. PC0's ARP broadcast enters the switch — and leaves by exactly one port, Fa0/2, the only other member of VLAN 10. Ports Fa0/3 and Fa0/4 receive nothing. The ARP question "who has 192.168.1.13?" physically never reaches PC2, so no answer, no delivery — the broadcast stopped at a fence made of configuration. Compare this animation with step 4's flood-to-everyone: same switch, same addresses, different world.
10. Save as m3-pt2. The capstone will ask you to build VLANs again, at scale, with this file as your reference.

Expected result. Baseline: ARP broadcast floods to all PCs; all pings succeed. After configuration: show vlan brief shows two named VLANs of two ports each; pings succeed within a VLAN, time out across; in simulation, PC0's ARP broadcast reaches only its VLAN partner.

Verify. You can state, pointing at your own simulation panel: which single port the broadcast exited after VLAN configuration, and which two ports it no longer reaches. And you can answer: did any PC's address change between the working ping and the failing one? (No — that is the proof.)

Questions.

1. In step 8, at exactly which device — and by which of the switch's three verdicts — did the cross-VLAN ping die?
2. All four PCs still share one subnet. What does the failed ping tell you about the relationship between addressing (layer 3) and VLAN membership (layer 2)?
3. What single addition would let TEAM-A and TEAM-B communicate again, and what is that arrangement called?
4. Your switch now contains how many broadcast domains? How many did it contain in step 4?

(Answers: 1 — at the switch: PC0's ARP broadcast was flooded only within VLAN 10, so PC2 never learned it was wanted; the ICMP ping itself never even left PC0, which was still waiting for ARP's answer. 2 — they are independent layers: shared addressing cannot cross a layer 2 fence; a VLAN boundary beats a subnet's promises. 3 — a router (or a layer 3 switch) connected to both VLANs, routing between them — inter-VLAN routing, configured in Module 5 and the capstone. 4 — two now; one before.)

If it goes wrong.

• CLI rejects a command ("invalid input"): you are likely at the wrong prompt level — type end, press Enter, and restart step 5 from configure terminal. Watch the prompt change as you descend.
• show vlan brief shows ports still in VLAN 1. The switchport access vlan lines didn't take — re-enter the interface range block for the affected ports. (VLAN 1 is the factory-default VLAN every port starts in; your configuration moves ports out of it.)
• Cross-VLAN ping still succeeds. Almost always a port-mapping slip: confirm which physical port each PC's cable actually uses (hover over the cable ends) against step 1's mapping.
• Same-VLAN ping fails. Check addresses and masks first (step 2), then show vlan brief to confirm both ports really share a VLAN.
• Simulation panel shows nothing. Edit Filters — tick ARP and ICMP.

Reset/cleanup. Nothing real was touched. Keep m3-pt2.pkt. If you want the switch back to factory innocence for re-practice, the fastest honest route in a simulator: delete it, drag out a fresh one, and rebuild — repetition is the point.

Check yourself

1. A switch fresh from the box receives its first frame ever, from PC-A addressed to PC-B. Describe everything the switch does with that frame — and what it does differently with PC-B's reply.
2. Two PCs sit in the same subnet on the same switch but different VLANs. A colleague insists "same subnet means they can talk." Design the one-command experiment from this lesson's lab that settles it, and predict the result.
3. Port security limits a lobby wall jack to one specific MAC address. List two distinct reasons this control can fail against modern devices, drawing on this lesson's caveats.
4. An office connects two switches with two cables "for backup" on gear with spanning tree disabled. Narrate the first sixty seconds after someone's PC sends one broadcast — then explain what STP would have done with the second cable.
5. A 30-person office wants guest Wi-Fi, staff PCs and VoIP phones kept mutually invisible at layer 2, using one switch. Sketch the VLAN plan in three lines, and name what the phones-on-data-jacks arrangement from lesson 2 corresponds to.
6. Why does putting IoT devices (cameras, sensors) in their own VLAN improve security even if their traffic is not otherwise filtered? Answer with this lesson's vocabulary.

Answers

1. The frame's source teaches: the switch records PC-A's MAC against the arrival port. The destination is unknown, so the verdict is flood — out every port except the arrival port. PC-B's reply teaches the switch PC-B's port (source learning again), and its destination — PC-A — is now in the table, so the verdict is forward, out one port only. Two frames, table complete, flooding over.
2. From one PC, ping the other (after arp -d to clear any remembered answer). Prediction: request timed out — and in simulation mode the pinger's ARP broadcast will visibly reach only its own VLAN's ports. Addressing proposes; VLAN membership disposes.
3. First, a MAC is an identifier, not a credential — any device can present the permitted address deliberately (spoofing). Second, if wireless devices are involved anywhere in the chain, MAC randomization means the "one specific MAC" may legitimately change, locking out the authorized user — the control misfires in both directions.
4. The broadcast reaches switch A, which floods it out both inter-switch links; switch B floods each copy back; copies multiply and circulate at wire speed with no TTL to kill them. Within seconds: a broadcast storm — ports saturated, MAC tables churning as the same sources appear on shifting ports, the LAN effectively down. STP would have elected a root, kept one inter-switch link forwarding, and put the second into blocking — silent, listening, ready to take over if the first fails.
5. VLAN 10 STAFF for desk ports; VLAN 20 VOICE for the phones; VLAN 30 GUEST for the access point serving visitors — three broadcast domains on one switch, mutually unreachable without a router's say-so. The phone jacks beside PC jacks are access ports in the voice VLAN: lesson 2's "separate virtual network," now built by you.
6. Their own VLAN is their own broadcast domain: a compromised camera can flood, scan and ARP-trick only its VLAN-mates, and it cannot even see frames from the staff network. Layer 2 invisibility shrinks the blast radius before any firewall rule is written — segmentation as containment.

Key terms

• MAC address table (CAM table) — the switch's learned map of MAC addresses to ports, built from frame source addresses, aged out when idle.
• Learning / forward / filter / flood — the switch's method: remember sources; deliver to one port, drop the already-delivered, or copy to all ports for broadcasts and unknowns.
• Unmanaged / managed switch — plug-and-play forwarding vs. configurable: VLANs, port security, monitoring, remote access.
• Port security — restricting a switch port to specific or limited MAC addresses; wired-access hygiene, not strong authentication.
• MAC randomization — modern wireless clients presenting changing MAC addresses by default, breaking MAC-based recognition for Wi-Fi devices.
• VLAN — a broadcast domain created administratively on a switch by grouping ports; virtual because it is drawn in configuration, not cabling.
• IEEE 802.1Q — the VLAN tagging standard: frames carry a tag naming their VLAN so trunks can carry all VLANs at once.
• Access port / trunk — a one-VLAN port facing end devices vs. a switch-to-switch link carrying tagged traffic for many VLANs.
• Inter-VLAN routing — the router's (or layer 3 switch's) job of carrying traffic between VLANs; within a VLAN switch, between VLANs route.
• Switching loop / broadcast storm — frames circulating endlessly through redundant layer 2 paths (no TTL to stop them), saturating the LAN.
• STP / RSTP / MSTP — spanning tree: elect a root, block redundant links, unblock on failure; RSTP is today's fast-converging deployment, MSTP its multi-VLAN form.
• VLAN 1 — the factory-default VLAN all switch ports start in.

Summary

• A switch is three verdicts on top of one table: learn from sources; forward, filter or flood by destination.
• Managed switches add VLANs, port security and monitoring; port security is honest wired hygiene, but MAC addresses are identifiers rather than credentials — and wireless MAC randomization breaks MAC-based recognition by design.
• A VLAN is a broadcast domain by decree: ports grouped in configuration, unreachable across groups at layer 2 — even inside one subnet, as your lab proved frame by frame.
• 802.1Q tags let trunks carry every VLAN across one link; access ports face devices, trunks face switches.
• Between VLANs, always a router: inter-VLAN routing, arriving properly in Module 5 and the capstone.
• Redundant layer 2 links invite loops — frames never expire — so spanning tree (today RSTP/MSTP) blocks the spares and wakes them on failure; that is the amber light, and all the STP depth this course needs.
• Module 3 complete: media, connectors, devices, standards, and the switch's mind. Download: Module 3 Cheat Sheet (the whole physical network on one page — worth printing before Module 4).

Next lesson

Module 4 changes the subject from copper to counting: binary, the language every address is written in — then IPv4 addresses, subnet masks, and the addressing craft that turns "192.168.1.11" from a label you copied in a lab into a number you can dissect. The physical network is built; now we learn to name everything on it.

Sources and further study

• Al-Doori, T., Network Essentials, Chapters 1 and 4 — the micro-segment teaching, the odd/even VLAN thought experiment, switch functions and loop avoidance.
• IEEE 802.1Q, "Bridges and Bridged Networks" — https://1.ieee802.org/tsn/802-1q/ — the standard behind VLAN tagging and modern spanning tree.
• Cisco, "What Is a Network Switch vs. a Router?" — https://www.cisco.com/c/en/us/solutions/small-business/resource-center/networking/network-switch-vs-router.html — the boundary this lesson's inter-VLAN rule rests on.
• Wireshark Wiki, "CaptureSetup/Ethernet" — https://wiki.wireshark.org/CaptureSetup/Ethernet — why, on a switched network, your capture sees only your own micro-segment's traffic plus broadcasts; a preview of Module 8's capture craft.