EVPN Duplicate MAC Suppression Blocking VRRP Failover: Causes and Fix

If a VRRP failover or an active/standby device swap in your EVPN-VXLAN fabric leaves traffic black-holed to the old location, the most likely cause is evpn duplicate mac suppression tripping because the failover generated more MAC mobility events than Junos' default detection window allows. The fix in the field is almost always some combination of relaxing the duplicate-mac-detection thresholds, excluding the known virtual MAC from detection, and checking the VXLAN DDoS policer, in that order. This guide covers the diagnostic sequence, each root cause ranked by how often we actually see it, and copy-ready configuration.

What the Symptom Actually Looks Like

The pattern is consistent across the reports we reviewed, including a widely-discussed EVPN/VXLAN thread on r/Juniper involving QFX5120 leafs and an Acme SBC active/standby pair with hundreds of VRRP-style interfaces. After a failover, the new active node sends gratuitous ARP and starts forwarding, but show ethernet-switching table on the remote leafs still shows the MAC pinned to the old ESI or interface. Traffic to that MAC gets flooded as unknown unicast instead of being switched directly, and it can stay broken for minutes, or in one reported case, days, before it self-heals.

This is not a routing failure and it is not a VRRP configuration error. It is EVPN's own duplicate MAC address detection mechanism doing exactly what it was designed to do: protecting the fabric from MAC flapping caused by a real network loop. The problem is that a legitimate, fast failover looks identical to a loop from the control plane's point of view, and Junos suppresses the MAC rather than risk re-learning a looped address.

Diagnostic Order: Cheapest Checks First

Work through these in order before opening a JTAC case. Each one takes under a minute and rules out a specific layer.

show evpn database mac-address 00:00:5e:00:01:01 extensive

Look at the State field. If it shows Duplicate or references MAC mobility history with a suppressed entry, you have confirmed duplicate MAC suppression is the active condition, not a learning failure.

show log messages | match "evpn.*mac"

Junos generates a syslog message any time duplicate MAC detection is triggered or a pinned MAC conflict occurs. If you see repeated EVPN MAC move messages timed to your failover events, that confirms the mobility threshold is the trigger.

show ddos-protection protocols statistics terse

Check specifically the arp and vxlan protocol groups for a non-zero dropped-packets counter. A DDoS policer violation during a mass ARP flood will produce a similar black-hole symptom even when duplicate MAC detection is not involved, so ruling this out early saves time.

show policer __default_arp_policer__

On QFX platforms all interfaces share a single default ARP policer. A burst of gratuitous ARP from hundreds of failing-over interfaces at once can hit this policer even when the per-protocol DDoS counters look clean, so check both.

Root Cause 1: Duplicate MAC Detection Threshold Is Too Strict for the Failover Pattern

This is the most common cause in every report we reviewed. Junos' default duplicate-mac-detection settings are a 180-second detection window with a threshold of 5 mobility events before a MAC is flagged as duplicate and suppressed. A VRRP or active/standby failover that moves the same virtual MAC across hundreds of VLANs inside a few seconds will blow past that threshold almost instantly, even though every single move is legitimate.

Our read is that Juniper tuned these defaults for the common case, a single host migrating occasionally, not for a design where one shared virtual MAC moves across many logical interfaces simultaneously during a planned or unplanned failover. That is a reasonable default for most deployments, but it is actively hostile to VRRP-over-EVPN and clustered-firewall designs unless you tune it. The cost of the strict default is that your fastest, most time-sensitive failover event is exactly the event most likely to trip suppression.

The Fix

set protocols evpn duplicate-mac-detection detection-window 5
set protocols evpn duplicate-mac-detection detection-threshold 20
set protocols evpn duplicate-mac-detection auto-recovery-time 5
commit confirmed 5

