端到端验证命令组合
L3VPN 的交付验证要三样一起看：实例内是否有路由、标签转发面是否就绪、端到端报文是否真的通。只做 ping 相当于只验了最后一环，一旦不通很难判断是路由没进来还是标签没准备好。把三条命令按顺序固定下来，验证过程本身就变成了排查流程。
基本信息
| Cisco ping | ping vrf <实例> <目标> source <实例内地址> repeat <次数> |
|---|---|
| Cisco traceroute | traceroute vrf <实例> <目标> |
| 标签核对 | show mpls forwarding-table <关键前缀> |
| 路由核对 | show ip route vrf <实例> <网段> |
| 建议归档 | 时延、丢包与路径快照一并记录，作为验收依据 |
典型使用场景
- 客户交付验收：按固定命令组合逐项打勾，交付证据可追溯
- 故障定界：区分管理侧问题与客户侧问题，避免互相推诿
- 割接后回归：对每个客户逐个实例验证，防止遗漏
- 性能基线建立：记录时延与丢包的正常区间，供后续对比
- 方案评审举证：用实际输出说明转发面已就绪
组合验证与核对顺序
组合验证与核对顺序
# 1) 路由面：实例内是否有目标网段
show ip route vrf CUST-A 10.10.2.0
# 2) 转发面：标签行为是否就绪
show mpls forwarding-table 10.10.2.0
show ip bgp vpnv4 all labels
# 3) 端到端：指定源与次数，记录时延与丢包
ping vrf CUST-A 10.10.2.2 source 10.10.1.1 repeat 20
traceroute vrf CUST-A 10.10.2.2验证记录表
| 验证项 | 命令 | 判定依据 |
|---|---|---|
| 实例内路由 | show ip route vrf | 目标网段存在，下一跳为对端 PE 或 CE |
| VPN 标签 | show ip bgp vpnv4 all labels | 已分配且与对端协商一致 |
| 转发行为 | show mpls forwarding-table | 出标签与下一跳指向正确路径 |
| 端到端 | ping vrf + traceroute | 丢包稳定、时延在基线范围内、路径合理 |
ping 不指定 source 时源地址由系统选择，可能不具代表性。验收与故障复现都应显式指定实例内的源地址，并在记录里写明，便于日后按同一口径复测。
客户有多条 PE 接入时，验收要覆盖全部接入点而不只是当前在用的一条：备份 PE 上的实例、标签与策略同样需要确认，否则切换发生时才发现问题。
每次验证的命令输出按客户名归档：同一客户日后再次报障时，可直接与历史输出逐项比对，路由、标签或属性的变化往往一眼可见，比从零开始查快得多。