为什么 Junos L2VPN 显示标签却不转发任何流量

客户报告到达时称：L2VPN 连接处于 Up，接入点已启用，但没有任何帧通过。状态灯是诚实的；帧正被归类到一个在远端没有可用转发状态的服务中。在由 BGP 信令的点到点 L2VPN 中，第一个决定属于接入点，而不是路由查找。客户帧到达逻辑接口，该接口确定了连接，因此也确定了远端站点。此后的一切都是用对端所通告的内容构建出的标签转发状态。

帧从不进行路由查找

信令已经准备好了状态；逐包处理只是在已选定的连接上查找标签。因此问“为什么缺少路由”是错误的问题，它掩盖了两个关键值：接入点的连接，以及它使用的服务标签。

这也解释了投入上的不对称。配置审查告诉你本应安装什么，而连接视图告诉你实际推导出了什么，只有后者能经受标签块不匹配。

两个标签，两个方向

每个 PE 在本地分配一个标签块，通告其基址与大小，其对端再加上偏移量，从而推导出某个站点的标签。因此分配只在本地有意义：两个 PE 对同一服务可以使用不同的基址和不同的块大小。在改动任何东西之前，先从两端读取连接。尺寸少了一个标签的块，看起来和一条从未安装的连接一模一样。

show l2vpn connections instance CUST-A extensive

在该输出中，入标签是本 PE 分配并告知对端使用的那个，而出标签是本 PE 压入的、对端分配的标签。把两者读反是经典错误，它会让你去寻找一个本不该出现在这一侧的值。连接参考记录了标签旁的字段，包括站点、状态和块信息。

标签查找证明了什么

拿到入标签之后，本地查找只需一条命令：

show route label 160042

该输出应显示带有下一跳的 l2vpn 条目，标签操作会告诉你帧在离开前是压入、交换还是弹出。如果什么都不显示，即使连接显示 Up，服务状态也从未安装，差异出在信令而不是传输。

跟踪一个帧

把一个数据包压入接入点，比任何配置审查都更能说明问题。服务标签路由应指向通往远端 PE 的传输 LSP，两个标签也应对应于对端报告的值。当传输正常而服务标签错误时，帧到达正确的路由器后在那里被丢弃，所以远端计数器看起来是空的，而近端计数器看起来很忙。

同时检查接入点的封装、控制字设置和 MTU，因为它们是协商出来的属性，而不是逐跳行为。

把服务模型分开看

VPLS 学习 MAC 地址，EVPN 通告端点，而点到点 L2VPN 两者都不做，因此尽管它们跑在同一套 BGP 和 MPLS 基础设施上，帧选择流程并不能互换。把一种模型的排障步骤搬到另一种模型，只会得出自信却没有依据的结论。

对于缺失的路径，记录两端对端的连接状态、接入点、两个标签方向、封装、控制字设置和 MTU。该记录把所通告的内容与转发平面实际行为连起来，这是唯一重要的环节，也是下一位工程师会索要的东西。