These are the widened values reported as effective in the field: a 5-second window, a threshold of 20 events before suppression, and automatic recovery after 5 minutes if suppression does trigger. Always use commit confirmed on a change like this from an out-of-band console session, since a bad duplicate-mac-detection value can make an active fabric problem worse before you can roll it back.

Root Cause 2: The VRRP Virtual MAC Is Not Excluded From Detection

Widening the threshold reduces false positives but does not eliminate them under heavy load. If you know in advance which MAC addresses are legitimately mobile, such as a VRRP virtual MAC or an SBC's shared cluster MAC, the cleaner fix is to exclude that specific MAC from duplicate detection entirely rather than relying on a wider threshold to tolerate it.

The Fix

set protocols evpn mac-list VRRP-EXCLUDE mac-address 00:00:5e:00:01:01/48
set routing-instances EVPN-INSTANCE protocols evpn duplicate-mac-detection exclude-list VRRP-EXCLUDE

This is a newer, more targeted mechanism than the global threshold. Note that Junos will reject a configuration that combines duplicate-mac-detection no-mac-suppression with exclude-list on the same instance, since the two statements overlap in function. Pick one approach per routing instance and verify the bind with show evpn mac-lists.

Root Cause 3: VXLAN DDoS Protocol Policer Dropping the ARP Flood

Even after duplicate-mac-detection is tuned, a mass failover generates a burst of gratuitous ARP across the VXLAN overlay, and the default DDoS protection policer for the vxlan protocol group can drop a portion of it. This does not show up as a MAC suppression message in the logs, which is why it gets missed; it shows up only in show ddos-protection protocols statistics terse.

The Fix

set system ddos-protection protocols vxlan aggregate bandwidth 2000
set system ddos-protection protocols vxlan aggregate burst 1000
commit confirmed 5

Raise these values incrementally and re-test rather than setting them arbitrarily high, since DDoS protection on the VXLAN protocol group exists to protect the Routing Engine from a genuine control-plane flood, not just your planned failover traffic.

Root Cause 4: MAC Mobility Sequence Number Races on Multihomed ESI

Less common, but seen in active/active ESI-LAG deployments: if two PE devices both advertise the same MAC with the same sequence number during a fast failover, Junos falls back to a tie-break on the advertising PE's IP address per RFC 7432. In an asymmetric topology this can leave the "wrong" PE holding the active route even after the real host has moved, independent of any duplicate-mac-detection setting.

The Fix

clear evpn duplicate-mac-suppression
show evpn database mac-address 00:00:5e:00:01:01 extensive

Manually clearing suppression forces a fresh mobility sequence on the next MAC move. If the same VLANs keep landing in this state repeatably, that is a signal to open a JTAC case with show evpn database extensive output captured on all PEs during the event, since sequence-number races are harder to fix with configuration alone.

Quick Reference: Symptom to Cause to Fix

Verification After the Fix

After committing the widened thresholds and the exclusion list, trigger a controlled failover in a maintenance window and confirm the MAC updates cleanly.

show evpn database mac-address 00:00:5e:00:01:01 extensive

A healthy result shows State: Active with a current, incrementing sequence number and no mobility history flagged as duplicate. Compare this against the broken state captured earlier, where the same command showed State: Duplicate with a mobility history listing more events than your configured threshold inside the detection window.

show ethernet-switching table vlan-id 100

Confirm the MAC now points at the correct, current ESI or interface on every leaf, not just the leaf physically connected to the newly active device.

A Note on Design, Not Just Configuration

It is worth stepping back from the tuning exercise for a moment. EVPN-VXLAN was designed primarily around individual host mobility, like a VM migrating between racks, not around hundreds of logical interfaces on a single device failing over simultaneously. When a vendor sales team recommends EVPN-VXLAN over a simpler MC-LAG or virtual-chassis design for what is fundamentally a two-box, two-datacenter Layer 2 extension, it is worth asking whether the added control-plane complexity is buying you anything a simpler design would not, especially if the workload includes a device like an SBC with an unusually high interface count moving as a block.

