MAC Flooding Attacks: Technical Deep Dive and Prevention Strategies

MAC flooding is a Layer 2 network attack that deliberately exhausts the CAM (Content Addressable Memory) table of an Ethernet switch by injecting thousands of frames with spoofed, randomized source MAC addresses. Once the CAM table reaches capacity, the switch degrades into hub-like behavior — broadcasting all incoming frames out of every port — which exposes the entire broadcast domain to passive interception and active manipulation.

This attack is not theoretical. It is trivially executable with tools like `macof` (part of the `dsniff` suite) and can saturate a typical 8,000-entry CAM table in under 70 seconds on a gigabit link. Understanding the mechanics, the failure modes, and the layered countermeasures is essential for any network engineer responsible for infrastructure integrity.

How the CAM Table Works and Why It Fails

Every managed Ethernet switch maintains a CAM table that maps MAC addresses to specific physical ports. When a frame arrives, the switch performs a lookup: if the destination MAC is in the table, the frame is forwarded only to the corresponding port (unicast forwarding). If the MAC is unknown, the switch floods the frame to all ports in the same VLAN — this is normal, expected behavior for unknown unicast traffic.

The CAM table has a finite size, typically ranging from 8,000 entries on access-layer switches to 128,000+ entries on enterprise core switches. Entries age out after an inactivity timeout (default: 300 seconds on most Cisco IOS platforms). An attacker exploits this by injecting frames faster than entries age out, keeping the table perpetually full with garbage entries.

The Fail-Open Failure Mode

When the CAM table is full, the switch cannot store new legitimate MAC-to-port mappings. Every frame with a destination MAC not already in the table gets flooded to all ports in the VLAN. This is called fail-open behavior — the switch prioritizes connectivity over security, which is the opposite of what a security-conscious design requires.

The consequences are immediate and severe:

• Passive sniffing: Any host on the segment can capture traffic intended for other hosts using a promiscuous-mode NIC and a packet analyzer like Wireshark or tcpdump.
• Man-in-the-middle (MITM) attacks: With full traffic visibility, an attacker can combine MAC flooding with ARP poisoning to intercept, modify, and relay traffic between two communicating hosts without either party detecting the interception.
• Credential harvesting: Unencrypted protocols (Telnet, FTP, HTTP Basic Auth, SMTP without STARTTLS) expose credentials directly. Even with TLS, metadata and session patterns leak valuable reconnaissance data.
• Network performance degradation: The sheer volume of flooded frames consumes port bandwidth and CPU cycles on all connected hosts, effectively constituting a denial-of-service condition.

Attack Execution: What It Actually Looks Like

A realistic attack using `macof` on a Linux host:

“`bash

macof floods the network with random source MACs

-i specifies the interface, -n specifies the number of packets

macof -i eth0 -n 100000

“`

Each packet has a randomly generated source MAC and destination MAC, forcing the switch to attempt a new CAM entry for every frame. On a 100 Mbps link, `macof` can generate approximately 155,000 packets per second — far exceeding the CAM table replenishment rate.

MAC Flooding vs. ARP Spoofing vs. ARP Poisoning

These three attacks are frequently conflated but operate at different layers and through different mechanisms. Understanding the distinction is critical for selecting the right countermeasure.

Prevention Strategy 1: Port Security on Managed Switches

Port security is the most direct and effective first-line defense against MAC flooding. It operates at the port level, enforcing a hard limit on the number of MAC addresses that can be learned on any given interface.

Core Configuration Parameters

Maximum MAC addresses: Set this to the minimum number required for legitimate operation. A port connected to a single workstation should allow exactly one MAC address. A port connected to an IP phone with a downstream PC (a common daisy-chain topology) should allow two.

Violation modes determine what happens when the limit is exceeded:

• `protect` — Drops frames from unknown MACs silently. No logging, no port shutdown. Useful for environments where false positives are a concern, but provides no visibility.
• `restrict` — Drops frames from unknown MACs and increments a violation counter, generating a syslog message. The port remains operational.
• `shutdown` — Immediately places the port in err-disabled state and generates a syslog alert. This is the most secure option but requires administrative intervention (or auto-recovery) to restore the port.

