MPLS 伪线上的 MTU 加三十字节规则为何失效

问一位工程师 MPLS 要加多少，你会听到一个数字，通常是三十，而且说得相当有把握。这个数字与其说错，不如说脱离了前提：它完全取决于起始数字统计的是什么，以及运营商边缘实际发出的是什么。在以太网伪线上，这些假设看得见；一旦写下来，算术就会取代口口相传的说法。

同一个名字下其实在量三样不同的东西。有客户的 IP 数据包，有跨越伪线承载的以太网帧，还有运营商自己的外层链路成帧。把三者混在一起的预算，会得出任何设备字段都不期望的值。

一个把所有前提都写明的计算示例

取一个 1500 字节的客户 IP 数据包、一个跨伪线承载时不带客户 FCS 的普通以太网头部、不保留 VLAN 标签、两个条目的标签栈，以及四字节的控制字。承载的以太网头部加 14，保留的标签不加任何字节，两个标签条目加 8，因为每个条目 4 字节，控制字加 4。这样得到 1526 字节的 MPLS 封装包。

仔细读这个结果。它不包含运营商链路的以太网外层头部及其 FCS；而且它只是一个示例，不是可以填进任何名为 MTU 的字段的常数。两个标签同样是假设：真实栈可能带一个传输标签、一个业务标签，有时还更多，每个条目的成本都是同样的 4 字节。

伪线上实际通过的是什么

RFC 4448 定义了以太网帧如何在 MPLS 内部传输；在其通常模型中，客户的前导码和 FCS 在入口被剥离、在出口重新生成。这就是上面的预算里没有 FCS 的原因。VLAN 的处理取决于业务模式：保留客户标签的模式会把它们的字节加回来，映射标签的模式则不会。额外的保留或额外的封装必须在其上另算。

只要使用控制字，它就算在算术里。RFC 8469 推荐在以太网伪线上使用它，所以一段把它说成可选的旧文字，并不能证明你的路径就省掉了它。向运营商确认实际的业务模式，而不是从拓扑图推断。

把数字和正确的字段比较

现在把所需的封装后大小放到每条相关链路的旁边，也放到你所配置的厂商限制定义的旁边。有些字段描述的是 IP 数据包，另一些描述的是帧或另一种封装边界。两个数字看起来可能一样，描述的容量却不同；看起来装得下的配置在现网中产生丢包，原因就在这里。

这也是为什么在不同平台之间照抄数值有风险。字段名才是规范，而不是你从另一家厂商控制台里记住的十进制数字。

ping 载荷不是 MTU 值

IPv4 ping 的载荷不是 IP MTU。IP 头部和 ICMP 头部同样消耗字节，所以能成功的载荷大小对应的是线路上更大的数据包。在某一个大小上能通过的探测，也说明不了采用其他 VLAN 模式或更深标签栈的业务。测试只测一条路径、一个大小和一种载荷形状，而业务可以把这三者都换掉。

更糟的是，ping 可能成功而大帧失败，因为探测走的路径和大小，真实流量根本不用。把它看作关于可达性的一条数据，而不是第 2 层业务的规范。

当帧装不下时

如果超大帧无法承载，又没有受支持的分片或重组机制，它们会被丢弃，通常两端都不会给出清楚的错误。于是应用在批量传输上超时，而交互式会话仍然正常，这会让人去查防火墙和路由，而不是去数字节。

与运营商把实际预算弄清楚：业务模式、标签处理、标签深度、控制字，以及你设备实际执行的精确上限。把假设写在数字旁边，否则下一位工程师只会继承三十字节规则和一个谜。