Junos L2VPN：先把客户的接入合同定对

在碰 pseudowire 之前，先跟一个客户帧进入 PE，看它应该落在哪里。物理端口把它分类到一个逻辑单元，该单元承载一种封装，而单元又绑定到一项服务。三个彼此独立的决定，也是三条各自出错的路。大多数被上报为信令故障的案例，其实是被分类进了没人为此服务配置过的单元。所以从接入开始，再往外查。

把帧合同写下来

在选任何配置之前先把合同记录下来：不带标签、单层服务标签，还是标签栈。补上客户将要发送的 MTU，以及每个方向上预期的标签处理方式，因为这些是协商出来的属性，不是本地偏好。单元号只是标识符，它并不说明接口会接受哪些帧。

把它写进服务记录，而不是工单评论。半年后来排查的人会读记录。他不会去读工单。

让封装与合同对应

单标签服务通常使用 VLAN 电路封装，例如 vlan-ccc，而不带标签的帧需要朴素的 Ethernet 电路形式，标签栈则需要能理解两个标签的扩展形式。在支持按单元做服务封装的平台上，一个物理接口可以同时承载多个，这很方便，也正是帧落进错误单元的那条路。若平台指南要求 family ccc，就把它作为完整接入的一部分来配置，而不是事后挂到某个路由接口上。封装指南 列出了哪些接入类型会带来哪些要求。

不要出于保险给每个接口都加一条 family 语句。让一条电路跑通的配置，可能让下一条接受它的客户从不发送的帧。

把接入绑定到正确的服务

由 BGP 信令的 Layer 2 VPN、由 LDP 信令的电路，以及其他受支持的服务，各自有独立的接口绑定和信令配置，彼此不可互换。把一种接入方式与另一种的信令混在一起，得到的电路会报告对端却从不承载帧。

把远端与近端对照，而不是孤立地看其中任何一端：对端地址、服务标识、封装约定、control word 期望和尺寸预算。底下的 MPLS 完全可以健康，而接入缺失或被分类到了别处；所以只看底层在这里证明不了任何事。

用帧来验证，而不是用状态

在客户发送流量时读取本地接口计数，然后读服务状态，最后确认到达的帧就是约定的那一帧，标签也包括在内。修好的接入会送出那一帧；仅凭状态变化什么都证明不了。

在有权限抓包的地方，两个方向都看帧。标签不对称在状态视图里容易漏掉，在抓包里却一目了然。这种不对称也解释了那些单向能通、反向失败的问题。

然后把它写下来

在服务记录里记下四个值：合同、封装、单元和服务绑定。新工程师需要的正是这四项，而配置评审很少明说。

半年后电路出问题时，那条记录就是十五分钟修好与从运行配置里重新推导整套设计之间的差别。再补上最后一次核对的日子，记录也就说明了它有多旧。