×××技术中的MTU问题

【问题简述】

 

在×××技术中常常遇到隧道已经创建可是某些应用程序没法正常通信的问题，通常所来是因为路径MTU不匹配的缘故，下面就其中的数据传输流程作一些分析，以说明遇到出现此类问题该如何解决。

 

【问题分析】

先从一个实验提及

实验拓扑以下：

PC1-------×××网关1―――――×××网关2--------PC2

 

在上述组网中，×××网关1和2之间创建了一条GRE隧道，PC1与PC2经过该GRE隧道互访。

这时，咱们会发现，PC1在ping 1448的报文时，在PC2上抓包发现没有被分片，而ping 1449时，PC2上会发现PC1过来的报文已经被分片了。为何呢？

PC1出来的IP报文长度为1448＋8（ICMP报头长）＋20（IP报头长），到达×××网关1，×××网关1发到GRE隧道口，封装GRE头（4字节），再加上外层IP头，到达×××网关外层以太口，这时IP报文的长度已经变为：1448＋8＋20＋4＋20＝1500字节，恰好等于以太口的MTU，因而被顺利传送。而ping 1449时，到达外层以太口为1501字节，超出了1500的MTU，又由于报文DF位未置1，便可以分片，×××网关因而将该报文分片发送出去。这就是咱们所看到的现象。

在上述实验中，因为应用程序是ping，因此报文能够被分片，所以互通没有问题。可是若是是WEB访问等应用，则有些报文是不容许分片的，这样在外层以太口就会将超过1500的报文丢掉，致使没法通信。

从上述实验能够看到，因为×××会额外加入一些报文头，若是通信双方的MTU不能随之改变的话，就容易产生不通的问题。

下面以HTTP为例，说明为什么产生此问题并如何解决。

先看看HTTP为什么没法像ICMP那样自动分片通信。

假设PC1/2创建了HTTP链接后，PC2但愿从PC1下载一个大的网页。PC2开始发送，其IP的DF位置1，不容许分片，IP报文长度为1500字节。到达×××网关1的外网口后，×××网关1发现其长度超过了1500个字节，因而将其丢弃，并给PC1发回一个目的地址不可达的ICMP信息，出错代码为”Fragmentation needed”，表示须要分片，但不容许分片，同时给出”MTU of next hop: 1500”。PC1接收到该消息后，又按照1500字节对外发送，又被丢弃，因而就造成了循环，没法通信。

根据上述的分析，很容易获得以下解决方式，在×××网关1的出接口设置MTU为1500－4－20＝1476，这样×××网关1返回ICMP不可达消息时将给出”MTU of next hop: 1476”。PC2将以1476做为本身的最大MTU对外发送，到达×××网关1，封装GRE和外层IP头后就不会超过1500而顺利发到对端。

这时仅解决了下载的问题，若是PC2须要将大文件上传到PC1，一样须要设置×××网关2的出接口MTU值小于1476。

固然，还能够更改×××网关1的出接口的TCP MSS数值，将其更改成1500-4-20-20（TCP头）=1456字节，也可保证HTTP等TCP应用顺利经过。但该状况仅适用于TCP应用。

上述解决方式一样适用于其余隧道技术，在L2TP、IPSEC等应用时能够相应的根据其包头数值设置MTU或MSS。