MAC Flooding Attack: How It Works and How to Stop It

Most IT teams assume a switched network is inherently more private than a hub, since a switch is supposed to send traffic only to the port where the destination device lives. A MAC flooding attack deliberately exhausts a switch’s MAC address table by sending frames with numerous spoofed source MAC addresses. Once the table is […]

A single unmanaged switch port can turn an entire network segment into a shared listening device in under a minute.

Most IT teams assume a switched network is inherently more private than a hub, since a switch is supposed to send traffic only to the port where the destination device lives.

A MAC flooding attack deliberately exhausts a switch’s MAC address table by sending frames with numerous spoofed source MAC addresses. Once the table is full, the switch may be unable to learn legitimate MAC addresses. Frames destined for MAC addresses that are not in the table are then treated as unknown unicast traffic and flooded to all forwarding ports in the relevant VLAN.This article covers:

  • How a MAC flooding attack works at the switch-hardware level
  • The tool attackers actually use to pull it off
  • The port security and authentication controls that stop it
  • The difference between MAC flooding and the closely named MAC spoofing attack

What Is a MAC Flooding Attack?

A MAC flooding attack is a Layer 2 exploit that floods an Ethernet switch with forged source MAC addresses until the switch’s address table runs out of room. Once that happens, the switch broadcasts frames to many ports instead of only the intended one.

MAC flooding targets the switch’s memory, not any individual device or user account.

Every Ethernet switch keeps a table that maps each MAC address it has seen to the physical port that address arrived on. This is commonly called a content addressable memory (CAM) table or MAC address table. The switch builds it by watching the source address of every incoming frame.

That mapping is what lets a switch send unicast traffic to one port instead of every port, which is the entire reason switches replaced hubs in enterprise networks.

The CAM table is not infinite. Commonly cited estimates put desktop-class switches at as few as 1,000 to 2,000 entries and typical enterprise switches somewhere between 5,000 and 16,000, though exact capacity varies by model and should be checked against the vendor datasheet.

A MAC address itself is a 48-bit identifier, so the pool of addresses an attacker can forge is effectively unlimited compared to any table size a switch can hold in memory.

How a MAC Flooding Attack Works

The mechanics are simple, which is part of why the attack has stayed relevant since switched Ethernet became standard.

An attacker on any port of the target switch, physical or virtual, sends a rapid stream of frames each carrying a different, often randomly generated, source MAC address.

  1. Frame generation: The attacker’s machine, connected to any port on the target switch, generates thousands of Ethernet frames with unique, usually fake, source MAC addresses.
  2. Table exhaustion: The switch dutifully learns each new source address and writes it into the CAM table, evicting older or legitimate entries once capacity runs out.
  3. Fail-open behavior: Once the table is full and the switch cannot resolve where to send unicast traffic for the addresses it just displaced, many switches revert to broadcasting frames from every port on the same virtual local area network (VLAN), the same behavior a hub uses by default.
  4. Traffic capture: The attacker’s network interface, now receiving copies of frames meant for other hosts, runs a packet sniffer to pull unencrypted credentials, session data, or other traffic from the flood.

That fail-open behavior is well documented in switch and tool vendor guidance.

Info: Macof, one of the standard tools used to run this attack, is described in its own documentation as flooding “the local network with random MAC addresses (causing some switches to fail open in repeating mode, facilitating sniffing)”.

The captured traffic is a textbook case of what the MITRE ATT&CK framework catalogs as network sniffing, where an adversary places an interface into a position to passively collect credentials and other data crossing the wire.

The Macof Tool

Macof is a command-line utility, part of the older dsniff suite, built specifically to flood a switch with forged MAC addresses. One published lab test used macof.py, a reimplementation of macof, against an emulated switch with an 8,192-entry table. In testing, the tool very nearly filled it the table completely, reaching 8,188 entries in roughly 2.7 seconds.

