为什么一个 EVPN 租户会显示多个 route distinguisher

你为一个租户筛选 EVPN 表，结果路由带有两个不同的 route distinguisher。第一反应是配置冲突，而这个反应通常是错的。租户名是业务标签，不是控制平面里的单一对象，因此其中的桥接上下文和路由上下文完全可以分别用不同的标识符来通告。一次只沿一条路由，从输出回溯到产生它的本地服务对象，第二个 RD 就不再像是错误了。

从让你困惑的那条输出开始

选一条路由，而不是整张表。记下它的路由类型、RD、导出的 route target 以及下一跳。这四个字段足以确定是哪个本地对象通告了它，以及哪条远端策略应当导入它。

在 NX-OS 风格的设备上，用下面的命令进入详细视图：show bgp l2vpn evpn route-type 2 detail 或 show bgp l2vpn evpn route-type 5 detail。在 Junos 上，同样的信息出现在 show route table bgp.evpn.0 detail。语法不同，字段相同。

不要一上来就把界面上显示的每个数字改成一样。把 RD 改成一样，恰恰是会在正常运行的 fabric 上弄坏导入策略的那种改动。

给每个标识符各自的职责

MAC-VRF 保存桥接服务的 MAC 转发表项。IP-VRF 为被路由的服务提供 IP 路由上下文。一个租户可以同时包含两者，所以同一个租户在没有任何配置错误的情况下也能产生不止一个 RD。

RFC 7432 把通告方 MAC-VRF 的 RD 分配给它对应的 EVPN NLRI，并要求同一台 PE 上的不同 MAC-VRF 使用不同的 RD。route-target 的流程是分开的：它允许一个或多个 RT 属性，成员关系由导入策略决定。造成共享成员关系的并不是 RD 相同，把它当成同一回事正是这一困惑的根源。

沿一条路由从通告走到导入

沿着一个方向跟踪这条路由。确认路由类型、产生它的服务、RD、导出的 RT，然后确认接收端 PE 上的导入策略。每一步回答的问题不同，任何一步出问题，在对端看起来都是同样的前缀缺失。

路由存在之后，检查已经安装的转发表上下文和 VNI 映射。两端 VNI 一致，说明数据平面是一致的；它并不能说明控制平面是按预期策略导入这条路由的。

如果路由出现在远端 PE 上，但流量不通，问题就已经超出了 EVPN。再次修改 route target 之前，先检查 VNI 到 VLAN 或 VNI 到 VRF 的绑定，以及 underlay 路径。先看映射，再看 underlay，最后才看控制平面。为了追数据平面的故障而回滚 route-target 改动，是弄坏一条正常导入的可靠办法。

3 层前缀依然是 EVPN 路由

EVPN 表里的 IP 前缀不是普通的 IPv4-unicast BGP。EVPN IP Prefix 路由是它自己的路由类型，而 MAC/IP 与 IP 前缀的通告走的是 EVPN 地址族，RFC 7432 将其标识为 AFI 25 和 SAFI 70。

当你把 EVPN 表里的一条路由和单播表里的一条路由对比时，这个区别很重要。它们可能描述同一个目的地，却由不同的策略产生、过滤和导入。把其中一个当成另一个的证据，正是正确的 fabric 在迁移期间看起来像坏掉的原因。

在比较数字之前，先查厂商的推导方式

RFC 9136 用 IP Prefix 路由扩展了 EVPN，并规定适用的 RD 来自 MAC-VRF 还是 IP-VRF 上下文。所以同一份输出里的 L2 服务标签和路由服务标签，应当对照它们所属的对象来读，而不是简化成每个租户一个 RD。

RD 和 RT 的自动推导因厂商而异。请查阅所部署厂商关于所用公式的文档；在一台交换机上看到的自动生成值并不是通用编码，比较两家厂商的数字也很少能证明什么。

最后为最初那条路由写一份书面追踪：类型、产生它的对象、RD、导出的 RT、导入策略、已安装的 VNI。六个字段就能向接下来读工单的人解释这次通告，而且其中任何一个都不需要让租户的数字变得一样。