A switch ships with an empty table and no configuration that says where anything is. Plug a laptop into a different port and it keeps working, because the switch did not know where the laptop was in the first place — it learned.
That single mechanism explains flooding, broadcast storms, MAC table exhaustion, and most of the "the network is slow but only in this one room" tickets you will ever open.
A switch is a learning bridge
Ethernet frames carry a source MAC and a destination MAC, both 48 bits. When a frame arrives on a port, the switch does two things in order:
- Learn. It records the source MAC and the port it arrived on, with a timestamp.
- Forward. It looks up the destination MAC and sends the frame out the matching port.
If the destination is not in the table, the switch does the only safe thing available: it floods the frame out every port in the same VLAN except the one it arrived on. That is called unknown unicast flooding, and it is normal. One reply is enough to teach the switch where the destination lives.
| Destination | Behavior |
|---|---|
| Known unicast | Forward out one port |
| Unknown unicast | Flood within the VLAN |
| Broadcast (ff:ff:ff:ff:ff:ff) | Flood within the VLAN |
| Multicast | Flood unless snooping is configured |
Aging keeps the table honest
Every entry has an age, typically 300 seconds. If the switch sees no traffic from that MAC, the entry expires. Without aging, a table would fill with devices that moved, were replaced, or never existed again, and every lookup would be slower and every move would break.
Aging is also why a device that has been silent for ten minutes gets flooded on its next packet. The first frame is broadcast to the VLAN; the reply repopulates the table. Users experience nothing.
The table is per VLAN
A MAC address learned in VLAN 104 is not known in VLAN 106. The switch keeps a separate forwarding table per VLAN, which is one of the practical reasons a VLAN behaves like its own small network.
Worked example
A closet switch has four devices. After a minute of traffic the table looks like this:
| MAC | Port | VLAN | Age |
|---|---|---|---|
3c:52:82:1a:04:11 |
5 | 104 | 12 s |
3c:52:82:1a:04:22 |
6 | 104 | 41 s |
b8:27:eb:77:10:03 |
12 | 106 | 3 s |
00:1c:42:9f:2e:81 |
24 | 108 | 288 s |
A frame arrives on port 5 destined for 3c:52:82:1a:04:22. The switch finds it on port 6 and forwards
it there — no other port sees the frame. If the destination had been 3c:52:82:1a:04:99, unknown, the
frame would go out ports 1-4 and 6-48 (in VLAN 104 only) and the reply would teach the table.
That is the entire forwarding model. Everything else is bookkeeping around it.
Where the model breaks
Loops. Ethernet has no TTL. A flooded frame in a loop circulates forever, and each pass is multiplied by every switch that floods it. A single cable between two access switches, plugged in twice, can saturate a campus in seconds. Spanning Tree exists solely to prevent this, which is the next article.
Table size. Switches have a finite MAC table, from a few thousand entries on access gear to hundreds of thousands on core hardware. When it fills — a virtualization host with thousands of VMs, a loop, or a MAC flooding attack — the switch evicts entries and starts flooding known unicast too. The symptom is a network that works but is inexplicably slow, with no errors anywhere.
Duplicate MACs. Two devices claiming the same MAC, usually cloned VMs or a misconfigured redundancy protocol, cause the table to flap between ports. Frames go to the wrong host half the time.
A full MAC table fails open, not closed
When a switch runs out of table space it does not drop traffic. It floods. That is why MAC table exhaustion looks like a performance problem rather than an outage, and why it is easy to miss for weeks.
What breaks in production
- A loop with no Spanning Tree. Broadcast storm, all ports at 100% utilization, phones and APs reboot from the load. The fix is physical, and the lesson is BPDU guard on every edge port.
- Move a device, lose a minute. The old entry has to age out or be overwritten by the new port's traffic. Usually invisible; occasionally a printer keeps answering on its old port until the entry expires.
- MAC flapping alarms. The same MAC appearing on two ports in quick succession almost always means a loop, a duplicate address, or a trunk misconfiguration — not a broken NIC.
- Unicast flooding after a topology change. The table is rebuilt by traffic, so a quiet VLAN floods until devices speak. On a large VLAN that is a measurable burst.
Checklist
- Every access port has BPDU guard and an appropriate MAC limit.
- You know your switch's MAC table size and can read the current count.
- Unknown unicast flooding is expected, not a fault — but sustained high flooding is a symptom.
- Aging timers are left at vendor defaults unless you have a specific reason.
- A MAC appearing on two ports is treated as a loop until proven otherwise.
Next
Loops are the failure mode that takes down a campus, and one protocol exists to stop them. Continue with Spanning Tree Without Fear.