The precise timing depends on the hardware, but the order of magnitude is the point: this is a seconds-to-minutes attack, not an hours-long one.

Under normal conditions tables like this rarely fill up, because they are sized for the expected device count and stale entries age out on a timer rather than accumulating indefinitely.

A CAM table that takes seconds to fill is a CAM table an attacker only needs a few minutes of physical or logical access to exploit.

MAC Flooding vs. MAC Spoofing

The names sound alike, and both attacks target the MAC address layer, but they work in opposite directions and require different defenses.

MAC flooding is a volume attack against the switch’s memory: it succeeds by generating as many fake addresses as possible to break the table.

MAC spoofing is a precision attack against identity: it succeeds by copying one specific, legitimate address to impersonate a trusted device and evade MAC-based filtering or access controls.

Here’s an illustration of what it looks like.

Diagram showing MAC spoofing

The table below breaks down the two attacks side by side.

Attribute MAC Flooding MAC Spoofing
Target The switch’s CAM table A specific device’s identity
Method Thousands of forged addresses One copied, legitimate address
Goal Force traffic flooding to all forwarding ports in the relevant VLAN Evade MAC filtering or access rules
Primary Defense Port security, 802.1X Certificate-based authentication

Put another way, flooding wants the switch confused about everything. MAC spoofing wants the switch, or the access control system behind it, confidently wrong about one thing.

A network can be hardened against one and remain fully exposed to the other, which is why treating them as the same problem is a mistake.

MAC flooding also belongs to a broader family of switch-level exploits. It shares that ground with attacks like double tagging and switch spoofing, which manipulate VLAN trunking rather than address tables.

Watch the video below to learn the importance of PKI in modern cybersecurity.

Why MAC Flooding Still Matters

A successful flood does not hand an attacker credentials directly. It hands them visibility they should not have.

When MAC-table exhaustion causes unknown-unicast flooding, an attacker with a sniffer on an affected VLAN may capture traffic that would normally be forwarded only to its intended destination. Unencrypted traffic could then be exposed, while encrypted traffic remains protected from passive inspection by the attacker.

That visibility is frequently a stepping stone rather than the end goal.

An attacker who captures session tokens or credentials from a flooded segment can pivot into a full adversary-in-the-middle position, intercepting and manipulating traffic between two hosts rather than just observing it.

A closely related Layer 2 technique, address resolution protocol (ARP) spoofing, achieves a similar interception outcome through forged ARP replies rather than table exhaustion, and it deserves its own treatment.

Danger: Legacy switched networks that rely purely on physical port access as their security boundary are the most exposed. Any device that can plug into an access port, a conference room jack, an unused cubicle drop, an exposed patch panel, can attempt this attack with no credentials at all.

Detecting and Preventing MAC Flooding

The standard defense has not changed much in two decades, because the attack itself has not changed much. It caps how many MAC addresses a single port is allowed to learn, which directly denies the attacker the table space they need.

Port security, a feature available on most managed switches, lets an administrator set a maximum number of MAC addresses permitted on a given port and define what happens when that limit is exceeded.

On Cisco IOS switches, this is configured with a port security violation mode set to one of three behaviors:

  1. Protect, which silently drops traffic from any address beyond the limit
  2. Restrict, which does the same but also logs the violation
  3. Shutdown, the default, which disables the port entirely until an administrator manually re-enables it

Beyond basic port limits, a few additional controls close the remaining gaps:

  • Static or sticky MAC binding: Locking a port to a specific, known MAC address removes any ambiguity about what device should be learned there.
  • Disabling unused ports: A port that is administratively shut down cannot be flooded, regardless of what plugs into it.
  • Monitoring table utilization: Alerting on unusual growth in MAC table size, rather than waiting for an overflow, catches the attack while it is still in progress.
  • Segmenting flat networks: Smaller VLANs limit the blast radius of a successful flood to a narrower set of hosts.

Port security is effective, but it is a hardware-layer control tied to physical switch ports. It says nothing about who or what the device actually is, only how many addresses a port will tolerate.

