跨 AS 的 VPNv4：标签转发约定究竟要求什么

在 AS 边界路由器上读一个 VPNv4 标签，只要不知道这次交接实现的是哪一种跨 AS 模型，能看出的东西就很少。标签本身并不是路由自身的属性；它记录的是两台路由器之间关于封装与投递的一项约定。先判定模型，再去读显示结果。否则，你调试的是一份没有人写下来的约定。

边界实现的究竟是哪一种模型

VRF 到 VRF 的对接方式通过路由化接入把相互匹配的 VRF 连接起来。双方都把对方视为客户边缘邻居，交换普通的 IPv4 路由，因此那个边界上不需要 MPLS。

第二种方式是在边界路由器之间直接交换带标签的 VPNv4 路由。这只有在整条互联链路上存在一致的标签交换路径，并且双方都接受同一套路由目标分发与信任模型时才成立。只要缺了其中任何一块，这个模型就没有真正在用，无论配置看起来如何。

第三种方式分发带标签的 PE 可达性，而 VPN 路由则在端点之间或跨 AS 的路由反射器之间传递。这三种方式在边界上留下的工作各不相同，把其中一种的控制平面与另一种的接口假设混在一起，就是典型的失败。这种错配通常表现为：标签在一侧看起来正常，到了另一侧却消失了。

端到端读一条前缀

挑一条已获授权的客户前缀，把它走一遍。看看通告出去的是什么、收到的是什么、下一跳、标签，以及放行它的导入策略。然后去看路由器如何解析通往该下一跳的转发，因为标签正是在那里变成数据包的。跳过任何一半，你描述的都是一个可能并没有在转发流量的控制平面。这两方面的读数只有合在一起才有意义。

这个数字是本地的。它的含义只相对于分配它的那台路由器，以及把数据包送到那里的路径，这就是为什么同一个值可以出现两次却表示两件不同的事。把它与接收方声称收到的内容做比较。

标签是本地的，承诺也是

能力要在互联链路的两端都检查，而不是只查一端。在你自己的接口上敲命令，对相邻提供商的接口毫无影响；BGP 接受了某条路由，本身也不等于邻居承诺转发带标签的数据包。

RFC 4364 把带标签的 VPNv4 对等关系限定在可信安排之内，并警告不要接受从未向该对等体通告过的标签。这既是协议层面的表述，也是安全层面的表述。要把公网互联网的路由关系与私有的 VPN 路由交换分开。如果互联链路只是普通 IP，就不要指望任何标签能穿过它。而在链路带标签的地方，要确认外层传输标签在每一跳都被正确交换。

标签在一侧看起来正常、到另一侧却消失，通常就是那种错配，而不是路由故障。

验收时要写下什么

验收是一次数据包测试，而不是一次表项复核。让一个客户数据包进入远端 VRF，再让它的回应走回来，然后写下这次交接实现的是哪一种模型。还要加上两侧的交接负责人，以及边界承载的是普通 IP 还是带标签的流量。

这条记录能让下一位操作员正确地读懂同一份标签显示。没有它，模型就只能从配置里推断，而推断出来的假设正是同一个错误被反复重犯的原因。RFC 4364 的跨 AS 章节才是确定原本想要哪种模型的地方。