为什么你的 L2VPN 会忽略刚建好的 RSVP-TE LSP

两位工程师可能离开同一个维护窗口时都确信新路径已在服务，而两人的判断却因不同原因都错了。一位建好了 LSP，就以为服务会自动跟随。另一位什么也没动，就以为什么都没变。pseudowire 只会使用其对端地址在当时解析出的那条传输路径，因此真正的问题是这次解析当前给出了什么，两种设计对它的回答并不相同。

一个标签指明服务，另一个搬运分组

pseudowire 标签由定向 LDP 通告，如 RFC 4447 所述，它告诉接收侧运营商边缘：哪个接入电路应当接收该帧。它并不说明帧是怎么到达那里的。它下面的标签属于传输层，而这套栈由任何为对端 loopback 通告可达性的协议建立，无论是 LDP、RSVP-TE 还是分段路由路径。因为两层由不同协议通告，一层健康时另一层可能已经过期。这种分离正是混乱的全部来源。

不妨直说：pseudowire 并不选择 LSP。它把帧交给传输层，由传输层根据收到的目的地址做决定。

这也是为什么跨新 LSP 的一次干净 ping 证明不了什么。LSP 可能在线、有标签、还承载其他业务，而你的 pseudowire 仍经由另一个下一跳解析。在你读取绑定之前，这两件事毫无关系。

方案 A：把 pseudowire 固定到选定的传输

固定意味着让服务的传输解析变得确定。视平台而定，它表现为隧道选择策略、服务上的显式传输端点，或改写对端地址下一跳的路由策略。三者底层做的是同一件事：把某个目的地址的解析强制到特定 LSP 上。这才使结果事后可审计。

代价是范围。匹配对端地址的策略会影响指向该对端的每项服务，而不只是你想到的那条 pseudowire。

备用路径应在变更窗口之前决定，而不是在窗口之中。若固定的 LSP 失效，你要么让服务改走另一条已批准的路径，要么让它停下。一条悄悄退回违反时延或不相交约束路径的策略，已经把一次干净的故障变成了对任何人都难以解释的局面。

方案 B：让 IGP 自行选择并观察结果

让服务保持原状是合理的设计，而且往往更好。pseudowire 与去往对端 loopback 的其他流量遵循同一套解析，因此继承 IGP 收敛、前缀抑制以及核心本就提供的冗余。策略越少，陈旧匹配可藏身的地方也越少。交换条件是：你不再控制服务走哪条路径，只知道存在某条路径。

等代价多路径让这种交换比初看更尖锐。哈希按流进行，因此同一条 pseudowire 内的两个会话可能从不同的外层标签出去。

在信任任一方案之前，先读已安装的转发

从对端地址入手，而不是从服务入手。在 Junos 上，show route 203.0.113.1 detail 打印被选中的下一跳和标签操作，show route table mpls.0 把入标签映射到该操作。在 IOS XR 上，show mpls l2transport vc 100 detail 给出 pseudowire 状态以及压入的栈。

确认传输层实际使用的 LSP，而不是设计文档里写的那条。在 IOS XR 上，traceroute mpls ipv4 203.0.113.1/32 沿标签交换路径走一遍，列出沿途的标签和出接口，这是最接近亲自观察路径的方式。然后从远端运营商边缘重做一遍，因为回程方向是独立解析的，策略只部署一部分时不对称很常见。一个方向对、另一个方向错的路径，比两边都错更糟，因为你的测试会有一半通过。

把证据与服务记录放在一起：对端地址、下一跳、外层标签以及你核查的日期。路由策略很容易过时，没人记得两个季度前生效的是哪一条。

按故障模式选择，而不是按偏好

固定适合那些带 IGP 无法表达约束的服务，也适合能在每次变更中维护策略的团队。交给 IGP 则适合必须在无人介入下挺过任何单点故障的服务。

决定性的问题是错误路径让你付出多少代价。若错误 LSP 上的服务只是略差一点，就让 IGP 决定，把精力放在监控上。若错误路径破坏合同、审计发现或不相交要求，就固定它并写下备用方案。然后测试备用方案，因为未经测试的备用只是假设，不是计划。无论如何，核心每次变更后都要重读已安装的绑定，并把一条升起来的 pseudowire 视为只能证明信令可用，不能证明别的。