分片的确认和重传机制,哪怕只有一个分片在传输的过程中被丢弃或

错误的网络访问控制策略导致PMTUD实现故障一例Jun 27,2004作者：Yiming Gong声明:任何形式的摘抄必须保留上述作者和http地址前一阵子处理了公司转过来的一个关于PMTUD实现的故障，在处理的过程中感觉这是一个国内大网内比较广泛存在的关于安全方面的访问控制列错误配置问题，而且很多技术人员对PTMUD实现几乎没有概念，因此周末花点时间来记录一笔。

转过来的邮件部分内容是这样的“xx省服务器无法下载大文件的问题已经很久了，故障早已经升级到专家组处理，但一直没有解决。

由于其他省市（如xx，xx）也遇到了类似的情况….“还是应该介绍下什么是PMTUD：首先我们知道各种网络链路介质对走在自身的最大数据帧长度都是有要求的，比如以太网就是1500byte，这个值称为MTU。

其次我们知道TCP为了性能考虑，在传输数据包的时候，会尽可能的发送大的分组段，在三次握手时刻，双方要各自通告自己的MSS（最大传输段），告知对方自己能收到的最大报文段长度(注意MSS仅仅是TCP的payload)。

而每端的这个MSS又是通过比较outgoing 端口的MTU和自身buffer，取最小值而来的再减去ip头和TCP头长度而来的，由于大多数主机的buffer都很大，应此一般来讲，以太网介质上的主机常常声明的MSS都是1500byte-20byte IP头-20 byte TCP头=1460 byte。

补充一句，突然觉得恐怕有人要打岔：“错误！也不是分组越大越好”的确，记得Richard stevens在他的文档里面提到过这个问题，结论是分组不是一定越大越好。

有兴趣的可以去翻，不过一般来讲，TCP双方还是尽可能的使用大的分组的。

需要注意的时，即使双方MTU均为1500，也不是万事大吉，因为传输两端主机的中间“可能“会走过不同的网络介质，这些网络介质的MTU可能会小于1500，那么使用1460 byte 作为传输分组段大小的主机在经过这些介质时就会出现问题，导致数据包无法通过。

IP层的分片方法可以解决这个问题：IP层会比较自身MTU和收到数据包的大小，如果收到的IP数据报长度大于自身MTU，那么就需要讲数据报文分片――IP层可以打散收到的数据包～设想一下你的女友吃一个大苹果，囫囵吞下去难度太大，必须一口口分解那个苹果。

不过在TCP/ip实现的过程中，还是尽量避免分片的，这是因为IP是无连接的，缺乏对分片的确认和重传机制，哪怕只有一个分片在传输的过程中被丢弃或超时，那么整个数据报都要重传。

其次，由于数据报分片的重组是在最终的目的主机上完成的，那么分片开始后即使后续路径上所有的MTU都非常大，也只能使用此小分片，这就极大的降低了传输效率。

因此，TCP在通讯过程中，总是尽可能的选取尽可能大但又不会被中间路径任意一跳设备打散的数据包大小。

这个数据报大小就可以被称为PMTU，它等于路径中所有网络设备中最小的那个MTU值。

那么避免分片又是如何实现的呢？就是IP包头的DF位标志，IP可以通过为数据报设置DF（Don’t frag）标志，禁止对数据报分片，来探测路径中MTU小于目前使用MTU的设备，这就是PMTUD。

当IP层收到带DF位标志的数据报时，如果MTU大小允许通过，那么一切照旧；如果分组段＋包头大小大于自身MTU允许值，那么将不再采取自动打散数据报的方式，而是给源主机发送ICMP TYPE 3 CODE 4（fragmentation needed and DF set）报文，源主机收到这个ICMP错误反馈后，会减小自己的分组段大小来适应路径中MTU小于目前使用分组段＋包头大小的设备，然后重传数据报。

（好长，总算一口气写完了大致原理 ^_^ ）看到邮件后，下意识的感觉就是router上错误的配置了针对ICMP的访问控制列，从我以往的经验来看，目前国内很多大的ISP的路由/交换维护人员在配置ACL的时候，往往错误的毙掉所有的ICMP数据包。

我们的这个客户网络分布于国内各个省，同时中间还使用到多家ISP的物理链路，那么就很大的可能在中间某一跳的router上错误的配置了ICMP的ACL，从而使路由/交换设备发出的ICMP TYPE 3 CODE 4无法顺利到达故障两端的主机，主机无法接收到icmp 3/4，so 认为PMTUD实现中目前采用的MSS不存在问题，从而永远尝试用目前实际上已经大于网络中某一跳MTU值的MSS传输，so永远无法顺利传输。

