文/解麟猛

MTU概念简介

最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议承载上层数据报文的最大数据报大小（以字节为单位）。最大传输单元这个参数通常与通信物理接口有关（以太接口、串口、ATM、E1/T1等）。通常来说是指在IP层上能通过的最大报文长度。

IP协议允许IP分片，这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。分片技术会降低通信效率，因此很多应用通过将IP报文头的DF“Don’t Fragment”标记位置位，来禁止对报文分片。如常见的WEB应用。此时就需要有一种机制来发现整个传输路径的所有接口的最小MTU值。在IP协议中，一条传输路径的“路径的MTU”被定义为从源地址到目的地址所经过“路径”上的所有IP接口的MTU的最小值。RFC 1191描述了“路径最大传输单元发现方法”。在这项技术中，源地址将数据报文的DF“Don't Fragment”标记位置位，路径上任何需要将报文进行分片的设备接口都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址，并在这个响应中告知了该接口的MTU值。这样，源主机就“学习”到了不用进行分片就能通过这条路径的最大传输单元了。

但在现实网络中，有很多种原因使得路径最大传输单元发现方法不能正常工作，常见的环境有：

网络中存在NAT设备，导致路径上需要将报文分片的设备无法通知数据源；

网络中安全设备基于状态的访问控制，或对ICMP报文抑制；

网络中存在隧道，MPLS-VPN等技术，报文在传输过程中增加了额外的封装，超过了接口的MTU。

下面我们来看一看一些MTU带来的问题。

问题1：通过PPPoE over L2TP隧道访问总部WEB服务器部分网页打不开

参考如下组网图：

分部采用R1路由器和总部R2路由器租用运营商提供的Internet访问链路，通过L2TP建立隧道，分部需要访问总部服务器的客户端通过PPPoE连到R1，并通过L2TP隧道从R2处获得地址。网络联通后，发现PC1访问PC2的WEB页面时，有部分网页无法打开。

使用Ping报文进行测试，发现不论小包和大包（可以分片），都可以ping通。但将DF位置位后（不许分片），可以通过的最大ping报文是1460bytes（包含IP及ICMP封装）。

从ping测试结果看，可以分片报文可以通过，不能分片报文（大包）不能通过，我们判断问题和接口MTU相关。

问题分析：

我们分析一下在网络中传输报文的封装结构：

因为在总部的R2路由器上启动了L2TP虚接口，该虚拟接口会为传输的报文增加L2TP的封装，UDP的封装，外层IP头封装，需要增加：

L2TP（6bytes）+UDP（8bytes）+IP（20bytes）=34bytes

因此在R2路由器的VT虚接口上会自动计算MTU，该值为物理出接口的MTU值减去34bytes，即为：1500-34=1466bytes。对于ping报文来说，还需要减去PPP的封装，即：1466-6=1460bytes（含IP、ICMP报文头）。

而在访问网页的时候，有些大包不能分片，因此导致了部分网页打不开的效果。

解决方案是：

调整R1和R2设备的物理出接口的MTU。

问题2：数据报文小包能通过，大包（即使可以被分片）不能通过。

参考如下组网图：

如上网络是一个典型的MPLS VPN组网图。P设备和PE设备中间使用的是运营商租用的MSTP链路。CE1和CE2之间互ping包长1468bytes（不含IP、ICMP报文头）以下正常，ping包长1469bytes不通。

问题分析：

针对问题我们进行进一步详细测试，发现CE1始发ping大包1497bytes的报文时，报文可以到达CE2，CE2的应答报文由PE2转发出去，但P设备没有收到。查询P设备端口统计报文数没有增加。初步怀疑数据报文在MSTP链路上被丢弃。

进一步查询MSTP的网络参数，发现MSTP设备上缺省配置可以接收、发送最大帧长为1518bytes（不含CRC）。

我们计算一下，1497bytes的IP报文经PE2设备发出时，因没有超过1500字节，不会被分片，打上两层MPLS标签，再封装Ethernet包头，1497+4+4+14=1519，已经超过了MSTP设备接收最大帧长，报文被直接丢弃。

从CE1到CE2方向的报文为何没被丢弃？原因也很容易理解，P设备发报文给PE2的时候，进行了倒数第二跳弹出，因此只打了一层标签，没有超过MSTP设备接收帧长上限。

解决方案：

1． 推荐的解决方案

我们希望的解决方案是，对于DF置位的IP报文，最大可以通过1500字节。要达到这一点，对于通常的MPLS 三层VPN网络，我们需要全网的MPLS VPN设备，包括传输线路的MSTP设备，物理接口至少能够接受超过1522字节（不含CRC）的超长帧。

而实际上在现实网络中，还可能存在三层、四层标签，以及802.1Q标签等，对接收帧长远超过1522字节的要求。

2． 可选的解决方案

如果因为某些原因，现网MSTP设备较陈旧，无法支持超长数据帧，那么需要在MPLS VPN设备上调整MPLS MTU。

