MPLS VPN 中的 RD 与 RT：唯一性与导入策略

两个客户站点都可以通告 10.20.0.0/24，并且在同一个运营商网络内都保持有效。路由区分符让这两条通告彼此区分；路由目标则决定哪个客户 VRF 可以取得副本。二者在配置中相邻出现，却承担完全不同的职责。把它们混为一谈，只会带来看似合理却毫无修复作用的改动。

沿着一条路由从客户边缘走到远端 VRF 分工就变得具体：标识在路由进入 BGP 之前被附加，而分发策略在路由到达接收侧运营商边缘时被评估。

VPN-IPv4 路由由一个 RD 和一个 IPv4 前缀组成

RFC 4364 将 VPN-IPv4 地址族定义为一个八字节的路由区分符，后接一个四字节的 IPv4 地址。RD 被加在客户前缀之前，因此来自不同站点的两个相同前缀会变成两条不同的 BGP 路由。

这一构造就是唯一性机制的全部。运营商不需要客户就互不重叠的地址空间达成一致，一个站点的路由也无法悄悄替换另一站点的相同前缀。

RD 的格式本身是管理员选择的值，通常是一个自治系统号加一个本地号。它的数值形状只是一种惯例，并不表示这两个字段与碰巧使用相同数字的路由目标共享含义。

考虑同一前缀的两条通告。站点 A 携带 RD 65000:101，站点 B 携带 RD 65000:202，两者都针对 10.20.0.0/24。此时 BGP 中持有两条 VPN-IPv4 路由，可以独立比较、过滤和选择。

RD 并不说明哪条路由应该由哪个 VRF 接收，也不标识某个客户或服务。它是路由的标识字段，而不是成员名单。某个 VRF 自身的 RD 无需与它所导入路由的 RD 相同。

这就是为什么把 RD 改成与另一站点的号码一致并不能解决任何问题。如果远端缺少路由，让数字匹配只会制造另一个标识问题，而不是修复导入决策。

导出策略以一个或多个路由目标作为 BGP 扩展团体属性附加到路由上。接收侧运营商边缘会把这些属性与每个 VRF 的导入策略进行比较。RT 随路由在控制平面中传递。比较完全发生在路由策略中，且早于任何客户报文被转发。

客户数据报文并不携带 RT。路由安装进某个 VRF 之后，转发使用的是该 VRF 的表以及架构分配的 MPLS 标签栈。运营商边缘不会从每个客户报文中读取路由目标。

一条路由可以携带多个 RT，一个 VRF 也可以导入多个。配置往往看起来像一小段：

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

把这段配置读成两条独立语句。导出那一行控制离开该 VRF 的路由会附加什么；导入那一行控制该 VRF 愿意考虑什么。数字一致只是方便，并非必需。

一条路由可能对某个 VRF 具有资格，却仍然不出现在其转发表中。资格是一道过滤器；随后常规的 BGP 决策过程会比较有资格的路由并选出一条。较旧或不太受偏好的路由可能输给另一条有资格的路径。

要检查被选中的路由，而不只是导入策略。一个导入 RT 65000:500 却不显示 10.20.0.0/24 路由的 VRF，可能已经收到该路由并在选择阶段拒绝了它，也可能从未收到。

当出现意外前缀时，这一区分同样重要。过宽的导入策略会把站点并不打算使用的路由拉进来，而 RD 的唯一性对此毫无阻止作用。分发范围是 RT 策略的问题。

从通告开始：源 VRF 是否导出了预期的 RT，该路由是否作为 VPN-IPv4 路由存在于路由反射器或接收侧 PE 上？然后按收到时的状态检查属性，而不是按发送侧的配置。

接着把接收侧 VRF 的导入列表与该路由实际的 RT 值进行比较。最后检查该 VRF 中被选中的路由以及标签绑定。每一步回答的都是不同的问题，而直接跳到 RD 往往会漏掉真正出错的那一步。

记录正常站点与故障站点的 RD、导出的 RT、导入的 RT 以及选中的下一跳。四个值并排放置，就能把含糊的“VPN 不通路由”变成控制平面上真正存在差异的那一步。