MPLS L3VPN 实验环境 ping 不通？依次检查五个节点

两台客户路由器、一对运营商边缘设备，以及一个没有任何错误提示就消失的 ping。在小型 MPLS L3VPN 实验环境里，故障几乎总是落在五个检查点之一，而每个检查点都有一条命令，能显示该依赖关系是通的还是缺失的。常见的错误是每次 ping 失败就重启 BGP，而不是按顺序测试这些依赖。直接跳到 VRF 配置，你可能会在一个源于两台设备之外未解析下一跳的问题上耗掉一小时。

从下往上逐条走这个清单。已经通过的检查点保持通过，第一个失败的地方才是值得调试的。

第一个检查点：两台 PE 能互相到达

每台 PE 都需要一条通往对端 PE 环回口的路由，而这条路由必须解析到某个真实存在的东西上。内部网关协议是常见做法，但只要递归查找落在活跃的邻接上，静态路由同样可行。在 IOS 风格的设备上，show ip route 10.0.0.2 之后再执行 show ip cef 10.0.0.2，就能看出该前缀是否存在、是否具有已解析的邻接。表里有一条路由、背后却没有邻接，那不叫可达。

两个方向都要查。IGP 开销不对称、错误一侧的被动接口，或者一条把环回口过滤掉的分布列表，每一种都只破坏一个方向，而一个方向就足以让会话中断。如果环回口能 ping 通、BGP 会话却停在 Active，先看更新源，再动别的地方。

第二个检查点：存在标签路径

通往远端环回口的 IP 路由并不能证明传输层会压入标签。在 LDP 设计里，要确认远端环回口既有本地绑定也有远端绑定，并且出标签出现在转发表中。show mpls ldp bindings 10.0.0.2 32 显示标签对，show mpls forwarding-table 10.0.0.2 显示线卡实际会压入什么。当第二条命令显示「no label」或者把报文打回 IP 转发，说明传输层并没有按设计假设的方式承载 VPN 流量。

这个区别来自 MPLS 把转发状态与目的前缀分离的方式，也就是 RFC 3031 中描述的模型。如果你的实验环境用 RSVP-TE 或与 BGP 相邻的标签而不是 LDP，就去查那套机制自身的状态；假定 LDP 会分发每一条底层标签，是追逐幽灵缺陷的常见做法。断掉的标签路径通常会在之后表现为一条存在却不可用的 VPN 路由。

第三个检查点：VPN 路由完整到达

要看针对确切客户前缀的 VPNv4 或 VPNv6 路由，而不是会话摘要。show bgp vpnv4 unicast all 10.10.1.0/24 应当显示路由区分符、指向远端 PE 环回口的下一跳，以及一个标签。如果前缀缺失，源端 PE 的导出策略或接收端 PE 的导入策略是第一个嫌疑对象，而路由目标通常是元凶。

把路由目标的检查与 BGP 的接收分开来读。一条路由可以带着正确的下一跳到达，却因为导入目标不匹配而进不了 VRF。在接收端 PE 上，show ip route vrf CUSTOMER 10.10.1.0 才是真正有意义的测试；BGP 表只能证明这条路由穿过了控制平面。

第四个检查点：接口在 VRF 里

带路由区分符和路由目标的 VRF 定义，并不会把任何接口搬进去。面向 CE 的接口需要 VRF 指派，show ip vrf interfaces 或 show ip interface brief 应当把它列在正确的实例下。这是照抄配置最容易出错的地方，因为 VRF 块看起来完整，接口却仍然待在全局表里。

然后确认 PE 已把本地客户前缀学到那个 VRF 里，并且 CE 有一条经该接入链路回程的路由。CE 上一条指向 PE 的静态默认路由对实验环境就够用，前提是 PE 的 VRF 里有通往 CE 局域网的路由。只要缺了任何一半，ping 在压入任何标签之前就会失败。

第五个检查点：回程找到回家的路

先追踪去程报文，再追踪回程报文，因为它们用的是不同的表。在入站 PE 上，客户源地址应当在该 VRF 内解析到远端前缀并使用远端标签。在出站 PE 上，目的地址应当在同一 VRF 内解析到面向 CE 的接口。从 PE 本身发起的 ping 不算证据：它可能走全局表或另一个源地址，所以 ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1 才是应该跑的测试。

主机防火墙、反向路径过滤和 CE 访问列表依然起作用。如果去程通、回程死，问题在返回侧的某条路由或过滤器上，而不是 MPLS 传输。

为每个检查点保留一行记录，写明第一个失败的依赖。这条记录会把「客户 ping 不通」变成关于可达性、标签状态、路由导入、接口归属或返回路径的具体问题，也能让下一次调试不必再按同样的顺序重复那五条命令。