In any Ethernet Virtual Private Network (EVPN) deployment, MAC mobility events occur regularly and are expected. When a virtual machine undergoes live migration from one hypervisor to another, it keeps its MAC address intact. Upon arrival at the new host, it broadcasts a gratuitous Address Resolution Protocol (ARP) message, enabling the new leaf to learn the MAC locally before distribution across the fabric. A single Border Gateway Protocol (BGP) update then reroutes traffic, preserving active sessions. A VM that has moved 200 times will display a counter reflecting all 200 transitions, each one legitimate.

Yet not every MAC movement indicates a genuine VM relocation. Occasionally, a MAC address belongs to a server that has never relocated, yet its sequence number climbs because another host within the same broadcast domain transmits frames using that server's address. Understanding this vulnerability requires examining how sequence numbers function within EVPN.

How EVPN changed MAC learning

Before EVPN, MAC learning happened entirely in the data plane. Switches or Provider Edge (PE) devices learned MAC addresses by observing source addresses in arriving frames, storing them in the forwarding table, and removing them after inactivity. EVPN shifted MAC learning to the control plane. A PE still learns local MAC addresses from data-plane traffic on access ports, but then distributes those addresses to every other PE using BGP. Remote MACs are learned from these advertisements rather than through flooding.

This transformation makes a MAC move an explicit, trackable event. When a PE learns locally a MAC it previously considered remote, it re-advertises that MAC with the MAC mobility sequence number incremented by one. Before EVPN, a forged MAC injection would eventually expire and needed constant reinjection to persist. With EVPN, the same spoofed frame becomes part of a BGP advertisement carrying a higher sequence number, and every PE accepts and installs that information. It remains trusted until the legitimate host advertises itself again.

The attack exploits a fundamental Ethernet limitation: no verification of source MAC address ownership. Any host can place a neighbor's MAC address in its own frames, and the leaf switch cannot tell it from the legitimate owner. Executing this requires neither privileged access nor advanced packet manipulation.

Ethernet forwards based on destination address, not source. Once the attacker inserts the victim's MAC in the source field, EVPN distributes that information, and every leaf installs a forwarding entry for the victim MAC. The goal is not to capture traffic sent by the victim, but to attract traffic destined for it.

Workloads communicating infrequently leave this attack window open longer. A storage target sitting idle for extended periods becomes a more appealing target than a busy VM. While this does not grant direct access to the fabric, it can expand visibility into the entire bridge domain. Impact depends on what connects to the access port. Hypervisors hosting VMs face greater exposure to this hijacking, while container platforms add a switching layer that complicates exploitation.

PE behavior, sequence numbers and MAC mobility explained

The MAC Mobility Extended Community is defined in RFC 7432 and travels with MAC/IP Advertisement (Type-2) routes. This transitive BGP Extended Community rides within the same UPDATE message as the Type-2 route. Every PE importing the EVPN instance's (EVI) Route Target (RT) through route reflectors will propagate the update. As long as a PE accepts a Type-2 route, the mobility attribute accompanies it.

According to RFC 7432, the eight octets of the MAC Mobility Extended Community break down as:

  • Octet 0: Type = 0x06 (EVPN Extended Community)
  • Octet 1: Sub-Type = 0x00 (MAC Mobility)
  • Octet 2: Flags. The low-order bit is defined: 0x01 = Sticky/Static. The remaining bits are reserved.
  • Octet 3: Reserved, sent as 0.
  • Octets 4–7: Sequence Number, a 32-bit unsigned integer (the critical field)

When a PE learns a MAC address locally, this sequence unfolds:

  1. A PE learns a MAC from the data plane via an ingress port. If it already holds a remote MAC/IP route for the same MAC from a different Ethernet segment, it assumes the host has moved. It re-advertises the MAC with a MAC Mobility Extended Community whose sequence number exceeds the highest value previously observed for that MAC. Both RFC 7432 and RFC 9721 mandate the local sequence number be higher than any existing remote MAC route.
  2. Every PE receiving multiple routes for the same MAC executes the same selection: Install the route with the highest sequence number. If sequence numbers match, the tie-breaker is the lowest PE IP address. While this supports legitimate mobility, it can also be exploited through spoofing.
  3. Sticky routes take priority. A MAC advertised with the sticky/static flag is deemed immobile and does not participate in sequence-number evaluation. A received sticky route cannot be overridden by a dynamic local learning event. RFC 7432 goes further: If one PE treats a MAC as static while another advertises the same MAC elsewhere, the event is flagged rather than treated as routine.

Section 15.1 of RFC 7432 addresses duplicate detection. If a PE observes a MAC moving X times within Y seconds (defaults of five moves within 180 seconds), it alerts the operator and must stop sending and processing MAC/IP Advertisement routes for that MAC address. However, implementations vary. Juniper suppresses the MAC until manual clearing, while Nokia SR OS uses five moves within 180 seconds, flushes the MAC, and retries after a 90-minute recovery period. This distinction matters because the scenario described here depends on two factors: the absence of MAC-origin authentication and relatively weak safeguards based on rate limiting. Together, these create abuse opportunities.

