You're staring at a switch port blinking amber. Again Easy to understand, harder to ignore..
The ticket says "intermittent connectivity" but the logs show nothing useful. No errors. Plus, no CRC spikes. Just users dropping off and reconnecting every few minutes. Day to day, you've replaced the patch cable. Swapped the port. Even swapped the switch. Same problem Small thing, real impact..
Here's the thing — most engineers don't actually understand how a switch decides what to do with a frame. They know that it forwards frames. They've memorized "MAC address table.But " But ask them what happens when a frame arrives with a destination MAC the switch has never seen? Or why a switch floods a broadcast but not a unicast to an unknown MAC? The answers get fuzzy Simple, but easy to overlook..
That's the gap. And it's exactly what the 7.In real terms, 1. 5 check your understanding section in the Cisco curriculum is trying to close.
What Is Ethernet Switching Really
Ethernet switching isn't magic. It's a deterministic process built on a simple premise: learn where devices live, then forward frames only where they need to go. Everything else — VLANs, trunking, STP, EtherChannel — layers on top of that core logic The details matter here. Nothing fancy..
A switch maintains a MAC address table (sometimes called a CAM table — Content Addressable Memory). If it's seen before but on a different port, it updates the entry. Also, it maps that MAC to the ingress port. In real terms, every time a frame enters a port, the switch looks at the source MAC address. If the MAC is new, it adds an entry. That said, this is learning. It happens silently, constantly, on every frame.
Then comes the forwarding decision. The switch examines the destination MAC. Three possibilities:
- Known unicast — MAC exists in the table, associated with a port other than the ingress port. Forward out that single port.
- Unknown unicast — MAC not in table. Flood out all ports in the same VLAN except the ingress port.
- Broadcast / multicast — Flood out all ports in the same VLAN except the ingress port.
That's it. Day to day, that's the entire switching logic. The complexity comes from what happens around that decision.
The CAM Table Isn't Forever
Entries age out. In real terms, networks change. Default aging timer on Cisco switches: 300 seconds (5 minutes). But next frame for that MAC? Here's the thing — flooded. Also, if a device goes silent — laptop sleeps, server reboots, IP phone unplugs — its MAC entry eventually disappears. Because of that, this is by design. Tables must reflect reality Less friction, more output..
But here's where people get burned: aging timer ≠ link down detection. If a port goes down (link failure, shutdown, cable pull), the switch immediately flushes all MACs learned on that port. No waiting for the timer. This distinction matters when troubleshooting flapping ports Less friction, more output..
Switching Methods: Store-and-Forward vs Cut-Through
You'll see this in the curriculum. It's not just trivia.
Store-and-forward — The switch receives the entire frame, runs CRC check, then forwards. Latency varies with frame size. Bad frames get dropped. This is the default on modern Catalyst switches.
Cut-through — The switch reads only the destination MAC (first 6 bytes after preamble/SFD), makes the forwarding decision, and starts transmitting before the rest of the frame arrives. Lower latency. But zero error checking. A corrupted frame gets propagated.
Fragment-free — A compromise. Reads first 64 bytes (collision window) before forwarding. Catches most collision fragments. Rarely used now No workaround needed..
Modern switches? Almost all store-and-forward. ASICs are fast enough that latency difference is negligible. But exam questions still ask. Know the tradeoffs Small thing, real impact. That alone is useful..
Why This Matters More Than You Think
You might be thinking: "I configure VLANs and trunks all day. Why do I care about flooding logic?"
Because every weird Layer 2 symptom traces back to this.
The Mystery of the Missing MAC
Scenario: Server A talks to Server B. Works fine. Comes up. Both on same VLAN, same switch. ARP fails. And ping fails. Server A tries to talk — nothing. Reboots. Then Server B's NIC driver updates. But Server B can ping Server A.
What happened? That said, server B's MAC aged out during reboot. Server A still has Server B's MAC in its ARP cache. Server A sends unicast frames to Server B's MAC. So switch looks at destination MAC — not in table. Floods to all ports in VLAN. On the flip side, server B receives. In practice, replies. Practically speaking, switch learns Server B's MAC on reply. Now return traffic works. But Server A's next frame? Still flooded until Server A's ARP cache refreshes or Server B sends something The details matter here. Nothing fancy..
The official docs gloss over this. That's a mistake.
This asymmetry — one direction works, the other doesn't — confuses people who don't understand independent learning per direction.
Broadcast Storms Start With Flooding
A looped topology + no STP = broadcast storm. Exponential growth. One of those ports loops back to the switch. Switch sees broadcast on another port, floods again. Here's the thing — cPU hits 100%. Even so, why? Because a broadcast frame gets flooded out every port. Everything dies.
This is why STP exists. But STP only blocks ports. It doesn't change the flooding logic. The switch still floods broadcasts on forwarding ports. Understanding this helps you design loop-free topologies instead of relying on STP to save you.
Security Implications
MAC flooding attacks. Consider this: an attacker sends thousands of frames with random source MACs. Switch table fills. Legitimate MACs get pushed out (or table hits hardware limit). Next legitimate frame? That said, unknown unicast. Flooded. Attacker on another port sees all traffic.
Port security limits MACs per port. But you need to understand why it works — it stops the table exhaustion at the source.
How It Works: The Frame Walkthrough
Let's trace a frame end-to-end. This is the mental model you need.
Step 1: Frame Arrives
Physical layer: bits become bytes. In practice, etherType/Length. Source MAC (6 bytes). This leads to payload. In practice, destination MAC (6 bytes) — first thing the switching ASIC sees. But preamble (7 bytes) + SFD (1 byte) sync the receiver. FCS (4 bytes) Which is the point..
Step 2: Learn Source MAC
Switch extracts source MAC. Because of that, update timestamp. Consider this: - Present on different port? Practically speaking, - Present on same port? Still, move entry to new port, update timestamp. Add entry: MAC → ingress port + VLAN + timestamp. Checks CAM table:
- Not present? (This handles device moves.
Step 3: Forwarding Decision
Extract destination MAC. Now, - No match → Flood to all ports in same VLAN except ingress port. Plus, destination is on same segment. That said, check CAM table:
- Match found, different port → Forward out that port only. Now, - Broadcast (FFFF. FFFF) → Flood to all ports in same VLAN except ingress port. On the flip side, fFFF. - Match found, same port → Filter (drop). No need to forward.
- Multicast → Flood (unless IGMP snooping / MLD snooping enabled — then forward only to interested ports).
Step 4: Transmit
Frame queued on egress port. If port busy, frame waits in queue. On the flip side, qoS policies may prioritize. Here's the thing — if queue fills? Tail drop.
Step 4 (Continued): Transmit
If the queue fills, the switch employs congestion avoidance mechanisms like tail drop (dropping new frames when buffers are full) or WRED (Weighted Random Early Detection) to randomly discard packets before saturation, preventing buffer overflow and maintaining throughput. The switch also validates the Frame Check Sequence (FCS) to ensure data integrity. If the FCS is invalid, the frame is silently discarded.
For multicast traffic, switches without IGMP snooping or MLD snooping flood frames to all ports in the VLAN, while those with snooping forward multicast only to ports that have explicitly joined the group via IGMP/MLD messages.
Conclusion
Grasping these fundamental switching behaviors—MAC learning, frame forwarding, flooding logic, and error handling—is essential for designing resilient, secure networks. By mastering the frame lifecycle, network engineers can troubleshoot performance bottlenecks, prevent topology loops, and defend against Layer 2 threats. Now, broadcast storms and MAC flooding attacks exploit gaps in understanding how switches process traffic, but proactive measures like STP, port security, and proper VLAN segmentation mitigate these risks. When all is said and done, these concepts form the backbone of efficient switching, ensuring data flows predictably and securely across modern infrastructures That's the whole idea..
