沉默的 EVPN 主机始终解析不了：顺着 ARP 追到绑定

端点已经接入，端口也处于 up 状态，监控主机却仍然访问不到它。有人从对端发一个 ping，它就通了，于是问题看起来时好时坏，fabric 也显得毫无责任。这种模式正是沉默主机的典型特征：它很少发送，因此 fabric 的发现与刷新行为比它的接入状态更重要。请选一个目标 IP、MAC 和 bridge domain，沿着下一次解析交互往下查。

追踪下一次 ARP 或 ND 交互

对 IPv4，观察发起请求的主机的 ARP 交互；对 IPv6，追踪 Neighbor Solicitation 与 Advertisement。确认请求进入了预期的本地网段和预期的 VNI，因为一个从未到达正确 bridge domain 的请求，任何代理都无法应答。

然后看 fabric 对目标知道什么。只有 MAC 的路由可以识别 Layer 2 目的，但代理此时还没有它的 IP-to-MAC 绑定。这是两条独立的记录，查其中一条并不能说明另一条。

如果存在有效绑定，代理可以按策略应答，但 该绑定中的 MAC 仍然需要一条生效的转发路径。如果绑定缺失，请求必须先经由 flooding 或复制路径到达端点的接入点，之后才有东西能从应答中学习。

必须互相吻合的两条记录

MAC 路由回答以太网地址在哪里。代理表回答哪个 IP 映射到哪个 MAC。最近没有发过话的主机，完全可能有一条完好的 MAC 路由，却没有可用的代理表项，而这正是健康接入上出现解析失败的根源。

在远端接入点，确认端点是否真的收到并回应了这次交互。它的应答会刷新本地学习和相应的 EVPN 通告，所以手动 ping 看起来能修好问题：你制造了 fabric 一直在等的流量。这也解释了为什么这种修复不持久：刷新后的表项一旦老化，端点又重新沉默。定时 ping 只是在治标，并把设计上的缺口藏了起来。

收到应答后，沿选中的路由和已安装的转发表项往请求方回溯。解析成功和转发成功是两件事，把两者混为一谈的工单会把你带到错误的层次。

标准究竟假设了什么

RFC 9161 描述了动态代理学习，以及对未知 ARP 和 ND 请求的默认 flooding。完全抑制这种 flooding 只适用于那些学习或预置假设使其安全的部署，这个条件比大多数配置指南所暗示的要窄得多。

期望发现新端点的 fabric，必须为这些请求保留一条可用的路径。如果有人为了减少 BUM 流量而关掉了未知请求 flooding，沉默主机就是为此付出代价的那部分，症状会在几周后以间歇性可达性投诉的形式出现。

把抑制配置读成 fabric 关于自己承诺知道什么的声明。如果没有任何东西预置这些绑定，这个承诺对不常发送的主机就不成立。把配置的抑制与本应供给它的预置系统对照。两者不一致时，fabric 的行为完全符合配置，需要修正的是预期。

刷新、老化与静态替代方案

标准描述了在动态表项老化之前可用的刷新探测。应答会刷新相应的 bridge 和代理状态；没有应答则可能合理地导致删除与路由撤回。这不是靠拉长每个定时器就能压下去的缺陷。

无限延长老化定时器，等于用一个过期故障换掉一个可见故障：fabric 会持续通告主机已经离开的位置。请使用实现中记录的控件，并选择一个与端点合理发言频率相匹配的生存时间。

对于已知且受管理的端点，静态或由控制器预置的绑定是合理的第二种模型。它需要有负责更换与迁移的属主，因为主机换到别的端口时，预置记录不会自己更新。

下一张工单之前要记录什么

把绑定的来源、最近刷新时间、当前位置以及任何撤回事件，和 MAC 路由放在一起。这份记录回答了工单真正要问的问题：应用是在等发现、在依赖过期状态，还是解析成功之后转发出问题。

然后决定你愿意运营三种模型中的哪一种。带 flooding 的发现、使用现实生存时间的刷新，或带属主的预置，都是站得住脚的。为一种模型配置、却被期望像另一种那样工作的 fabric，正是沉默主机消失的地方。