在 pseudowire 端点统一 VLAN 标签：一份操作手册

在动 pseudowire 之前，先定义每个客户边缘应收到什么样的帧。在简单情形下，CE A 发送一个业务定界标签，CE B 期望不带标签的帧，而差异就在提供商边缘解决。标签属于本地策略，不属于客户的以太网合同，pseudowire 承载的是约定的帧而不是原始帧。在做任何配置之前，把两个方向都写下来。

先写帧合同

正向移除一个标签，反向再加回来。如果只写其中一个方向，你就会测出一条单向可用的路径，然后把电路判为健康。

把合同写得足够短，能直接粘进变更单：哪个边缘发带标签的帧、哪个边缘期望不带标签、哪个标签值起业务定界作用。

就 pseudowire 模式达成一致

RFC 4448 区分 raw 与 tagged 两种 pseudowire 模式，并说明业务定界标签如何处理。raw 模式仍然可以承载属于客户帧的标签，因此区别在于标签的业务角色，而不只是有没有 802.1Q 头。把模式读成 tagged 还是 untagged，是这项工作量被定错的最常见原因。在决定需要哪些操作之前，先与对端确认模式。

然后核对实际的 pseudowire 类型和对端参数。本地 VLAN 接入与远端端口接入需要受支持的互通安排，两条本地改写语句并不能证明所通告的电路类型一致。

如果控制字与 MTU 的预期不一致，那就是协商问题，任何改写都修不好。两件事都要从对端运行配置确认，而不是从设计文档确认。

应用本地标签操作

Juniper 的 VLAN CCC 改写指南 记录了 pop、push 和 swap 操作及其平台相关限制。对于已配置好的兼容带标签单元，示意方向是入方向 input-vlan-map pop、出方向 output-vlan-map push。这些行只是示意操作，并不是完整的接口或电路配置。要确认具体平台与版本，而不是把某一设备家族的示例到处套用。

单元所支持的 VLAN 与封装设置仍然必须定义预期的标签和分类。在分类错误的单元上写改写语句，只会把问题挪走，而不是解决。

保留业务所需的任何内层客户标签。对于堆叠标签，在移除任何东西之前，先确定你在操作哪个外层标签。

为尺寸做预算，而不只是标签

把保留的标签、实际的 MPLS 栈和控制字都纳入尺寸预算。RFC 8469 建议为以太网 pseudowire 使用控制字，而这条建议会改变帧预算，无论你的平台是否默认启用它。MTU 不匹配要对齐，而不是把告警压掉当作修复。被压掉的告警就是一场把日期磨掉的计划内中断。

在两个提供商边缘上都检查同一份预算，因为一侧加标签、另一侧加控制字，就足以压垮原本正常的载荷。

如果数字对不上，就改方案，而不是改日志级别。

逐帧验收

验收时，在两个方向上检查每个客户接入点上的预期帧。然后按已批准的测试计划，跑业务真正需要的应用流量和控制流量，因为 ping 能证明的东西远少于一个完整到达的带标签帧。把入方向和出方向的帧合同与电路配置一起记录下来。正是这份记录让下一次变更可被审查。

把模式、标签操作、MTU 预算和测试结果放在同一处，因为它们只有合在一起才有意义。把它们拆到三张工单里，保证下一位工程师会重新发现同一个约束。

当两个方向都符合你一开始写下的合同时，电路才算完成，而不是第一个方向通过就算完成。