Sticky MAC addressing (`mac-address sticky`) instructs the switch to dynamically learn MAC addresses and write them directly into the running configuration as static entries. This eliminates the need to manually pre-populate MAC address tables while still binding specific devices to specific ports.

Complete Cisco IOS Configuration Example

“`

interface GigabitEthernet0/1

switchport mode access

switchport access vlan 10

switchport port-security

switchport port-security maximum 2

switchport port-security violation shutdown

switchport port-security mac-address sticky

spanning-tree portfast

“`

To verify port security status:

“`

show port-security interface GigabitEthernet0/1

show port-security address

“`

To recover an err-disabled port after a violation:

“`

interface GigabitEthernet0/1

shutdown

no shutdown

“`

For automated recovery, configure `errdisable recovery cause psecure-violation` with an appropriate interval.

Critical Pitfall: Trunk Ports and Uplinks

Never apply port security to trunk ports or switch uplinks. These ports legitimately carry traffic from hundreds of MAC addresses across multiple VLANs. Applying a MAC limit to a trunk port will cause catastrophic connectivity failures. Port security is exclusively an access-port feature.

Prevention Strategy 2: VLAN Segmentation and Private VLANs

VLAN segmentation limits the blast radius of a MAC flooding attack by constraining the broadcast domain. If an attacker floods a CAM table, only the VLAN containing the attacker's port enters fail-open mode — other VLANs continue operating normally.

Standard VLAN Segmentation

Segment your network by function and sensitivity level:

• Management VLAN: Network devices, out-of-band management interfaces, IPMI/iDRAC/iLO access
• Server VLAN: Production servers, databases, application tiers
• User VLAN: Workstations, printers, general-purpose endpoints
• DMZ VLAN: Internet-facing services, reverse proxies, mail gateways
• Voice VLAN: VoIP phones (also reduces QoS complexity)

Private VLANs (PVLANs)

Private VLANs extend isolation within a single VLAN by defining port roles:

• Promiscuous ports: Can communicate with all ports in the PVLAN (typically the uplink or gateway)
• Isolated ports: Can only communicate with promiscuous ports — not with other isolated ports
• Community ports: Can communicate with other ports in the same community and with promiscuous ports

PVLANs are particularly valuable in hosting environments where multiple tenants share the same physical infrastructure. Even if one tenant's port is compromised, isolated port behavior prevents lateral traffic capture. If you are running workloads on a VPS Hosting platform, understanding how the underlying switching fabric implements VLAN isolation is directly relevant to your threat model.

Prevention Strategy 3: DHCP Snooping

DHCP snooping builds a binding table that maps MAC addresses to IP addresses, VLANs, and switch ports. This binding table is not just useful for DHCP-specific attacks — it serves as the authoritative source of truth for Dynamic ARP Inspection and IP Source Guard.

Configuration Logic

Ports are classified as trusted (connected to legitimate DHCP servers or uplinks) or untrusted (connected to clients). DHCP responses arriving on untrusted ports are dropped.

“`

ip dhcp snooping

ip dhcp snooping vlan 10,20,30

interface GigabitEthernet0/1

ip dhcp snooping limit rate 15

! Untrusted by default — no additional command needed

interface GigabitEthernet0/24

ip dhcp snooping trust

! Uplink or DHCP server port

“`

The `ip dhcp snooping limit rate 15` command limits DHCP packets to 15 per second on untrusted ports, preventing DHCP starvation attacks that can accompany MAC flooding campaigns.

The DHCP Snooping Binding Table

“`

show ip dhcp snooping binding

“`

This table output shows MAC address, IP address, lease time, VLAN, and interface — exactly the data DAI uses for validation.

Prevention Strategy 4: Dynamic ARP Inspection (DAI)

DAI validates ARP packets against the DHCP snooping binding table. Any ARP packet claiming a MAC-to-IP mapping that does not match the binding table is dropped. This directly counters the ARP poisoning that attackers typically layer on top of MAC flooding.

“`

ip arp inspection vlan 10,20,30

interface GigabitEthernet0/24

ip arp inspection trust

! Uplink — trusted for ARP

interface GigabitEthernet0/1

ip arp inspection limit rate 100

! Limit ARP rate on access ports

“`

