EX Switch MAC Flapping and Unicast Flooding: Finding the Loop or the Ghost

"Switches flooded with MAC learning of invalid addresses" — the Juniper community thread with that title, plus the r/networking "Juniper EX flooding packets out all interfaces" post, describe the same scary hour: an EX switch whose MAC table churns constantly, or which floods every packet out every port. There are four root causes in the real world, and each has a distinctive signature.

Step 1: Quantify the Problem First

show ethernet-switching table | last 40
show ethernet-switching statistics
show l2-learning mac-learning-buffer | match flap

Distinguish the two symptom classes: flapping (the same MAC alternates between two ports) means two paths claim the host; unknown-unicast flooding (every frame copied to all ports in the VLAN) means the destination MAC is never learned. They have different culprits.

Cause 1: A Layer-2 Loop (Flapping + Flooding Together)

If the same MAC flips between interfaces faster than you can read the table, and flooding spikes at the same time, you almost certainly have a loop somewhere STP is not blocking — a misconfigured trunk, an unmanaged switch bridging two access ports, or a hairpin cable in a patch panel:

show spanning-tree bridge
show spanning-tree interface
monitor traffic interface ge-0/0/12 no-resolve

A port receiving the same frames it sends (your own BPDUs or your own source MAC coming back) is the loop port. Trace it, unplug, and watch the table calm within seconds. On EVPN fabrics, the equivalent pathology is duplicate MAC detection — the EVPN-VXLAN troubleshooting method covers show evpn duplicate-mac.

Cause 2: Silent Point-to-Point Failures

The community thread about MAC learning of invalid addresses on EX2300/EX3400 turned out to involve media errors: a degrading link corrupts frames, the switch learns garbage source MACs, then floods to find them. Check the physical layer on every suspicious port:

show interfaces ge-0/0/12 extensive | match "errors|drops|CRC"
show interfaces diagnostics optics ge-0/0/12

The isolation procedure in our CRC and input-errors guide is the standard play: zero the counters, measure growth, swap components one at a time.

Cause 3: Asymmetric Routing (Flooding with Clean Physicals)

The classic quiet cause: two routers, two VLANs, return traffic entering the switch on a different VLAN than it left. The switch never sees the return frames in the VLAN where it learned the source MAC, so it floods them. The r/networking EX flooding thread followed exactly this pattern — traffic redirected out a different interface, then unicast flooding everywhere. The fix is design symmetry: make both directions of a flow use the same L2 segment, or enable ARP suppression/gateway redundancy so MACs stay learned where traffic returns.

Cause 4: A Leaking or Spoofing Device

A misbehaving host, a virtualization platform with promiscuous ports, or a test box replaying frames can inject thousands of source MACs — the switch dutifully learns them all, fills its table, and starts aging out real entries. Protect the edge:

set switch-options interface ge-0/0/20.0 mac-limit 10 action drop
set forwarding-options storm-control-profiles SC all bandwidth-percentage 5

Apply storm control to access ports, MAC limits where the topology is known, and watch show ethernet-switching statistics for which port trips first — the offender identifies itself.

Quick Reference

If the EX runs inside a Virtual Chassis, remember a VC split mimics loop symptoms — verify member health with the Virtual Chassis troubleshooting guide before chasing cables. And when the flooding starves the routing engine's control plane, the high CPU guide shows how to spot and rate-limit the collateral damage.