MPLS 分支路由：CE 学到什么，从谁那里学

一个分支的主机向另一个分支的服务器发起连接，两个站点位于同一张受管的 MPLS 第 3 层 VPN 之后。主机只知道自己这边的默认网关，其他一概不知，这是正确的。关键在于本地客户边缘把数据包交给自己的运营商边缘，再由运营商的 VPN 路由状态把它送到拥有目标前缀的那个分支。

沿着路径跟踪一个数据包，是看清哪一段属于客户责任、哪一段属于服务本身的最快办法。

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

每一跳的职责到哪里结束

CE-A 需要一条指向本地运营商接入、而不是远端分支 WAN 地址的远端 LAN 路由。随后运营商用 VPN 路由状态把数据包穿过自己的骨干，CE-B 再把它送到目标 LAN。任何环节都不需要主机去理解标签、VRF 或对端的互联网线路。

工单里反复出现的错误，是在 A 分支把 B 分支的 WAN 地址配成下一跳。两个分支买了同一项服务，于是感觉它们应当是邻居。其实不是：下一跳必须经由你真正拥有的路由设计可达，而远端 CE 通常在你并不管理的设备之后、隔着很多跳。基于这个假设建立的静态路由会显示为活动状态，却解析不到任何东西；这比缺少路由更糟，因为在表里它看起来是对的。

RFC 4364 把客户边缘与运营商边缘之间的交换，与运营商对 VPN 路由的分发分开，而这正是本篇所讨论的边界。客户要做的是告诉自己的边缘能交付什么，并接受服务回馈的可达性。

交接必须在哪些点上达成一致

机制要和运营商一起定，而不是绕开他们。静态路由、BGP，或 CE 与 PE 之间的路由协议约定都合法，OSPF 对这种交接有明确的 MPLS VPN 模型。这些都不是在两个远端客户边缘之间、跨未说明的运营商骨干建立 OSPF 邻接的理由，因为那是运营商没有同意、也无法支持的设计。

新 LAN 上线之前，写下四件事：前缀、CE 上的本地下一跳路由、运营商接受的宣告，以及运营商回传的路由。再加上合同施加的任何过滤、前缀限制或站点间约束。健康的邻接只是交换信息的通道，并不能证明某个前缀被接受了；会话可以处于活动状态，而你的新子网正卡在过滤器里。

然后跟踪回应。B 分支需要一条回到源 LAN 的路由，接收侧的主机也需要自己的网关和自己的服务权限。在 CE-A 上出现的路由只建立了半程往返，而这半程正是 ping 测试一个方向看起来正常、应用却仍然失败的原因。

验收前核实两次交接

在两端的客户边缘收集路由状态，与运营商确认预期的 LAN 前缀已进入 VPN，然后在每个方向测试一个被允许的应用。单看路由表不能证明应用可用，单看应用测试也不能告诉你失败时是哪一层控制面出了问题。

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

把三份输出放在一起读。第一份说明边缘相信什么，第二份说明它从哪个对端学到了什么，第三份说明它实际会转发什么。三者不一致通常是策略或递归问题，而不是缺少宣告，值得在请运营商排查之前先解决。把这三份输出带到与运营商的通话里，因为它们能回答支持工程师本来要问你的大部分问题。

知道服务不提供什么

这是第 3 层的路由型接入。 它不是把广播延伸到各办公室的第 2 层线路，所以发现协议、依赖广播的应用以及共享网段的假设都不会随之而来。打印、名称浏览以及任何依赖本地网段的东西，都需要自己的设计。

VPN 隔离也不是加密。标签交换在运营商网络内部把客户隔开，但合同要求机密性时，它并不会让载荷保密。凡是在意这一点的地方，必须由应用或叠加层来提供。

最后，把服务模型写在站点路由配置旁边。下一位要加子网的工程师应当能读到：宣告了哪些前缀、谁接受它们、预期的回程路径是什么—— BGP/MPLS IP VPN 规范是一切背后那套模型的参照。