Network Access Foundational

Switching Operation

How a switch actually decides where to forward each frame. Covers source-MAC learning, destination-MAC lookup, the three outcomes (forward / flood / drop), and store-and-forward vs cut-through.

TL;DR

A switch's job per-frame: learn the source MAC on the inbound port, look up the destination MAC, then forward, flood, or drop.
Forward = known destination → out one port. Flood = unknown destination → out all other ports in the VLAN. Drop = destination is on the same port the frame arrived on.
Store-and-forward (default) buffers the whole frame and validates the FCS before forwarding. Cut-through forwards as soon as the destination MAC is read — faster but no error checking.

Mental model

A switch does one thing per frame: decide which port (if any) to send it out. The decision is mechanical:

Receive a frame on a port.
Learn — record the source MAC of this frame against the port it came in on (in the MAC address table).
Look up the destination MAC in the same table.
Forward, Flood, or Drop based on the lookup result.

This happens billions of times a second in a busy LAN. Hardware does it at wire-speed.

The three outcomes

Forward (the common case)

Destination MAC is in the table, mapped to a specific port. Send the frame out only that one port. No one else sees it.

Frame arrives on Gi0/1 destined for dd:dd:dd
CAM table says dd:dd:dd is on Gi0/5
→ forward out Gi0/5 only

This is what makes switches different from hubs — and dramatically more efficient. Traffic between PC-A and PC-B doesn’t disturb PC-C.

Flood (unknown destination)

Destination MAC isn’t in the table. The switch sends the frame out every other port in the same VLAN — every port except the one the frame came in on. The hope: somewhere out there, the destination exists and will reply, which lets the switch learn its port.

Frame arrives on Gi0/1 destined for ee:ee:ee (unknown)
→ flood out Gi0/2, Gi0/3, Gi0/4, ..., everywhere except Gi0/1

Three triggers cause flooding:

Unknown unicast — destination not in MAC table
Broadcast — destination FF:FF:FF:FF:FF:FF (always flooded)
Multicast — flooded unless IGMP snooping is configured

Drop

If the destination MAC is on the same port the frame arrived on, the switch drops the frame. Two hosts on the same physical port (impossible normally, but possible through a hub) would already have heard the frame — no point forwarding it back.

Less common: drops happen for security policy (port security violation, ACL on an SVI, STP-blocked port).

Store-and-forward vs cut-through

Two switching modes:

Mode	Behavior	Trade-off
Store-and-forward	Buffer the entire frame, check FCS (frame check sequence), then forward	Slightly higher latency but no corrupt frames forwarded
Cut-through	Forward as soon as the first 14 bytes (destination MAC) are read	Lowest latency but corrupt frames propagate
Fragment-free	Cut-through, but wait for the first 64 bytes (catches collision fragments)	Compromise between the two

Modern Cisco Catalyst switches default to store-and-forward. Cut-through exists on data-center switches (Nexus, some merchant silicon) where every microsecond of latency matters. For CCNA, know all three terms; in real life, store-and-forward is what you have.

Why the switch never reads the IP header

Switches are Layer 2 devices. They see frames and MACs, full stop. The IP header inside the frame is irrelevant to switching decisions.

That’s why:

Switching doesn’t need a router involved (Layer 3) when destination is in the same VLAN
Different VLANs can’t talk without a router because the switch refuses to forward frames between VLANs — even though they share the same physical hardware
ACLs on regular switches operate on MAC / port; for IP-based filtering on a switch, you need a Layer-3 switch with SVIs

Per-VLAN switching

The MAC table is per-VLAN. A switch maintains separate tables for VLAN 10 and VLAN 20.

SW1# show mac address-table vlan 10
   10    aaaa.aaaa.aaaa    DYNAMIC     Gi0/1
   10    bbbb.bbbb.bbbb    DYNAMIC     Gi0/2

SW1# show mac address-table vlan 20
   20    cccc.cccc.cccc    DYNAMIC     Gi0/5

When a frame arrives, the switch looks up the destination MAC only within the VLAN tagged on the frame. Same MAC in two different VLANs? Two separate entries, treated independently.

Switching modes you can set

SW1(config)# switching-mode store-and-forward       ! default on most platforms
SW1(config)# switching-mode cut-through             ! some platforms only

Most Catalyst switches don’t expose this — they’re hardwired to one mode. Nexus and Data Center platforms expose it.

Common mistakes

Expecting switches to look at IP addresses. They don’t. Layer 2 only. If you need IP-based filtering, you need a Layer-3 switch (SVIs) or a router.
Forgetting flooding happens on unknown unicast. A quiet server whose MAC ages out causes its next inbound frame to flood every port. Mitigation: longer aging time or static MAC entries for critical servers.
Confusing “flooding” with “broadcasting.” Broadcast = destination MAC FF:FF:FF:FF:FF:FF, by definition reaches everyone. Flooding = forwarding behavior, can happen for unicast / broadcast / multicast.
Thinking VLANs use Layer-3 separation. They use Layer-2 separation. Same physical switch, separate broadcast domains. Inter-VLAN traffic needs a router.
Setting cut-through and being surprised by corrupted frames. Cut-through propagates errored frames before the FCS is checked. Bad cabling or marginal optics → cascading errors. Use store-and-forward unless you have a specific reason.
Misunderstanding switch fabric capacity. A switch’s “switching capacity” (sometimes called backplane) is what it can move in aggregate, not per port. A 24-port 1 Gbps switch might have 48 Gbps full-duplex switching capacity (24 × 1 × 2). Anything less and the switch is oversubscribed.

Lab to try tonight

One switch, three PCs in the same VLAN.
Run show mac address-table — empty (no traffic yet).
Ping PC-A from PC-B. Re-run — both MACs appear.
Open Wireshark on PC-C. Ping PC-A from PC-B again. Confirm PC-C does NOT see the ping (forward, not flood).
clear mac address-table dynamic. Repeat the ping. PC-C briefly sees the first frame in Wireshark (flooded), then the table re-populates and subsequent frames don’t flood.
Add static MAC entry pinning PC-A. Confirm it survives clear mac address-table dynamic.
Bonus: add VLAN 20, put PC-C in it. Try to ping from PC-A (VLAN 10) to PC-C (VLAN 20). Fails — different VLANs, no router.

Cheat strip

Concept	Plain English
Learn	Record source MAC against inbound port
Look up	Search CAM table for destination MAC
Forward	Known destination → send to that one port
Flood	Unknown destination / broadcast → send everywhere else in VLAN
Drop	Destination is on the same port frame arrived on
Store-and-forward	Default. Buffer full frame, check FCS.
Cut-through	Forward after 14 bytes. Fast, error-prone.
Fragment-free	Forward after 64 bytes. Catches collision fragments.
Per-VLAN table	Different MACs tracked separately per VLAN

← Previous topic

Wi-Fi Security — WEP, WPA, WPA2, WPA3

Twenty-five years of wireless security in one page. Why WEP is broken, why WPA is a stop-gap, why WPA2 ruled for two decades, and what WPA3 actually fixes.

Next topic →

CDP & LLDP — Neighbor Discovery

How devices learn about their directly-connected neighbors. CDP is Cisco-proprietary; LLDP is the vendor-neutral standard. Both shout the same info: who I am, what model, what IOS, what port — invaluable for troubleshooting.

Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep — built around the CCNA® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

One topic per email, every fortnight

VLANs, OSPF, ACLs, subnetting, automation — written like this. Unsubscribe in one click.

We respect your inbox. One email per week, max. Unsubscribe any time.