Summary

  • EVPN duplicate-address recovery can require both a host-side correction and the release or reconciliation of retained network state. Either action alone can leave work unfinished.
  • The affected object matters: a duplicate MAC, a duplicate IP with different MACs and an IP-only routed overlay do not have identical consequences.
  • Timer-based release exists in the specifications. The operating decision is how its scope fits the correction, not whether every recovery must be manual.

Imagine an incident in which an unwanted virtual machine has been removed. The host team has a defensible reason to mark its task complete: the competing address assignment no longer exists where it was found. A network operator, looking at a frozen route, has an equally defensible reason to say that service has not yet returned. Neither observation requires the other team to be wrong. They describe different points in a recovery sequence.

This is a hypothetical situation, not a report of a customer outage. Its importance lies in a dependency that EVPN's specifications make explicit. The person able to correct an endpoint assignment may not be the person able to release the resulting network state. Even when one engineer has both capabilities, one action does not automatically perform the other. The repair window includes the interval between correcting the conflict and restoring the intended path through the network.

That interval belongs in the operating model. It is easy to budget for fault detection and harder to account for a protection mechanism that has done its job but has not yet relinquished its effect. A service owner needs to know what remains to happen after the bad assignment is gone, who can make it happen, and whether an automated release is already scheduled. “The duplicate has been removed” is useful progress; it is not always the last operational event.

Why the network retains the problem

Ethernet VPN distributes endpoint reachability between provider-edge devices, usually shortened to PEs. A mobile endpoint can leave one Ethernet segment and appear on another. During the transition, old and new advertisements may coexist. The MAC-mobility procedure in RFC 7432 uses sequence numbers to order that changing reachability and trigger withdrawal of older advertisements.

The same machinery can encounter a different situation: two endpoints using the same MAC address in the same relevant broadcast domain. Their traffic can make the address appear to move repeatedly. The baseline specification describes configurable event-count and time thresholds, followed by an operator alert and a stop to sending and processing the affected MAC/IP advertisements until corrective action. This is a bounded response to an unstable address, not an instruction to halt the entire fabric. Other PEs may still forward traffic towards one of the advertising devices.

Nor is every appearance at several PEs a move. A legitimately multihomed endpoint can be reachable through multiple devices attached to the same Ethernet segment. The segment identifier helps distinguish that case from movement between segments. Counting devices without understanding this relationship can turn intended redundancy into an imagined conflict.

Retained state is therefore not an embarrassing residue of an otherwise completed repair. It can be the intended consequence of a protective decision. Removing it too readily and leaving it too long create different service exposures. Treating either outcome as automatically correct conceals the choice that operations must make.

The address that conflicted changes the repair

The later RFC 9721 extends EVPN integrated routing and bridging mobility procedures. Its subject includes cases in which an IP address moves to a different MAC association, rather than the two addresses moving together unchanged. This is relevant to re-created virtual workloads and to legitimate arrangements in which several IP addresses share one MAC address. Such sharing is not, by itself, evidence of misconfiguration.

The document separates three duplicate-detection cases: the same MAC at competing hosts; the same IP associated with different MACs; and a routed overlay in which host MAC addresses are not advertised. These are practical distinctions, not merely alternative ways to label one alarm.

Where the MAC is duplicated, the associated MAC-IP routes inherit that condition. Where only an IP conflicts across different MACs, the corresponding MAC-IP route is affected without making the related MAC route and every other IP sharing that MAC duplicate as well. The recovery decision consequently needs an identified address and context. “Clear the host” can be an insufficient description if the operator has not established which binding should remain.

This does not mean that the network's duplicate flag adjudicates which endpoint is legitimate. RFC 9721 considers recovery after removing a duplicate at either the location where state was frozen or the location where it was not. The place displaying the restriction is not necessarily the place whose endpoint should be discarded. Business and provisioning knowledge still matter when deciding which instance is intended to serve the workload.

A correction on the host side, a release on the network side

Section 8.4 of RFC 9721 starts recovery with a host-side action: remove one of the competing MAC or IP assignments. After that correction, normal operation may still wait for the duplicate state to age out, unless further action expedites recovery.

The document then distinguishes route unfreezing from route clearing. Unfreezing can advertise a sequence number higher than the other location's, helping the distributed network reconcile the surviving reachability. The resulting events can cause ARP or Neighbor Discovery probes and deletion of stale local state. Which location retained the intended endpoint changes how this proceeds.

