MTU参数对运营商网络的影响及配置建议.doc

MTU参数对运营商网络的影响及配置建议 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“Dont 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网络，我们需要全网的