RSVP-TE 隧道通了，但客户 L3VPN 没有路径

传输与服务是两个独立的判断。先读标签栈，分别检查下一跳解析和 VRF 挂接，然后再测试一条真实的客户流。

当客户报告 VPN 不通、传输团队却报告隧道正常时，两个团队可能都没错。流量工程 LSP 和 MPLS L3VPN 回答的是不同问题：一个负责把带标签的报文送过核心，另一个决定报文属于哪个路由上下文。两者混为一谈，争论就会绕圈，因为双方测量的对象不同，而两种测量都成立。

传输正常而服务中断是常态

LSP 可以已建立、承载流量、在所有监控系统中可见，而客户服务仍然不可用。这种组合并不矛盾，因为隧道并不关心远端前缀是否存在、导入策略是否接受它、接入电路是否在转发帧。

通常暴露这种混淆的症状是不对称的：从 PE 环回口 ping 得通，而客户 LAN 上的一台主机却什么都收不到，或者反过来。在形成假设之前，先记下哪些地址是通的。一旦意识到自己在测两个不同的对象，下一步就是去读标签栈，而不是争论谁的图对。两个地址、两个负责人，通常还是两个都认为对方弄坏了什么的人。

把标签栈读成两层责任

底层标签属于服务，顶层标签属于路径。RFC 4364 把这个顺序讲得很直白：先压入 VPN 路由标签，再把这个带标签的报文朝 BGP 下一跳做隧道，流量工程隧道正是在那里压上自己的标签。

ObjectDecision it encodesWho owns it
Attachment and VRFWhich customer context receives the arriving packetEdge configuration
VPN route and service labelWhich remote forwarding context handles the destinationBGP VPN signalling
Transport LSP and tunnel labelHow the core carries the packet to the BGP next hopRSVP-TE or another tunnel mechanism

在远端 PE 上，服务标签决定处理方式，可能是查 VRF，也可能是做挂接判断。这个标签不能换成仅仅穿过核心的标签，即使两者出现在同一接口的同一个栈里，也不能互换。

RSVP 成功证明了什么、没证明什么

RSVP-TE 建立显式路由的 LSP，带或不带资源预留，这是对报文穿过核心所走路径的具体而有用的保证。它不是关于客户路由的声明，而配置的隧道名称根本不是路由。

RSVP 的存在也不提供端到端性能承诺。一条 LSP 上的带宽预留，说明不了接入电路、客户自己的接入线路，也说明不了远端边缘的排队行为。把它当成保证，会对没人提出的问题给出自信的答案。如果需求真的是带宽承诺，就必须由真正能强制执行它的部件拼出来，而 LSP 只是这条链的中间一环。

按顺序检查，然后停下

从传输往外查，在第一个失败的步骤停下，因为后面的每一步都以前面的步骤成立为前提。先确认 LSP 已建立，并且服务前缀的转发表项确实指向它。再确认 VPN 路由在正确的表里、标签绑定存在、导入策略已接受。然后确认挂接：接口、封装，以及在适用时的、属于该合同的 VLAN 标识。

show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER

命令语法因平台而异，所以把那四行当成四个问题，而不是一段脚本。重要的是每一行问的是不同对象，正因为如此，故障才能指向具体的负责人。

跟一条被允许的请求走完，并保留好证据

最后用一条真实的、策略允许的客户请求及其应答收尾。一条端到端可用的流，胜过一页计数器读数，它检验的是组合，而不是每个部件单独的表现。

后段失败时，保留 LSP 正常的观测结果，而不是重建传输。重建一条本来正常的隧道修不好缺失的远端前缀、错误的 VRF 挂接或目的访问规则，反而会毁掉当初告诉你传输健康的那份证据。

相关文章