That gap is why port security alone is not a complete answer for modern, mixed-device networks.

Port Security Is Not Identity

A switch enforcing a strict MAC address limit still cannot answer a more basic question: is the device connecting to this port authorized to be on this network at all?

MAC addresses are trivial to view and copy, so a port security policy built purely around counting or matching addresses can be satisfied by an attacker who has simply spoofed one legitimate-looking address instead of flooding thousands of fake ones.

IEEE 802.1X closes that gap by moving the decision from “how many addresses has this port seen” to “has this specific user or device proven who it is.”

The 802.1X-2020 standard defines port-based network access control that restricts a LAN port to authenticated and authorized devices before any meaningful traffic is allowed to pass.

Watch the video below for a quick refresher on IEEE 802.1X and why it exists.

A switch running 802.1X will not forward traffic from an unauthenticated device even if that device’s MAC address never touches a port security limit, which removes the blind spot that a purely count-based defense leaves open.

Combining port security with 802.1X authentication addresses both halves of the problem:

  1. The switch hardware limits how much table space any one port can consume.
  2. The authentication layer verifies that whatever occupies that space is trusted.

Many 802.1X deployments authenticate that trust with digital certificates issued through Public Key Infrastructure (PKI) rather than a password.

How Cloud RADIUS and Dynamic PKI Strengthen Switch-Level Defenses

Port security and 802.1X reduce the practical value of a MAC flooding attack, but both controls are only as strong as the authentication credentials behind them.

A network still relying on shared passwords or basic MAC address allowlists for 802.1X authentication reintroduces the exact weakness port security was supposed to close: an address or password that can be copied, guessed, or phished.

The SecureW2 JoinNow Cloud RADIUS platform authenticates every device against a real identity drawn directly from the identity provider rather than trusting a static credential or a MAC address on its own.

Paired with JoinNow Dynamic PKI, which issues unique, non-exportable digital certificates to each device, the network can enforce 802.1X authentication with no shared password or MAC address for an attacker to copy or spoof.

A flooded, fail-open switch segment stops being useful to an attacker who still can’t authenticate onto it.

Schedule a demo to see how Cloud RADIUS and Dynamic PKI move switch security beyond address counting and into verified device identity.

Key Takeaways
  • A MAC flooding attack overwhelms a switch’s address table with fake media access control (MAC) entries, causing frames to be sent to all forwarding ports in the relevant VLAN.
  • The attack exhausts a finite content addressable memory (CAM) table, usually with the macof tool, until the switch fails open.
  • MAC flooding differs from MAC spoofing. Flooding breaks switch memory, while spoofing impersonates one address to evade filtering.

Frequently Asked Questions

Does VLAN segmentation stop a MAC flooding attack?

No, but it can limit the attack's scope. Unknown-unicast flooding occurs within the affected VLAN, so VLAN segmentation can limit which devices may receive or capture flooded traffic. It does not, however, prevent an attacker from attempting to exhaust the MAC address table.

Port security can help prevent MAC-table exhaustion by limiting the number of MAC addresses that an untrusted port can learn. VLAN segmentation provides an additional layer of containment by reducing the potential blast radius if flooding occurs.

Can modern switches still be MAC flooded?

Yes. Modern switches still maintain a finite MAC address table, and that table can still be exhausted if port security or an equivalent limiting control is not configured.

Larger enterprise switches simply take marginally longer to fill than older or lower-end hardware, since capacity is commonly cited as roughly 1,000 entries on desktop-class switches up to 16,000 or more on enterprise models.

How would I know if my switch is being flooded?

Watch for a sudden spike in MAC address table utilization, a jump in broadcast or flooded unicast traffic on a segment that normally has none, or port security violation logs on switches where the feature is enabled.

A switch that begins behaving like a hub, with hosts suddenly seeing traffic that was never destined for them, is the clearest symptom of a table that has already overflowed.