Troubleshoot MAC Flaps and Layer 2 Loops on Catalyst Switches

A MAC flap is one of the clearest early warnings of a Layer 2 problem: the switch sees the same source MAC address arriving on different ports in rapid succession and keeps rewriting its MAC address table. Left alone, it degrades forwarding, spikes CPU, and often ends in a full broadcast storm. This guide follows Cisco's systematic approach to MAC flap troubleshooting — reading the log message, tracing the MAC through the topology, and applying the right protection features so the flap cannot recur.

Background: How the MAC Address Table Gets Poisoned

A Layer 2 switch learns by source address. It receives a frame, notes the source MAC, and records "that address lives out of port X" in the MAC address table (also called CAM table). Every subsequent frame destined to that MAC is forwarded out port X and nowhere else.

That design assumes each source MAC has exactly one arrival point. A MAC flap breaks the assumption: the same source MAC arrives on two different ports in an alternating pattern. Each arrival triggers a table rewrite, and every rewrite flushes the previously learned entry. The practical effects are all bad:

• Forwarding instability. Frames for that MAC may be sent to the wrong port half the time, producing intermittent loss that users describe as "the network is slow, then fine, then slow".
• Unknown-unicast flooding. Every time the entry is rewritten, frames destined to the address are flooded to the whole VLAN until the table stabilises again.
• Control-plane CPU load. The switch logs every notification and reprograms the hardware table continuously; CPU and log buffers fill.
• Storm escalation. If the underlying cause is a loop, broadcast traffic multiplies across the affected links and can saturate them entirely.

MAC flapping is a symptom with several possible causes. The skill is in telling them apart quickly, because the remedy is completely different for each.

What a MAC Flap Looks Like

On Cisco Catalyst switches, flapping is logged as:

%SW_MATM-4-MACFLAP_NOTIF: Host xxxx.xxxx.xxxx in vlan x is flapping
between port (1) and port (2)

The message names the MAC address and the two interfaces involved — one leads to the real device, the other leads toward the loop.

Read the message carefully before doing anything else. The severity 4 means warning, not error — the switch is telling you it noticed a condition, not that it has failed. The message repeats on a timer for as long as the flapping continues, and the notification is rate-limited, so a single line in the log may represent far more than one flap event. The two port names are the entire value of the message: without them you have no starting point, and with them you have a bounded problem in exactly one VLAN.

Prerequisites and Preparation

Before troubleshooting, gather the following so the investigation does not stall halfway:

• The exact log line, including timestamp, VLAN and both interface names.
• Console or stable management access to every Layer 2 switch in the path. A flooding event can take out your SSH session, so do not rely solely on in-band management.
• A topology diagram, or the ability to reconstruct one from show cdp neighbors and show lldp neighbors.
• Platform awareness. On a stack, port names appear as GigabitEthernet1/0/1 with a switch member number; on a standalone switch they are GigabitEthernet0/1. Mistyping the member number sends you to the wrong box.
• Permission to shut a port. The fastest fix for a suspected loop is to disable the offending interface, and that may interrupt a user.

Root Causes

• Layer 2 loop — the most common cause, usually from STP misconfiguration or unmanaged switches.
• Faulty hardware or cabling — bad cables can deliver frames to the wrong interface.
• Duplicate MAC addresses — common in HA clusters with shared virtual MACs.
• MAC spoofing — a security issue that presents the same symptoms.

Two further causes are worth adding because they are easy to miss. First, software or NIC teaming misconfiguration: a server with two bonded NICs configured in a mode the switch does not know about can emit frames with the same MAC from both adapters, and the switch dutifully flaps between its two ports. Second, wireless bridging: an AP in bridge mode or a mesh link can introduce a second path with unpredictable behaviour. Both present identically to a loop in the log.

The Tracing Workflow

1. Note the MAC and interfaces from the log message.
2. Investigate the interfaces with show interfaces and show mac address-table to see which device is really there.
3. Trace the flapping MAC — run show mac address-table hop by hop on each L2 switch in the path; the port that does not lead to the device leads to the loop.
4. Check STP with show spanning-tree, and look for topology change notifications with show spanning-tree detail | include ieee|occur|from|is.
5. Confirm or rule out duplicate MACs on the network.

Worked Example: Tracing One Flapping MAC

Suppose the log on SW-A reports Host 0011.2233.4455 in vlan 10 is flapping between port Gi1/0/5 and port Gi1/0/24. The workflow looks like this in practice:

SW-A# show mac address-table address 0011.2233.4455
SW-A# show interfaces GigabitEthernet1/0/5 status
SW-A# show interfaces GigabitEthernet1/0/24 status
SW-A# show cdp neighbors GigabitEthernet1/0/24 detail
SW-A# show spanning-tree vlan 10 detail | include ieee|occur|from|is

Port 5 turns out to be an access port to a desk, and port 24 is the uplink toward SW-B. Next, follow the same MAC onto SW-B:

