EVPN 起来了，服务却没起来：四个检查点

能到达远端 VTEP 地址，只能证明底层网络能转发报文，仅此而已。租户服务需要的是：地址族正确的 BGP EVPN 会话、已挂接并处于运行状态的本地 VNI、已产生的路由，以及对端的导入。这是四个彼此独立的检查点，修复手段各不相同。把底层全绿当成服务就绪，是 EVPN 开通卡住最常见的原因。

按顺序读，遇到第一个与设计预期不符的点就停下。后面的检查点无法弥补前面的失败。

检查点 1：到 VTEP 的承载

先看作为 VTEP 源的 loopback 地址之间是否可达。路由必须在底层存在，路径必须被放行，包括任何封装要求，回程路径也必须通。路由存在但只在一个方向被过滤，会产生看似间歇性的非对称故障。继续之前，两个方向都要确认。

记录你检查过的源地址和目的地址。后续某一步若用另一个地址解析下一跳，那是另一个测试；把两者混为一谈，就会让已解析的下一跳替承载故障背锅。

检查点 2：EVPN 地址族，而不是会话数量

BGP 会话建立，不代表 EVPN 地址族已经协商。要看邻居的地址族专属状态：地址族是否启用、是否与对端协商成功、会话到底有没有承载它。一条只为 IPv4 unicast 建立、从未协商 EVPN 的会话，在常规邻居摘要里看不出任何异常，而EVPN 覆盖层规范本就把服务与控制流程视为独立于承载的问题。

也要检查会话的源地址。若对等体是用并非 VTEP 源的地址建立的，那就是一处设计不一致，迟早要用来解释转发故障。

检查点 3：本地服务已挂接

本地 VNI 必须挂接到代表该租户的网桥或 VRF 上，平台必须把它报告为运行状态。复制模型所用的成员状态在任何主机 MAC 学到之前就可能起作用，所以端点表为空不能作为服务已停的证据。

然后确认设备实际产生的是什么：该 VNI 的本地路由，以及设计规定的 route target。只挂接而不通告的 VNI，只会在本地存在，别处都没有。

检查点 4：接收端的导入

在接收设备上，比较导入与导出的 route target，而不是比较数字形式的 VNI。VNI 编号相同，并不证明接收实例导入了该通告；route target 不匹配，在 VNI 列表里根本看不出来。信任转发表项之前，先通过底层把通告的下一跳解析出来。然后读该服务的覆盖层转发状态，而不是整台设备的状态。

对等体表也可能反映实现相关的数据面或成员学习信息。要结合 EVPN 路由去读它的来源与服务上下文，而不是把行数当成证据。

一条记录走完整条路径

每个服务保留一条记录：本地 VNI 状态、EVPN 邻居与地址族、产生的路由，以及接收与导入的结果。让这条记录从产生一路走到安装。出问题时，记录会告诉你该修四个检查点中的哪一个，而不是该试哪条命令。

做这些时顺手打上时间戳。通告之后几分钟才出现的导入，是策略或收敛问题；始终不出现的导入，是配置问题。只有记下你何时查看，这个差别才看得见。

什么时候静态 VXLAN 才是正确答案

静态配置的 VXLAN 数据路径，可以在 EVPN 表为空的情况下配合手工指定的对等体工作。那不是 EVPN 部署坏了，而是另一种控制模型。在把空表判定为故障之前，先确定设计想要哪一种。

底层的 IGP 邻居只提供承载，别的都不提供。覆盖层的服务状态，是另一件要建设、也要另一套方法去验证的事。