DAI also logs dropped packets, providing forensic evidence of attack attempts:

“`

show ip arp inspection statistics vlan 10

“`

IP Source Guard: The Final Layer

IP Source Guard extends the DHCP snooping binding table to filter IP packets. Only packets with a source IP matching the binding table entry for that port are forwarded. This prevents IP spoofing even after a successful MAC flooding event.

“`

interface GigabitEthernet0/1

ip verify source

“`

The combination of port security + DHCP snooping + DAI + IP Source Guard creates a defense-in-depth stack that addresses MAC flooding, ARP spoofing, DHCP starvation, and IP spoofing simultaneously.

Prevention Strategy 5: 802.1X Network Access Control

IEEE 802.1X provides port-based network access control by requiring authentication before a port is allowed to pass traffic. An unauthenticated device — including an attacker's machine injecting MAC flooding packets — is placed in an unauthorized state and cannot communicate with the network.

The 802.1X architecture involves three components:

• Supplicant: The client device (workstation, server)
• Authenticator: The switch port
• Authentication server: A RADIUS server (FreeRADIUS, Cisco ISE, Microsoft NPS)

Until the supplicant successfully authenticates via EAP (Extensible Authentication Protocol), the port only passes EAPOL (EAP over LAN) frames. MAC flooding from an unauthenticated port is impossible because the port has no data-plane access.

“`

aaa new-model

aaa authentication dot1x default group radius

dot1x system-auth-control

interface GigabitEthernet0/1

authentication port-control auto

dot1x pae authenticator

“`

802.1X is the strongest preventive control available for access-layer security, but it requires a RADIUS infrastructure and supplicant configuration on all endpoints — a significant operational investment.

Prevention Strategy 6: Network Monitoring and Anomaly Detection

No preventive control is infallible. Continuous monitoring provides the detection capability needed to identify attacks that bypass or precede preventive measures.

Indicators of MAC Flooding

• Rapid increase in the number of MAC addresses learned on a single port
• CAM table utilization approaching 80-90% capacity
• Spike in broadcast traffic volume across a VLAN
• Increase in unknown unicast flooding events
• CPU utilization spikes on switches (due to flooding processing)

Monitoring Tools and Techniques

SNMP polling: Query `dot1dTpFdbTable` (RFC 1493) or `dot1qFdbTable` (RFC 2674) to track CAM table size over time. Alert when entries exceed a defined threshold.

NetFlow/sFlow analysis: Flow data reveals anomalous traffic patterns — a single source generating thousands of unique source MAC addresses is a clear indicator.

Intrusion Detection Systems: Snort and Suricata have rules for detecting MAC flooding patterns. Zeek (formerly Bro) can be configured to alert on rapid MAC address churn.

Wireshark/tshark for forensics: When investigating a suspected attack, capture on a mirror/SPAN port and filter for unique source MACs:

“`bash

tshark -i eth0 -T fields -e eth.src | sort | uniq -c | sort -rn | head -20

“`

A legitimate host generates a handful of unique source MACs (typically one). An attacker running `macof` generates thousands per second.

SPAN/RSPAN for Traffic Analysis

Configure a SPAN (Switched Port Analyzer) session to mirror traffic to a monitoring host:

“`

monitor session 1 source vlan 10

monitor session 1 destination interface GigabitEthernet0/48

“`

This allows a dedicated IDS/IPS or packet capture appliance to analyze all VLAN 10 traffic without disrupting production forwarding.

Hardware Considerations: CAM Table Size and Switch Selection

Upgrading to switches with larger CAM tables raises the bar for attackers but is not a substitute for the controls described above. A determined attacker with sufficient bandwidth can flood any finite table.

For production workloads — particularly those running on Dedicated Servers connected to enterprise switching infrastructure — the switch tier directly impacts your exposure window during an active attack.

Securing Hosted and Cloud Environments

MAC flooding is a local-segment attack. In a shared hosting or colocation environment, the threat model shifts: a compromised or malicious tenant on the same physical switch fabric can target other tenants.

For environments where you control the hypervisor or virtual switch (Open vSwitch, VMware vSwitch), equivalent controls exist:

Open vSwitch port security:

