The EVPN trust challenge: How to detect and contain internal MAC hijacks

As with any Ethernet Virtual Private Network (EVPN) fabric, you have almost certainly encountered a MAC/IP route or dealt with a MAC mobility event. MAC mobility events are not unusual. A busy virtual machine (VM) can trigger one, and they are a normal part of VM operations.

Live migration moves a running VM from one hypervisor to another. Throughout the process, the VM retains its MAC address. When it arrives on the new host, it sends a gratuitous Address Resolution Protocol (ARP) message, allowing the new leaf to learn the MAC locally before it is propagated throughout the fabric. The fabric then redirects traffic with a single Border Gateway Protocol (BGP) update, allowing the VM to maintain its active sessions. A VM that has been migrated 200 times will show a counter of 200 moves, all of them legitimate.

However, it is not safe to assume that every MAC move reflects a legitimate VM migration. Every so often, the MAC address belongs to a server that has never moved, yet its sequence number keeps increasing because another host in the same broadcast domain is sending frames with that server's address.

To understand why this happens, we need to look at the sequence number.

Before EVPN, MAC learning occurred entirely in the dataplane. A switch or Provider Edge (PE) learned MAC addresses by observing source addresses in incoming frames, installing them in the forwarding table, and ageing them out after a period of inactivity.

With EVPN, MAC learning moves into the control plane. A PE still learns local MAC addresses from the dataplane as traffic arrives on an access port, but it then advertises those MAC addresses to every other PE using BGP. Remote MACs are subsequently learned from those advertisements rather than through flooding.

This makes a MAC move an explicit 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 poisoned MAC injection would eventually age out and required continual reinjection to remain effective. With EVPN, the same forged frame becomes part of a BGP advertisement with a higher sequence number, and every PE trusts and installs that information. The information remains trusted until the legitimate host advertises itself again.

The attack also exploits a much older weakness: Ethernet does not verify ownership of a source MAC address. Any host can place a neighbour's MAC address in its own frames, and the leaf switch cannot distinguish it from the legitimate owner. Exploiting this behaviour requires neither privileged access nor sophisticated packet manipulation.

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

Workloads that communicate infrequently can leave this attack window open for longer periods. A storage target that remains idle for extended periods, for example, is likely to be a more attractive target than a busy VM. Although this does not provide direct access to the fabric itself, it can increase visibility into the entire bridge domain.

The impact depends largely on what sits behind the access port. Hypervisors hosting VMs are generally more exposed to this type of hijacking, while container platforms introduce an additional switching layer that can make exploitation more difficult.

PE behaviour, sequence numbers and MAC mobility explained

The MAC Mobility Extended Community is defined in RFC 7432 and is associated with MAC/IP Advertisement (Type-2) routes.

The MAC Mobility Extended Community is a transitive BGP Extended Community carried within the same UPDATE message as the Type-2 route. Every PE that imports the EVPN instance's (EVI) Route Target (RT) through the route reflectors will propagate the update. As long as a PE accepts a Type-2 route, the mobility attribute accompanies it.

As defined in RFC 7432, the eight octets of the MAC Mobility Extended Community are:

• 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 field we care about).

When a PE learns a MAC address locally, the following sequence occurs:

1. A PE learns a MAC from the dataplane via an ingress port. If it already has 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 is one greater than the highest value observed for that MAC. Both RFC 7432 and RFC 9721 require the local sequence number to be higher than any existing remote MAC route.
2. Every PE that receives multiple routes for the same MAC performs the same selection process: Install the route with the highest sequence number. If the sequence numbers are equal, the tie-breaker is the lowest PE IP address. While this behaviour supports legitimate mobility events, it can also be exploited through spoofing.
3. Sticky routes take precedence. A MAC advertised with the sticky/static flag is considered 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 a step further: If one PE treats a MAC as static while another advertises the same MAC elsewhere, the event is flagged rather than treated as informational.

Additional footnote: Section 15.1 of RFC 7432 covers 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 differ. Juniper suppresses the MAC until manually cleared, while Nokia SR OS uses five moves within 180 seconds, flushes the MAC, and retries after a 90-minute recovery period.

This matters because the scenario described here relies on two factors: The lack of MAC-origin authentication and relatively weak safeguards based on rate limiting. Together, these factors create opportunities for abuse.

How an attacker takes advantage

1. Interception. This is essentially a Layer 2 man-in-the-middle attack implemented 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 is redirected accordingly. This resembles a wiretap on east-west traffic originating from a compromised workload and bypasses 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.
2. Denial of service. There are two approaches. The simplest is to claim the victim's MAC address and drop all traffic. The more interesting approach is to weaponize the protection mechanisms. Trigger five moves within 180 seconds, and the workload may lose connectivity. A fixed recovery timer provides limited protection because the attacker can simply repeat the process once the timer expires.
3. 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.
4. IP hijack. Once the MAC has been spoofed, the attacker can attempt to claim the victim's IP address through gratuitous ARP or unsolicited neighbour 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 is designed to answer a simple question: Has a MAC address moved more than X times within Y seconds on a given PE?

An attacker who stays below that threshold can avoid 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 is triggered, it generally reports a MAC duplication event rather than a likely attack. The resulting alert may also appear 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. Check for slow churn. Measure MAC moves over hours or days rather than within a single 180-second window. Establish a baseline for each workload and identify outliers.

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 centre environment, operators naturally want to avoid additional processing, host interrogation, or other mechanisms that could interfere with line-rate forwarding.

That said, there are tools available 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.

Sabina Anja is Chief Technologist at Broadcom, with 20 years of experience in ASIC design, distributed systems, and cloud infrastructure. She focuses on sovereign cloud platforms, digital infrastructure resilience, and AI-ready architectures that support security, sovereignty, and long-term operational control.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.