mpls mtu 1504

这种方式会导致最大能够传输的不分片报文为1496bytes（具体应用环境可能不同，需要分析附加的封装开销），对于某些应用会存在问题。是不得已的解决方案。

问题3：H3C设备和友商设备互联，OSPF邻居无法建立。

参考如下组网图：

H3C设备和友商设备背对背互联，直联接口互ping没问题，但OSPF邻居一直无法建立。一端OSPF状态为Exstart，另一端状态为Exchange。

问题分析：

通过对两端设备的OSPF进行debug分析，发现友商的设备上报DD报文MTU域错误，因此将DD报文丢弃。

RFC2328规定，DD报文中有一个Interface MTU字段，要求填写实际物理端口的MTU值。对于V-link该值填“0”。

各厂家对这个字段的实现情况不一。

H3C设备为增加适配性，缺省的情况下，所有发出的DD报文的Interface MTU字段都填写“0”，并且不对接收到的DD报文的Interface MTU字段进行检测。可以通过在实际接口上配置OSPF mtu-enable命令，使得在发出的DD报文中Interface MTU字段填写为实际物理接口MTU值，并且对接收到的DD报文Interface MTU字段进行检测。检测的原则是：如果接收到的DD报文的Interface MTU的值大于接收到该报文的实际物理接口的MTU，则将此DD报文丢弃。

Cisco设备的实现方式有所不同。Cisco设备缺省情况下Interface MTU字段填写实际物理接口的MTU，并且要对接收到的DD报文进行监测，检测原则与H3C相同。Cisco设备可以在接口上配置ip ospf mtu-ignore命令来关闭对DD报文的检测。

部分友商对DD报文的检测更为严格，对于并非V-link链路的DD报文，如果数值为零，也认为是非法报文。

针对以上分析，我们很容易就找到解决方案。

解决方案：

需要在H3C设备运行OSPF的接口上增加配置命令：

OSPF mtu-enable

同时，需要将两端设备互联物理接口的MTU值配置为相同。

MTU相关问题的总结

1. 从第一个问题看，虽然接入路由器进行了MTU调整，但如果Internet骨干网上仍然存在MTU为1500的端口，且数据报文经过该端口转发，那么仍然存在大数据报文被分片或被丢弃的情况；

2. 从第二个问题上看，在全网MTU数值调整之后，大数据报文的传输，仍然受到网络中二层转发设备的最大可接收数据帧长限制；

3. 在OSPF、ISIS等IGP协议中，需要对接口的MTU进行探测和协商，需要将互联的两个端口的MTU调整为相同。

4. 随着目前数据中心、云技术的发展，大二层网络技术被越来越多的使用。其中各种“MAC in MAC”、“MAC in UDP”等技术像雨后春笋一样发展起来。而二层数据帧不具备分片的特性，在传输过程中只能被整个数据帧封装，这在网络中将导致更大数据报文的出现，对网络设备的MTU和最大可接受数据帧都提出了新的要求。

MTU在运营商网络中的配置建议

1. Internet骨干网，城域网络MTU的配置建议

从以上的问题分析总结中我们得知，为保证骨干网络、城域网络、接入网络的完美工作，MTU的数值一定要远大于以太网标准的基本要求，1500bytes。通常现有的大型路由器，交换机设备，都可以支持到9000以上的大数据报文，但缺省配置各厂商并不相同，很多厂商设备的缺省MTU配置仍然是1500bytes。并且因为网络中很可能运行OSPF、ISIS等需要协商MTU的路由协议，所以互相对接的不同厂商的设备的MTU也要调整为相同。

因此，在骨干网络的建设中，需要指定MTU的配置规范，在各个厂商都支持的情况下，尽量将MTU配置的大一些。

2. 数据中心等局域网络MTU的配置建议

在骨干网上，MTU的问题已经被大多数运营商了解并重视，并形成了相应规范。但在目前大规模建设的IDC等网络中，通常没有对MTU进行统一调整。随着新技术的应用，MTU的问题会逐步暴露出来。比如为进行大二层扩展进行的各类二层隧道技术的使用，VLL、VPLS、EVI等，以及进行多租户隔离的VXLAN技术的使用等。这些技术无一例外的都使用了额外的封装，形成了超大报文。如不同意进行MTU的规划，会导致传输效率低下，或者业务中断。

因此，在IDC等网络的建设中，也需要确定MTU的配置规范，在各个厂商都支持的情况下，尽量将MTU配置的大一些。

3. 调整MTU的同时也需要调整各设备最大可接收帧长。这个参数受芯片限制，有的产品可以调整，有的产品不能调整。H3C当前大多数产品最大可接收帧长缺省值就能够支持9216bytes，只有非常古老的产品才会在最大可接收帧长上存在限制。但当前有些厂商的设备需要调整缺省配置。最大可接收帧长是单个产品参数，设备间不需要互相协商。