That tradeoff is not a reason to avoid EVPN-VXLAN. It is a reason to tune duplicate-mac-detection and the VXLAN DDoS policer as a standard part of the build, before the first real failover happens in production, rather than discovering the defaults do not fit your failover pattern during an actual outage.

Release and Platform Notes

This guide is written against Junos 23.4R2 on QFX5120 and QFX5130 EVPN-VXLAN leaf platforms, which reflects a commonly JTAC-recommended train at the time of writing. The duplicate-mac-detection statement and its detection-window, detection-threshold, and auto-recovery-time options have been stable across recent Junos EVPN releases, but the newer mac-list exclusion mechanism with MAC prefix-length support was introduced in Junos 25.2R1 and changes the CLI format for any existing mac-list configuration. If you are upgrading from a pre-25.2R1 release and already have a mac-list configured, deactivate it before the upgrade and reconfigure it in the new format afterward to avoid a validation error, per Juniper's own documentation. Always verify current behavior in your own lab against the release you are running; do not assume this configuration is tested against your specific platform and train.

For the underlying standard, EVPN MAC mobility and the sequence-number tie-break logic referenced in Root Cause 4 come from RFC 7432, the EVPN base specification. For the full set of duplicate-mac-detection options, see Juniper's own Changing Duplicate MAC Address Detection Settings page. The original field report this guide draws its symptom pattern from is documented in a r/Juniper EVPN-VXLAN MAC re-learning thread, where multiple engineers compared notes on the same failure.

Related guides: if your fabric is also seeing EVPN-VXLAN interop problems unrelated to MAC suppression, see our EVPN-VXLAN interop troubleshooting guide. If the failover you are chasing is actually a BGP adjacency problem rather than a MAC table problem, start with our BGP stuck in Active guide. For general EVPN and VXLAN fundamentals on EX and QFX hardware, browse our Routing and Switching category. And if you are chasing a different control-plane symptom entirely, our OSPF stuck in ExStart guide uses the same cheapest-check-first diagnostic approach.

Frequently Asked Questions

Why does my VRRP MAC not update after failover in EVPN VXLAN?

The virtual MAC is most likely caught by Junos' duplicate MAC detection, which suppresses a MAC address after it exceeds the default mobility threshold of 5 moves in 180 seconds. Run show evpn database mac-address extensive to confirm the State field shows Duplicate before assuming it is a VRRP configuration problem.

How do I clear duplicate MAC suppression in Junos?

Use clear evpn duplicate-mac-suppression to manually clear a suppressed MAC and allow it to be re-learned immediately. This does not prevent the same MAC from being suppressed again on the next large failover unless you also widen the detection thresholds.

What is the default duplicate MAC detection threshold in Junos EVPN?

By default, Junos uses a detection-window of 180 seconds and a detection-threshold of 5 mobility events before flagging a MAC as duplicate. These are configured under set protocols evpn duplicate-mac-detection at the routing-instance level.

Can I exclude a VRRP virtual MAC from duplicate detection entirely?

Yes, using set protocols evpn mac-list to define the MAC and binding it with duplicate-mac-detection exclude-list on the routing instance. Junos will reject this if you also have no-mac-suppression configured on the same instance, since the two options conflict.

Why does it take days for EVPN MAC suppression to clear on its own?

If no auto-recovery-time is configured, a suppressed MAC remains suppressed indefinitely until it is manually cleared or the condition that triggered it stops recurring. Setting an explicit auto-recovery-time value, for example 5 minutes, ensures suppression lifts automatically instead of persisting for days.

Could this actually be a DDoS policer problem instead of MAC suppression?

Yes, a mass ARP flood during failover can separately trigger the VXLAN or ARP DDoS protection policers even when duplicate MAC detection is not involved. Always check show ddos-protection protocols statistics terse alongside the EVPN database output before concluding it is purely a MAC suppression issue.