FUNDAMENTALS · MECHANISM WALKTHROUGH

Unknown Unicast
What a Switch Does With a MAC It Hasn't Learned

the switch's own decision process — learning, aging, and the flood-then-learn cycle. this scenario is deliberately not about ARP: it's what happens when a MAC table entry goes cold while the host is still perfectly reachable.

FRAME ARRIVES→ SOURCE MAC LEARNED→ DEST LOOKUP: MISS→ FLOOD (VLAN)→ HOST REPLIES→ DEST MAC LEARNED→ KNOWN UNICAST

01 The Full Sequence — Worked Example

Two Independent Timers

PC-A resolved Server-S's MAC (SSSS.SSSS.SSSS) via ARP three hours ago and cached it — Windows/Linux ARP cache entries commonly live ~4 hours. But PC-A and Server-S haven't exchanged a packet in the last 6 minutes. The switch's MAC/CAM table entry for Server-S's port has a default aging timer of just 300 seconds — it already expired and was removed, silently, with no notification to anyone.

Background

PC-A Sends a Frame

PC-A needs to talk to Server-S again. Its ARP cache is still valid, so no ARP happens — it builds the frame directly addressed to SSSS.SSSS.SSSS and sends it out its access port.

Send

Switch: Source Learning Happens First, Always

Before the switch even considers where to send the frame, it reads the source MAC (PC-A's) and refreshes its own table entry for PC-A's port, resetting that entry's aging timer to zero. Source learning is unconditional — it happens on literally every frame the switch receives, regardless of what the destination lookup finds.

Learn

Destination Lookup — Miss

The switch now looks up the destination MAC, SSSS.SSSS.SSSS, in its table. It's not there — aged out in step 1. From the switch's point of view, this is indistinguishable from a MAC it has genuinely never seen before; there's no "this used to be known" flag.

Miss

Checkpoint — The Decision

Unicast destination + no table entry = unknown unicast. The switch's only correct move is to flood: send the frame out every other port in the VLAN except the one it arrived on. This is the exact same flooding action as a broadcast, but the classification and the reason for it are different — a broadcast is flooded because it's addressed to everyone by design; an unknown unicast is flooded because the switch simply doesn't yet know better.

Checkpoint

Every Port in the VLAN Receives a Copy

Every other host on the VLAN gets the frame at the NIC level. Non-matching hosts drop it in hardware without bothering the CPU or OS. Server-S recognizes its own destination MAC and passes the frame up its stack.

Flood

Server-S Replies

Server-S processes the request and sends a reply — addressed to AAAA.AAAA.AAAA (PC-A's MAC), which it already has correctly, since nothing about PC-A's addressing ever changed.

Switch Re-Learns Server-S

The reply's source MAC (SSSS.SSSS.SSSS) is read on arrival, and the switch writes a fresh entry: Server-S's MAC → its port, aging timer reset to zero. The table is now exactly as populated as it was before the entry expired.

Learn

Destination Lookup for the Reply — Hit

The switch looks up PC-A's MAC — still valid from step 3 — and forwards the reply out that single port. No flooding on the return leg; that only ever happened on the one frame that hit a genuine table miss.

Known Unicast

Steady State

As long as PC-A and Server-S keep exchanging traffic more often than every 300 seconds, both entries stay warm and every frame from here on is a clean, single-port known-unicast forward. The flood in step 6 was a one-off cost of the table having gone cold — not a fault, not an error, just the mechanism working as designed.

Steady

02 How to Explain This in an Interview

Lead with the two-timer distinction. ARP cache (host, hours) vs. MAC table aging (switch, ~300s default) is the single fact that makes this scenario non-obvious — most people assume "if ARP is cached, the switch must still know the path too."
Say "source learning is unconditional" explicitly. It's easy to describe learning as something that only happens on broadcasts/ARP — make clear it happens on every single frame, success or miss.
Don't call it a broadcast storm. A single unknown-unicast flood is normal, self-correcting behavior. A "storm" implies a sustained, repeating flood — usually from a real problem (see gotchas below). Conflating the two under interview pressure is a common, noticeable mistake.
Bring your own example if asked "when does this actually matter." A server that talks to a given client only every few minutes (backup jobs, monitoring polls, batch syncs) will flood on almost every re-contact — worth knowing as a real-world pattern, not just theory.
If pushed further, pivot to the security angle (CAM table overflow / MAC flooding attacks) — it shows you understand this mechanism isn't just a performance curiosity, it's an actual attack surface.

03 Follow-Up / Gotcha Questions

Q What's a MAC flooding / CAM table overflow attack?

A An attacker floods the switch with frames using thousands of fake, random source MACs to fill the finite CAM table. Once it's full, some switches fail open — every subsequent frame becomes an unknown unicast and gets flooded everywhere, letting the attacker passively sniff traffic that should have been switched to a single port. Port security (limiting MACs per port) and DAI/storm control are the standard mitigations.

Q Can you tune the 300-second aging timer, and why would you?

A Yes — mac address-table aging-time on Cisco. Lowering it makes the table adapt faster to topology changes (e.g. after a failover) at the cost of more frequent flooding for quiet hosts; raising it reduces flooding overhead but means stale entries (e.g. a moved device) persist longer.

Q Does STP interact with the aging timer at all?

A Yes — on a topology change, STP triggers switches to flush their MAC tables far faster than the normal 300s aging (historically down to 15s), because a topology change means previously-learned port mappings may now be wrong. This causes a brief burst of unknown-unicast flooding network-wide right after a link failover.

Q Is flooding a security or privacy concern even without an attack?

A Marginally — any host in the VLAN briefly sees a copy of that one flooded frame at the NIC level (though it's discarded in hardware if the MAC doesn't match). It's not something to design around for normal traffic, but it's the underlying reason port mirroring/SPAN and promiscuous-mode sniffing on a shared segment work the way they do.

Q Would a static MAC table entry change any of this?

A Yes — a statically configured MAC-to-port mapping never ages out and is never subject to a flood-on-miss, because there's no "miss" possible. It's occasionally used for critical, rarely-talkative devices, but it doesn't scale and has to be manually maintained if the device ever moves ports.

Q Why doesn't the switch just ask "does anyone have this MAC" the way ARP asks for an IP?

A There's no Layer 2 equivalent of ARP for MAC-to-port discovery — flooding the actual frame to every port and passively learning from whichever host replies (or from any future frame with that MAC as a source) IS the switch's discovery mechanism. It's implicit and reactive rather than an explicit query/response protocol.

04 Quick-Fire Glossary

Term	Meaning
Unknown Unicast	A unicast-destined frame whose MAC isn't currently in the switch's table — handled by flooding
Source Learning	The switch recording a frame's source MAC against the port it arrived on — happens on every frame
MAC / CAM Table Aging	The timer (default 300s on most Cisco platforms) after which an unused entry is removed
ARP Cache Timeout	A separate, host-side timer (commonly ~4h) — independent of, and usually much longer than, MAC aging
MAC Flooding Attack	Deliberately overflowing the CAM table with fake MACs to force fail-open flooding for sniffing
Port Security	A switchport feature limiting the number/identity of MACs allowed to be learned on that port
Broadcast Storm	A sustained, often self-reinforcing flood — usually from a loop, not a single unknown-unicast event
Storm Control	A switchport feature that rate-limits broadcast/multicast/unknown-unicast traffic to contain storms
Static MAC Entry	A manually configured, non-aging MAC-to-port mapping
STP Topology Change	An event that triggers accelerated MAC table flushing network-wide after a link state change