“`bash

ovs-vsctl set port <port-name> other_config:rstp-enable=true

ovs-vsctl set Interface <port-name> type=internal

Limit MAC learning via OpenFlow rules

“`

VMware vSwitch: Enable "MAC Address Changes: Reject" and "Forged Transmits: Reject" in the vSwitch security policy. This prevents a VM from injecting frames with source MACs other than its assigned MAC.

If you are managing web applications or services on a VPS with cPanel or using VPS Control Panels for server management, verify with your provider that the underlying hypervisor enforces MAC anti-spoofing at the virtual switch level — this is the virtualized equivalent of port security.

For organizations running SSL-terminated services, ensuring that your SSL Certificates are properly configured provides an additional layer of protection: even if an attacker achieves traffic interception through MAC flooding, properly implemented TLS with certificate pinning prevents credential harvesting from encrypted sessions.

Decision Matrix: Choosing the Right Controls

Use this matrix to prioritize controls based on your environment type:

Technical Key-Takeaway Checklist

Before considering your Layer 2 environment hardened against MAC flooding, verify each of the following:

• Port security is configured on all access ports with a MAC limit appropriate to the connected device type (1 for workstations, 2 for IP phone + PC chains)
• Violation mode is set to `shutdown` on high-security ports and `restrict` with logging on general access ports
• Sticky MAC learning is enabled and the running configuration is saved to NVRAM
• DHCP snooping is enabled on all production VLANs with correct trusted/untrusted port designations and rate limiting on untrusted ports
• Dynamic ARP Inspection is enabled on all production VLANs and validated against the DHCP snooping binding table
• IP Source Guard is deployed on untrusted access ports in high-security segments
• VLANs are segmented by function with no unnecessary inter-VLAN routing
• Private VLANs are implemented in multi-tenant or hosting environments
• 802.1X is deployed or roadmapped for all access-layer ports
• SNMP monitoring is configured to alert on CAM table utilization thresholds
• NetFlow or sFlow is enabled and feeding an anomaly detection system
• SPAN sessions are configured for IDS/IPS visibility on critical VLANs
• Virtual switch security policies (anti-MAC-spoofing, forged transmit rejection) are enforced at the hypervisor level
• TLS is enforced for all sensitive application traffic so that even successful interception yields no plaintext credentials

Frequently Asked Questions

Can MAC flooding affect wireless networks?

Standard Wi-Fi infrastructure uses a different association model — access points manage client associations via the 802.11 protocol, not a CAM table in the Ethernet sense. However, the wireless controller or the upstream wired switch serving the AP can still be targeted. Additionally, rogue AP attacks on wireless networks achieve similar interception goals through different mechanisms.

Does MAC flooding work against modern enterprise switches with large CAM tables?

Yes, but the attack requires more bandwidth and time. A switch with a 128,000-entry CAM table requires proportionally more spoofed frames to exhaust. However, `macof` on a 10 Gbps link can generate millions of frames per second, making even large tables vulnerable within seconds. This is why hardware-level countermeasures like port security are essential — they prevent the table from being filled in the first place.

What is the difference between MAC flooding and MAC spoofing?

MAC flooding exhausts the CAM table through volume — the goal is to force hub-like flooding. MAC spoofing involves impersonating a specific, legitimate MAC address to hijack a session or bypass MAC-based access controls. They are distinct attacks, though an attacker may use MAC spoofing after a successful MAC flooding event to maintain a persistent MITM position.

Does enabling port security break legitimate network operations like DHCP?

No, if configured correctly. DHCP traffic originates from the client's MAC address, which is the one MAC address allowed on the port. The DHCP server's response is addressed to the client's MAC and arrives on the uplink (a trusted port). Port security on access ports does not interfere with DHCP unless the limit is set to zero or the violation mode incorrectly drops legitimate traffic.

How do I detect a MAC flooding attack that has already started?

Check CAM table utilization immediately: `show mac address-table count`. If utilization is near 100%, cross-reference with `show mac address-table dynamic` to identify ports with an abnormally high number of learned MAC addresses. Simultaneously, check interface error counters with `show interfaces` for input rate spikes. The offending port will show a dramatically elevated input packet rate and an unusually high count of learned MAC addresses.