How an attacker takes advantage

Interception

This is essentially a Layer 2 man-in-the-middle attack executed through the control plane. By advertising a spoofed MAC address, every leaf updates its forwarding entry to point towards the attacker's port. Traffic destined for the victim gets redirected accordingly. This resembles a wiretap on east-west traffic from a compromised workload and circumvents much of the isolation normally provided by an EVI. Much of that traffic may be unencrypted, including iSCSI, NFS, replication, and management traffic. In many environments, the route reflector's history may be the only place where evidence of the event is recorded.

Denial of service

Two approaches exist. The simplest is to claim the victim's MAC address and discard all traffic. The more sophisticated approach weaponizes the protection mechanisms. Trigger five moves within 180 seconds, and the workload may lose connectivity. A fixed recovery timer offers limited protection because the attacker can simply repeat the process once the timer expires.

Control-plane exhaustion

Every MAC move generates a Type-2 withdrawal and update to every PE, along with a Forwarding Information Base (FIB) rewrite. By causing a small number of MAC addresses to flap just below the detection threshold, an attacker can generate a steady stream of BGP updates, Routing Information Base (RIB) processing, and FIB reprogramming across the fabric. A compromised host can also provoke a relearn war between the legitimate PE and a spoofing host that continually advertises a sequence number one higher.

IP hijack

Once the MAC has been spoofed, the attacker can attempt to claim the victim's IP address through gratuitous ARP or unsolicited neighbor advertisements. Because this does not generate additional MAC moves, MAC mobility and duplicate-MAC detection are never triggered. Where ARP/ND suppression is enabled, the leaf responds from the EVPN MAC/IP binding, effectively allowing a poisoned route to influence responses across the fabric. IP duplicate detection (RFC 9161) can help here, but only on platforms that support it and where it has been enabled.

Why duplicate-MAC protection doesn't help

Duplicate-MAC detection answers a straightforward question: Has a MAC address moved more than X times within Y seconds on a given PE? An attacker staying below that threshold avoids triggering alerts. Because counters are maintained per PE, activity spread across multiple leaf switches is even less likely to be detected. Once the monitoring window expires, the counters reset, allowing the attack to continue with minimal effort.

Even when duplicate-MAC protection activates, it generally reports a MAC duplication event rather than a likely attack. The resulting alert may also surface on a different part of the fabric from where the activity originated. In practice, the route reflector often provides the clearest view of what is happening, but it is rarely the first place operators investigate.

Detecting this in production

The route reflector may not be the first place operators look, but it provides visibility into every Type-2 route. Rather than manually reviewing route-reflector logs, operators can export routing updates using BGP Monitoring Protocol (BMP) (RFC 7854) to a collector. By tracking EVIs and MAC addresses alongside their originator, ESI, sequence number, sticky flag, and timestamps, several additional detection opportunities emerge:

  1. Sequence jumps. Investigate advertisements whose sequence number increases by more than one.
  2. Unexpected sticky bit. Sticky MACs are usually assigned sparingly. If a sticky route appears for a host that is not on the approved list, it warrants investigation.
  3. Tie-break flapping. If multiple PEs advertise the same MAC with different ESIs and identical sequence numbers, something is probably wrong.
  4. Infrastructure binding changes. A new MAC suddenly appearing behind a gateway, resolver, storage target, or management IP is worth examining.

This information should also be cross-checked against the access layer. DHCP snooping bindings, IEEE 802.1X session tables, and IPAM or port-inventory exports can help identify where a MAC address actually resides. Any Type-2 route that conflicts with these records deserves additional scrutiny.

Finally, duplicate-MAC and MAC-move syslog messages can be forwarded into a Security Information and Event Management (SIEM) platform. Alerting can then be tuned appropriately, preventing important events from being lost in routine operational noise.

EVPN trusts every leaf — should it?

EVPN is designed to trust information learned from every leaf. A MAC learned on an access port is accepted as genuine, and advertisements received from a PE are treated as authoritative. Sequence numbers, duplicate-detection mechanisms, and sticky flags are all trusted without additional verification.

Whether that level of trust remains appropriate is an architectural question. In a data center environment, operators naturally want to avoid additional processing, host interrogation, or other mechanisms that could interfere with line-rate forwarding. That said, tools exist to limit the impact of a compromised host. Trust can be established at the access edge by ensuring hosts are only permitted to use their assigned addresses. Port MAC limits, DHCP snooping, ARP/ND inspection, IEEE 802.1X, and sticky MAC entries for critical systems are all useful controls. At the control-plane level, monitoring route-reflector feeds provides additional visibility.

The real question is not whether EVPN trusts every leaf, but whether every leaf should trust every host connected to it. EVPN faithfully distributes the information it receives, making access-layer trust controls the foundation of the fabric's security model. Without robust validation at the edge, the control plane can propagate incorrect information at scale. For that reason, securing host identity at the access layer is not merely a best practice, it is a prerequisite for securing the EVPN fabric itself.