Clearing a local MAC route or an ARP/Neighbor Discovery entry is a separate operation. In particular, clearing state at the non-frozen location may still leave an unfreeze needed elsewhere. A command that successfully removes one local entry can therefore be entirely effective at its own job while leaving the wider recovery incomplete. The specification does not offer one universal vendor command that substitutes for understanding these locations.

An organisation can accommodate this without creating another approval committee. It can make the handoff precise: which assignment has been corrected, where it was corrected, which endpoint should remain, and what retained state is still waiting to be released. The point is continuity of the recovery decision, not the number of people who sign it.

A useful counterexample is an unwanted workload recreated by an orchestration system after an operator deletes its current instance. This is an analytical scenario, not an observed implementation claim. If the configuration that asks for the duplicate remains, the console action may remove a symptom only temporarily. The person responsible for recovery needs a way to determine whether the endpoint correction will persist. Otherwise, faster network release can simply shorten the interval before the same contention returns.

The timer is a policy, not an embarrassment

A blanket instruction to disable automatic recovery would misread the source material. RFC 9161, which concerns Proxy ARP/Neighbor Discovery operation in EVPN, describes clearing duplicate-IP status through operator correction or, alternatively, a hold-down timer. It gives a default of 540 seconds and makes the relevant parameters configurable.

That rule concerns the state described in that proxy function. It is not a promise that every frozen EVPN MAC route on every product disappears after nine minutes. Nor does expiry establish that a conflicting endpoint has been removed. It changes what the mechanism does with retained state; it does not reach into the host's provisioning authority.

An automatic release can be a deliberate availability choice. It can prevent a transient event from imposing an indefinite service restriction. It also requires the operator to understand the possibility of recurrence and the scope of the released entry. The alternative of explicit release has its own cost: a corrected service can remain unavailable while responsibility is located or permission is obtained. Neither choice can be evaluated from the word “automatic” alone.

Exceptions further limit generic rules. The specifications distinguish certain IPv6 anycast advertisements, with the Neighbor Advertisement Override flag unset, from the duplicate-IP procedures under discussion. Intentional anycast should not be forced into a narrative of accidental address duplication. The operating policy needs the relevant address behaviour, not just a count of apparent locations.

Compatibility has an operating boundary too

RFC 9721's publication record identifies it as a Proposed Standard published in April 2025. That status does not establish which devices in a particular fabric implement its extended behaviour.

A subsequent errata record, checked on 8 September 2026, makes the distinction unusually concrete. A proposed change disputing the abstract's backwards-compatibility language was rejected. The reviewing Area Director nevertheless acknowledged a limitation when a legacy PE is expected to perform newly specified IP-to-different-MAC mobility. The rejection distinguished an old implementation's lack of the new behaviour from incompatibility of existing route encoding and previously supported behaviour.

This is not an adopted correction declaring the RFC incompatible. It is a reason to ask a narrower operational question: do the relevant devices implement the behaviour on which this recovery plan relies? A product's broad EVPN label does not answer that question. This article has not established a vendor support matrix or tested a mixed-version network.

The same restraint applies to security. The specifications discuss how compromised host-facing traffic can make a legitimate host appear to move and eventually be marked duplicate. An alarm can justify containment without identifying a culprit. Conversely, a desired rapid restoration cannot simply assume that all repeated moves were harmless. Those interpretations require evidence from the actual environment.

Recovery belongs to the service

The distinction between a local action and its consequences is consistent with Heng Lu's account of why BTW exists to describe reality rather than advocate a position. His analysis of agency and incentives offers a lens for asking who can act and who bears delay. It does not supply grounds for attributing registry-specific motives or allegations to an EVPN operator.

Applied here, the question is modest but consequential. Does the incident process reward completion of a local task, or can it follow the service through endpoint correction, retained-state release and usable reachability? A team may perform its assigned operation correctly while the customer remains between those stages.

There is no measured outage duration or universal recovery threshold in this analysis. The source documents describe mechanisms and conditions. The leadership implication is to make the remaining interval visible and owned. Protective state should not persist merely because the correction occurred on somebody else's console; it should not be released merely because that console is the easiest one to reach.