摘要

  • 重复地址的纠正与网络保留状态的解除，是恢复过程中的不同动作；前一个完成，不代表后一个必然随之完成。
  • 重复的是 MAC 地址、不同 MAC 对应的同一 IP，还是只通告 IP 的主机路由，会改变应处理的对象，不能用一个笼统的“主机故障”替代。
  • 规范中存在计时器解除重复状态的安排。管理问题不是一概排斥自动恢复，而是明确它释放什么、还留下什么，以及谁承担这段时间的服务后果。

一张工单可以先于一次服务恢复结束。

设想一个并非来自真实事故的场景：平台团队发现多余的虚拟机使用了冲突地址，删除了错误实例，并确认该地址分配已被纠正。网络团队看到的却是另一种状态——相关路由仍处于冻结之中。前者并没有虚报工作，后者也不一定操作失误。双方可能都准确描述了自己掌握的一段现实，只是客户需要的完整结果还没有出现。

这个间隔值得成为管理对象。企业往往把恢复能力理解为检测得快、定位得准、有人会执行命令，却较少单独核算“根因已经纠正，保护状态仍在等待解除”的时间。它可能很短，也可能被交接、权限或者对机制的误解拉长。没有具体环境和测量，无法给它一个统一时长；但 EVPN 的规范足以说明，这段时间不能被概念上抹掉。

关键并不在于必须设立两个团队。一个工程师也可能同时拥有主机和网络权限。关键在于两个控制动作有不同对象：一个改变端点上的地址安排，另一个处理网络为了应对冲突而保留的状态。同一个人操作，并不会让它们变成同一件事。

冻结是保护动作留下的状态

EVPN 通过边缘设备之间的控制平面通告传播端点可达信息。端点从一个以太网段移动到另一个网段时，新旧位置的通告可能暂时并存。RFC 7432 定义的 MAC 移动机制使用序列号，帮助参与设备处理先后关系，并触发旧通告撤回。

地址重复会使这套机制遇到另一种压力。两个端点在相关广播域中使用相同 MAC，它们发送的流量可能让网络不断观察到“移动”。规范因此描述了可配置的计数和时间阈值：达到条件后，设备告警，并停止发送和处理该 MAC 的相关 MAC/IP 通告，等待操作人员采取纠正措施。这里的作用对象是相关地址，不是整张网络。其他边缘设备仍可能把流量发往通告该地址的某个位置，不能把告警直接理解为全网转发已经停止。

还必须分清移动与多归属。同一个端点通过同一以太网段连接多个边缘设备，可以是正常的冗余设计。规范利用网段标识处理这种情况，避免把同一多归属站点内的学习事件误判成跨网段移动。看到多个设备知道同一个地址，不足以得出部署出错的结论。

这也解释了为何“冻结还没消失”不一定是系统遗漏。它可能恰好说明保护机制按设计保留了决定。过早解除和过晚解除分别产生不同后果，不能只根据控制台是否清爽判断哪一种更好。

先知道冲突的是什么，再决定纠正什么

RFC 9721 把 EVPN 的集成路由与桥接移动机制扩展到更复杂的地址绑定变化。虚拟工作负载重新创建后，IP 可以不变而 MAC 改变；多个合法 IP 也可能在一个物理主机或中间设备后共用 MAC。共享 MAC 本身并不是地址冲突的同义词。

该文件把重复检测分成不同情形：MAC 相同；IP 相同但 MAC 不同；以及网络只通告主机 IP、并不通告主机 MAC 的纯路由场景。这样的区分直接影响恢复目标，而不是仅仅改变告警名称。

在 MAC 重复的情形下，相关 MAC-IP 路由继承重复状态。若是不同 MAC 对应同一个冲突 IP，应处理相应的 MAC-IP 路由，不应仅凭这个 IP 冲突，就把相关 MAC 路由以及共享该 MAC 的其他 IP 一起视为重复。恢复前需要明确的是具体绑定、所在位置和预期保留的端点，而不是一句没有对象边界的“清理主机”。

告警位置也不能替代这个判断。RFC 9721 讨论的恢复情形，既包括从冻结位置移除重复端点，也包括从未被冻结的位置移除重复端点。显示限制的地方，未必就是业务上应该删除实例的地方。究竟哪一个实例承担预定工作，仍需地址配置和工作负载管理方面的知识。

这不是要求运维人员在协议之外另行创造地址权利。它只是要求实际恢复动作能够接上企业对预期运行状态的认识。网络知道自己检测到了什么，与企业知道应该留下什么，分别回答不同的问题。

主机纠正完成后，网络还有自己的恢复顺序

RFC 9721 第 8.4 节把移除其中一个重复 MAC 或 IP 分配明确放在主机侧。纠正完成后，重复状态仍可能要等到老化，除非采用额外动作加快恢复。