SW-B# show mac address-table address 0011.2233.4455
SW-B# show interfaces GigabitEthernet2/0/10 status
SW-B# show spanning-tree vlan 10 | include Root|Designated|Blocking|Forwarding|Roles

Repeat until you reach a switch where the MAC appears on exactly one port. The switch before that one is where the extra path begins — in most real incidents, an unmanaged switch, a misconfigured trunk with an overlapping VLAN list, or a port that has left the STP domain. Once you have located it, shut the offending port and watch whether the notification stops. If it stops, you have found the path; now fix the cause rather than leaving the port down forever.

Distinguishing the Causes

Use these observations to separate the four main causes quickly:

• Loop: MAC flaps between two infrastructure ports, often with high broadcast counters on both and STP topology changes in the log. show interfaces | include broadcast shows rising rates.
• Bad cabling or hardware: one port reports CRC errors, runts or late collisions alongside the flap; the flap stops immediately when that cable is replaced. A flapping interface (link up/down) is different from a flapping MAC and is worth reading about separately — see how Junos identifies flapped interfaces for the cross-vendor view.
• Duplicate MAC in an HA pair: the flapping MAC belongs to a firewall or load balancer that is genuinely present on two ports by design. Check the documentation of the device; the fix is a design change (port-channel or vPC), not a spanning-tree change.
• Spoofing: the flap correlates with a period of anomalous traffic, and no physical topology explains the second path. This becomes a security investigation.

Protection Features That Stop Flaps

UDLD aggressive mode err-disables ports when a previously synchronized neighbor cannot be re-established — catching unidirectional links that STP cannot see. Storm control is implemented in hardware and suppresses broadcast, multicast and unknown-unicast floods on access ports without impacting performance. BPDU Guard on PortFast ports shuts down any port that receives BPDUs, stopping unauthorized devices from joining the STP domain.

Three more features belong in the same toolbox. Root Guard and Loop Guard prevent a port from becoming root or from moving to forwarding when BPDUs stop arriving — the classic failure mode where a unidirectional link silently creates a loop. Port security with a low maximum MAC count limits how many addresses an access port can learn, which stops a desk port from becoming a bridge. Configuration details for two of these are on this site: UDLD normal vs aggressive mode covers the detection side, and root bridge election and design rules explains how to make the topology itself deterministic so loops are less likely to appear in the first place.

Verifying That the Fix Worked

SW-A# show logging | include MACFLAP
SW-A# show mac address-table address 0011.2233.4455
SW-A# show interfaces GigabitEthernet1/0/24 counters broadcast
SW-A# show spanning-tree vlan 10 detail | include topology change
SW-A# show interfaces status err-disabled

A confirmed fix has four signatures: no new MACFLAP notifications after the change, the MAC appearing on exactly one port consistently, broadcast counters flat instead of climbing, and no further topology-change counters. Check show interfaces status err-disabled after enabling UDLD or BPDU Guard — protection features that fire are doing their job, but an err-disabled port needs to be recovered deliberately (shutdown / no shutdown, or automatic recovery with an interval) rather than left dark.

Common Mistakes

• Chasing the log message instead of the topology — the two ports in the notification are a starting point, not the answer.
• Disabling STP on access ports to "fix" flapping. That removes the safety net and converts a flap into a full loop.
• Leaving the offending port shut and closing the ticket. The root cause is still there, and it will return on the next cable move.
• Assuming a flapping MAC means a flapping link. They are different events with different evidence.
• Forgetting to check the server side when the evidence points at a NIC team — see Linux bonding modes for how hosts should be configured to present a single MAC.

FAQ

How often does the notification repeat? The switch rate-limits MACFLAP notifications, so treat each logged line as a sample of an ongoing condition rather than a count of events.

Can MAC flapping happen without a loop? Yes — duplicate MACs, NIC teaming faults and spoofing all produce it with a perfectly healthy STP topology.

Should I disable the flapping MAC's port immediately? If user impact is severe and you have console access, shutting one port is a reasonable holding action. Understand which port you are shutting: the access port serving a real user, or the uplink carrying many VLANs.

Does a stack change the diagnosis? It adds another layer — a bundle or stack link moving a MAC between member switches can look like a flap. Catalyst 9300 StackWise vs VSS vs StackWise Virtual explains how those architectures present their ports.

What about the MAC address table ageing time? A shorter ageing time makes flaps more destructive because entries expire faster; comparative defaults are covered in Arista EOS MAC address table commands and aging, which mirrors the same concepts.

Related: Cisco Catalyst STP 排障 covers the same loop symptoms from the STP angle, and Junos 接口 Flap 识别 explains interface flapping detection on Junos for a cross-vendor view.

原文链接：https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol-stp-8021d/221722-troubleshoot-mac-flaps-loop-on-cisco-cat.html