BGP 会话正常，客户路径不通：DMVPN 上的 MPLS

对等会话已经建立数周，前缀数量看起来正常，可某个客户的流量仍然绕远路，或者根本到不了。 同一个指标正在评判两件不同的事。BGP 会话只说明两个对端能通过一条 TCP 连接交换消息；它完全没有说明叠加层能否为该客户承载带标签的报文。

这个缺口在 MPLS over DMVPN 设计中看得最清楚：经由中心节点的路径与直连分支的路径可能表现得不一样，而原因与对等会话毫无关系。

会话究竟证明了什么

BGP 跑在 TCP 之上，因此在其他事情发生之前，每个对端都需要一条通往另一端地址的路由。选 loopback 作为这个端点，你建立的是可达性要求，而不是转发保证。于是会话可以经由一条客户流量永远不会使用的接口保持在线。

下结论之前，先在两端各记下四个事实：会话的源地址、目的地址、它所在的选路上下文，以及内核或路由器会为这对地址选择哪条接口。这些事实描述的是控制平面。客户报文在其之上还叠加 VRF、标签栈和叠加层映射。

四种机制，而不是一种

Cisco 关于 MPLS over DMVPN 的文档把这些部件分得很清楚。MP-BGP 在服务商边缘设备之间分发客户的叠加层标签。MPLS 用这些标签为报文选择转发上下文。NHRP 把叠加层地址映射到动态隧道所需的传输端点。IPsec 在适用处保护对端路径。

四者中任何一个正确，另一个仍可能出错，而承载流量的正是这个组合。路由交换可能已经完成，但某个 VRF 的标签绑定缺失；NHRP 映射可能指向过期的传输地址；隧道存在，却没有任何策略允许内层报文通过。这些状况都不会让会话中断。

把中心路径与捷径做对比，一次只改一个变量

固定源主机、目的主机和 VRF，然后把同一条流追踪两次。在中心路径上，记录下一跳、标识远端客户上下文的服务标签，以及正在使用的叠加层到传输的映射。在预期的直连路径上，记录同样的三样东西。两份清单的差异就是故障所在，或者说明故障并不存在。

对比过程中保持流量不变。在两次观察之间更换源主机、VRF 或目的地址，会得到两个互不相关的故事，而这正是这个练习最常见的失败方式。

把 loopback 测试放进它自己的隔间

从路由器 loopback 发出的 ping 是有用的测试，它检验的情形与来自主机的流不同。源地址属于路由器，其选路上下文可能是全局的而不是某个 VRF，返回路径也可能与客户前缀会走的路不同。因此 loopback 有回应和应用能走捷径是两个独立的结果，只有后者才描述客户。

两者都测，然后在你的记录里分别标注。当它们不一致时，你学到的是关于设计在何处分叉的具体信息，这比一个绿色对勾能告诉你的多得多。

版本主张与缺陷主张各自需要证据

现场报告有时建议修改主机掩码或 BGP 源地址，而这类报告只有与它所针对的缺陷以及受影响的版本一起读才有意义。某个版本的变通做法，并不等于声明该架构不支持任何 /32 前缀。

使用与你 DMVPN 阶段、平台和版本相匹配的文档，并记住一章可能覆盖多种编排方式，包括 FlexVPN。某种编排方式的示例不会悄悄迁移到另一种。按你真正需要的控制平面设计来选择会话端点，然后单独验证客户的转发路径，因为重写每个 loopback 掩码并不能代替查明是哪项工作失败了。