文件随后区分了路由解冻与路由清理。解冻可以使相关通告携带高于另一位置的序列号，由此推动设备重新处理可达信息，并通过 ARP 或邻居发现探测清除过时的本地状态。重复端点究竟在哪一侧被移除，会影响这一过程如何展开。

清除一条本地 MAC 路由，或者清理 ARP、邻居发现条目，是另一种操作。尤其在未被冻结的位置进行清理，并不必然免除另一侧的解冻工作。因此，一个命令完全可能成功完成其本地任务，却没有独自完成整个恢复过程。这里没有一个通用于所有厂商的命令，可以让操作者跳过对位置和状态的理解。

对管理者而言，重要的并不是记住命令语法，而是让交接能携带完整的问题：在哪个位置纠正了哪个地址分配，预期留下哪一个实例，还有什么状态等待处理，计时器是否已经承担了其中一部分工作。这个交接可以非常简短，但不能只留下“处理完毕”。

还应考虑纠正是否持久。设想编排系统的期望配置仍要求创建那个多余实例，那么删除当前实例之后，它可能再次出现。这只是分析中的假设，没有指向任何已经验证的产品行为。它说明的责任边界却很清楚：能删除正在运行的对象，不一定等于已经改变了使对象重新出现的配置来源。若这一点未被查清，网络侧更快的解除限制，可能只会更快地迎来下一次争用。

自动恢复并不天然站在错误的一边

把以上问题概括成“所有冻结必须人工解除”，同样会误读规范。RFC 9161 针对 EVPN 中的代理 ARP、邻居发现功能，描述了重复 IP 状态可由操作人员纠正后清除，也可在保持计时器到期后清除。文中给出的该计时器默认值为 540 秒，相关参数可以配置。

这是特定代理功能中相应状态的规则，不是对所有设备上的所有冻结 MAC 路由作出的九分钟恢复承诺。计时器到期也不意味着它已经进入主机管理系统，替操作者移除了冲突实例。它改变的是保留状态如何继续影响网络，而不是自动证明主机侧发生过纠正。

计时器解除可以是一种经过选择的可用性政策。它避免短暂异常把限制无限期留在服务上，同时也需要接受状态解除后仍可能再次发生冲突的风险。明确人工解除则有另一种成本：即便主机问题已经消除，服务也可能继续等待有权限、有上下文的人。两者都不能只靠“自动”或“人工”这两个标签评价。

此外，规范对特定 IPv6 任播行为另有区分，包括邻居通告中 Override 标志未设置的情况。不能看到同一 IP 出现在多个位置，就把有意设计的任播纳入错误地址分配的叙事。恢复政策需要知道实际采用的地址行为，不能只看位置数量。

版本兼容也要落实到具体行为

RFC 9721 的发布记录将其列为 2025 年 4 月发布的建议标准。这一地位能够说明文件处于什么规范阶段，却不能说明某个实际网络中的所有设备已经实现了扩展机制。

截至 2026 年 9 月 8 日查阅的勘误记录提供了一个有用边界。一项要求修改摘要中向后兼容表述的提议被驳回，但审阅的领域负责人同时承认：如果在混合部署中要求旧设备完成新增的“IP 移至不同 MAC”行为，就可能遇到局限。驳回理由区分了旧实现缺乏新能力与原有编码、原先支持的行为无法互操作。

因此，不能把这条被驳回的建议当作已采纳的规范修正，宣布 RFC 不兼容；也不能把“兼容”两字解释成任何旧设备都能执行新恢复方案。对于实际决策，应该问的是：这次移动和恢复涉及的设备，是否具备方案所依赖的具体行为？本文没有调查厂商支持矩阵，也没有测试某个混合版本网络。

安全判断同样需要保持边界。规范讨论了被攻陷的主机侧流量可能使合法端点看起来反复移动，最终被标记重复。这个风险值得防范，但一个阈值结果不能自动识别责任人。另一方面，恢复时间的压力也不能把所有重复移动都默认解释为无害。判断应来自实际环境中的证据。

客户等待的是结果，不是两个各自正确的结论

Heng Lu 关于 BTW 应描述现实而非从事倡导的论述，要求把机制的真实作用与愿望分开。他对代理关系和激励的分析，也提示我们追问谁能够采取行动、谁承担行动之间的延迟。这是本文采用的观察方法，并不是把他对注册机构的判断移植给 EVPN 工程师。

应用到恢复管理，问题并不复杂：企业记录的是两项局部任务完成，还是一项服务穿过了地址纠正、保留状态解除和可用性验证的全过程？两边都完成了各自的职责，客户仍然等待，在逻辑上完全可能成立。

本文没有给出真实事故时长，也没有提出适用于所有网络的恢复阈值。它把规范中已经存在的恢复环节，转化为一个可以明确交接的管理对象。限制不应仅仅因为纠正发生在另一套系统里而无人接手；解除也不应仅仅因为某个控制台容易操作就被当成完整修复。真正需要接住的，是这两种便利判断之间的恢复窗口。