在rfc 2923（TCP Problems with Path MTU Discovery) 里面对这种故障非常明确的进行了解释，有兴趣的可以自去翻阅。

根子上的问题是这样的，那么如何解决呢？个人总结了下，一般而言，对PMTUD实现故障的解决方法大概有如下几种：1：检查传输过程中每一跳的icmp访问控制配置，从而使PMTUD得以正常实现，这是彻底的解决方法。

2：修改路径中小于故障两端的主机MSS值的网络设备的MTU，从而使故障两端的主机的数据包能够顺利通过，不过这个的慢慢找。

3：修改故障两端的主机配置，禁止实现PMTUD，永远以小包方式传输，这是个笨办法，效率太差。

4：目前cisco设备还支持使用ip TCP adjust-MSS命令强制调整MSS值，或使用策略路由中的强制清除df标识位命令，等于变通的调整了PMTUD的实现。

按照个人的想法：此时首先应该寻找一个快速的方法定位MTU小于1500的网络，第一个想法就是使用PING命令，通过-f 指定强制增加DF标志和-l指定数据报payload大小来找出存在问题的那一跳router，不过马上想起ICMP被毙了，ping根本不可能，这个法子行不通；再来，想到hping，（哈，这个软件终于出新版的了，作者晃点了半年），这个倒是可以以非icmp方式来指定数据报payload和强制增加DF标志位一路trace过去来找出存在问题的那一跳router。

可惜让没有经验的客户去编译和使用会%$#@!。

So，不管那么多，干脆使用上面的方法3先来让客户的网络通了再说，具体出问题的点可以让同事慢慢的查，：）我们了解到的目前有问题的两台主机使用的操作系统是HP unix和 windows 2000准备在PMTUD上开始做些工作了，hpunix不熟悉，不过没关系，goolge下，键入关键字PMTU hp unix，第一个页面就有非常好的东东，cisco的文档，《Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems》，好东西！正好是我们要得内容，里面对多种操作系统的涉及PMTUD的调整进行了说明，题外话：cisco的文档系统做的真是棒啊！下了文档，跳过前面的概念，直接找到hpunix部分，如下：HP−UX 11 supports PMTU discovery and enables it by default. This is controlled through the ndd settingip_pmtu_strategy command.# ndd −h ip_pmtu_strategy 0Set the Path MTU Discovery strategy: 0 disables Path MTU Discovery; 1 enables Strategy 1;2 enablesStrategy 2. For further information, use the ndd −h command on an HP−UX 11 system.找了台hpunix，ndd -h ip_pmtu_strategy下，Set the Path MTU Discovery strategy: 0 disables Path MTUDiscovery; 1 enables Strategy 1; 2 enables Strategy 2.Because of problems encountered with some firewalls, hosts,and low-end routers, IP provides for selection of eitherof two discovery strategies, or for completely disabling thealgorithm. The tunable parameter ip_pmtu_strategy controlsthe selection.Strategy 1: All outbound datagrams have the "Don't Fragment"bit set. This should result in notification from any interveninggateway that needs to forward a datagram down a path that wouldrequire additional fragmentation. When the ICMP "FragmentationNeeded" message is received, IP updates its MTU for the remotehost. If the responding gateway implements the recommendationsfor gateways in RFC?191, then the next hop MTU will be includedin the "Fragmentation Needed" message, and IP will use it.If the gateway does not provide next hop information, then IPwill reduce the MTU to the next lower value taken from a tableof "popular" media MTUs.Strategy 2: When a new routing table entry is created for adestination on a locally connected subnet, the "Don't Fragment"bit is never turned on. When a new routing table entry for anon-local destination is created, the "Don't Fragment" bit isnot immediately turned on. Instead,o An ICMP "Echo Request" of full MTU size is generated andsent out with the "Don't Fragment" bit on.o The datagram that initiated creation of the routing tableentry is sent out immediately, without the "Don't Fragment"bit. Traffic is not held up waiting for a response to the"Echo Request".o If no response to the "Echo Request" is received, the"Don't Fragment" bit is never turned on for that route;IP won't time-out or retry the ping. If an ICMP "FragmentationNeeded" message is received in response to the "Echo Request",the Path MTU is reduced accordingly, and a new "Echo Request"is sent out using the updated Path MTU. This step repeats asneeded.o If a response to the "Echo Request" is received, the"Don't Fragment" bit is turned on for all further packetsfor the destination, and Path MTU discovery proceeds as forStrategy 1.Hoho，不错，看来hpunix通过引入全MTU长度的ICMP数据包的发送增加了对black hole 的监测，既然hpunix支持这么个选项，就不用愚蠢的禁止PMTUD了。