When a switch MAC address table fills, the switch keeps forwarding traffic for MACs it already knows, but it stops learning new ones — so any frame to an unknown destination is flooded to every port. The result is not an outage but broadcast-like flooding that eats bandwidth and CPU.
A full MAC table does not drop the network — it stops learning new MACs and floods unknown unicast to all ports.
The symptom is sluggishness (ping jitter, dropped video frames), not a hard link failure, because hardware forwarding of known MACs stays at line rate.
Fix it at the root: kill loops with RSTP/ERPS, shrink broadcast domains with VLANs, and size the table to your endpoint count.
A Layer 2 industrial switch forwards at the data-link layer using this table — formally the FDB (forwarding database), implemented in CAM/TCAM memory that can search in parallel. Learning is straightforward: on receiving a frame it writes "source MAC + ingress port" into the table; on forwarding it looks up the destination MAC's port, and if found sends it unicast, if not it floods.
Note: Every entry carries an aging timer, default 300 seconds per IEEE 802.1D — if that MAC is not seen again within the window, the entry is cleared to free room for new endpoints.
When the table is full, the switch still forwards for MACs already in it — that traffic is unaffected. The trouble starts with "new faces": a terminal not in the table sends a frame, the switch finds no destination MAC, and by rule floods it to every port except the ingress. The longer the table stays full, the more "unknown unicast" gets flooded, and traffic that should have been point-to-point turns into network-wide broadcast.
This is the ethernet switch vs hub distinction in practice: a hub repeats every frame everywhere, while a switch only floods what it cannot place. A full table simply forces the switch back toward hub-like behavior.
Warning: A broadcast storm is unrelated to a full table (broadcast frames always flood), but a full table stacks "unicast forced to flood" on top — making a bad situation worse. Many sites blame "not enough bandwidth" for the slowdown when the real cause is the MAC table.
Access-layer industrial switches commonly carry 8K–16K entries, which sounds like plenty — until a loop or an attack fills them in minutes.
| Tier | MAC table size | Typical location | Default aging | Behavior when full |
|---|---|---|---|---|
| Unmanaged / SOHO | 1K–4K | Desktop, small office | 300s | Flood |
| Access-layer industrial | 8K–16K | Workshop access, PoE to endpoints | 300s | Flood + stop learning new MACs |
| L3 / aggregation | 32K–64K | Core, inter-VLAN routing | 300s | Flood |
| Core / data center | 128K–1M | Backbone, large L2 | 300s | Flood |
An access-layer industrial Ethernet switch rated at 8K looks sufficient, yet a loop or attack can fill it within the 300-second aging window; after that, every new endpoint's traffic floods.
Aging time is "how long since last talk before forgetting this MAC." 300 seconds is the factory default; most managed network switches let you change it from 10 seconds up to millions of seconds. Shorten aging (say 60s) and terminals that move update fast — but active terminals get flushed and relearned constantly, the table keeps churning, and unknown unicast rises. Lengthen it (say 1 hour) and "zombie" addresses pile up and crowd the table, making a real fill harder to recover from.
Tip: Aging is not "smaller is better." Set it by endpoint mobility: a fixed-seat factory can use a longer timer; a site with roaming phones and APs benefits from a shorter one.
Cisco: show mac address-table count and show mac address-table aging-time. Huawei: display mac-address and display mac-address aging-time. Linux bridge: bridge fdb show. Three signs together confirm it:
a. Log alarms like "MAC table full."
b. "Unknown unicast / flood" counters climbing steadily.
c. Switch CPU oddly high (some models push flooded frames to the CPU for software handling).
Rayin's industrial Ethernet switches expose the same table counters and alarms, so check the counts before concluding — far faster than blind testing.
A common myth: a full table slows the switching chip's forwarding. Hardware forwarding of traffic already in the table is essentially zero-cost — the lookup is at line rate. The real slowdown is the chain reaction from flooding: unknown unicast saturates the uplink, every device in the broadcast domain must process the stray frames, and on some models flooded frames also hit the CPU.
Note: So a full table typically shows up as "some services lag, ping jitters, video frames drop" — not "all ports halved in speed." That is why industrial sites prefer Rayin's large-table models over skimping on access-layer capacity: the saved cost never covers one site-wide troubleshooting session.
Loop / self-loop. An extra cable between two switches with no STP/RSTP/ERPS open leaves broadcast frames circling; MACs get learned to different ports repeatedly and the table fills within the 300s window. In a 64-camera workshop, a self-loop on one access switch quickly shows as stutter in the surveillance VLAN.
MAC flapping. Virtualization, frequent phone roaming, or misconfigured NIC bonding bounces one MAC across ports, churning table entries.
Deliberate attack. A MAC-flood attack sprays frames with fake source MACs to fill the table and force all later traffic to flood — convenient for sniffing.
Too many static MAC binds. Static binding for key devices is stable, but static entries also consume the table; over-binding crowds out dynamic space.
Kill the loop first. Enable RSTP/ERPS on the access layer; don't leave spare cables dangling.
Shrink broadcast domains. Cut VLANs and subnets by service; the MACs one switch must track drop immediately.
Enable IGMP Snooping. Keep multicast from riding the flood too.
Static binds + port security. Limit how many MACs a port may learn — blocks attacks and controls table size.
Upgrade if still short. Move access from 8K to 16K, core to 64K+, and the headroom appears. When access-layer industrial PoE switches power cameras, align table capacity with endpoint count.
Is the MAC address table the same as the ARP table?
No. The MAC table is for Layer 2 forwarding (MAC to port); the ARP table is for Layer 3 (IP to MAC). A Layer 3 switch has both, each serving its own layer.
Does a full table drop packets?
Traffic to known MACs forwards normally and is not dropped. Unknown unicast that floods generally is not dropped either — it consumes bandwidth; only when the uplink or backplane is saturated by flooding and congestion sets in do queued frames get dropped.
What happens if I set aging time to 0?
On many devices "0" means no aging (permanent retention) — entries only grow, which most easily fills the table over time. Do not set it to 0 casually.
Do home mini-switches need to worry about this?
Basically no. A home has a dozen endpoints and a table of thousands — it never fills. This topic matters for enterprise, industrial, and data-center networks with many endpoints, many VLANs, and possible attacks.
A full MAC address table will not cut the network outright; the cost is unknown-unicast flooding that drags down bandwidth and CPU, and the fastest diagnosis is to read the table counters and alarms first. Size the table to your endpoint count when choosing gear — far cheaper than firefighting afterward. For managed industrial switches sized to your endpoint scale, see Rayin's industrial switch solutions.
Customer Manager at Shenzhen Rayin Technology Co., Ltd.
