What is a MAC flooding attack on an Ethernet switch, what does the attacker gain, and how do per-port MAC limits stop it?

## The weakness: learning is unauthenticated and the table is finite An Ethernet switch learns where hosts are by recording the **source MAC address** of every arriving frame against its arrival port. Nothing checks that the address is genuine, and the table that holds these entries lives in fixed-size hardware memory. Frames whose destination is not in the table (**unknown unicast**) are **flooded** out every port in the VLAN except the arrival port. Combine the three facts and an attack follows. ## How the attack works 1. The attacker, on an ordinary access port, transmits a high rate of frames, each with a different random **source** MAC address. 2. The switch dutifully learns each forged address against the attacker's port. 3. The table fills. The switch can no longer add entries; RFC 7348 (VXLAN), describing table overflow in general, says that "the switch may stop learning new addresses until idle entries age out, leading to significant flooding of subsequent unknown destination frames". 4. Legitimate hosts whose entries age out, and new hosts that join, cannot be relearned. Frames to them are now unknown unicast and are flooded, including out the attacker's port. 5. The attacker captures that flooded traffic, or simply benefits from the load it places on every port. Because the forged frames also have unknown destinations, they are themselves flooded, across uplinks to the other switches in the same VLAN, which learn the forged sources too. One port can exhaust the tables of every switch in its VLAN. ## What the attacker actually gains, stated precisely | Claim | Reality | |---|---| | "The switch becomes a hub" | It still forwards to every address it already knows; only unknown destinations flood, and each port is still its own collision domain. | | "The attacker sees all traffic" | Only traffic to addresses that are not in the table, and only within the attacker's own VLAN. | | "It is permanent" | Entries age out; the effect lasts as long as the attacker keeps transmitting. | | "Encryption is bypassed" | Flooded frames carrying TLS or another encrypted protocol stay encrypted; cleartext protocols are what leak. | So the realistic gains are **passive capture of unencrypted traffic in one VLAN** and **degraded performance** for everyone on it. It is different from ARP spoofing, which lies about IP-to-MAC mappings to redirect traffic rather than exhausting the switch's table. ## Detecting it - RFC 4188's Bridge MIB counter `dot1dTpLearnedEntryDiscards` counts entries that "have been or would have been learned, but have been discarded due to a lack of storage space"; the MIB itself says that if it keeps increasing, the table is regularly full. - One access port suddenly holding thousands of learned addresses. - A sharp rise in flooded unicast on ports that normally see little. ## Mitigation: per-port MAC limits The primary defence is to cap how many source addresses each access port may teach the switch. The feature is widely implemented and usually sold as **port security**, an implementation feature rather than a protocol mechanism. Its knobs are: - **the maximum** number of learned addresses on the port; - **the violation action** when an extra source appears: drop frames from the new source, drop and log, or disable the port; - **pinned addresses**, statically configured or remembered from the first ones learned. With a limit, the attacker can occupy only a handful of entries, and the table never fills. Supporting measures: 1. **Port-based authentication** (802.1X) decides whether a device may use the port at all, which addresses the attacker getting a port in the first place. 2. **Smaller VLANs** limit how far the forged addresses and the flooded traffic spread. 3. **Encryption** of application traffic makes whatever is captured far less useful. 4. A **shorter ageing time** does not prevent overflow, but RFC 4188 notes that a large ageing value may simplify forwarding-table overflow attacks, because forged entries persist longer. ## Getting the limit right A limit that is too tight causes self-inflicted outages, and a disable-port violation action turns every misjudgement into a support call: - a port feeding a **hypervisor** carries one MAC per virtual machine; - a desk phone with a PC behind it presents two or more addresses; - docking stations, USB adapters and clients that use **randomised MAC addresses** can present a new address each time they reconnect, which a limit with pinned addresses then rejects. A common pattern is a small limit with "drop and log" on user ports, a larger limit on known virtualisation hosts, and alerting on violations rather than shutting ports automatically.