网络故障举例：[转自华为3COM全球服务论坛]
现象描述：
组网：
PC－AR2831－AR2880－CISCO设备组成的核心网－SERVER
网络运行MPLS VPN;AR2880为PE;AR2831为CE，PE、CE间运行OSPF,多CE配置；路由器各接口MTU、TCP MSS值采用默认设置
AR2880：Version 3.30, Release 0008
AR2831：Version 3.30, Release 0008
现象1：
AR2880路由器的以太口MTU使用缺省设置时,使用的OA系统(BS架构)部分流程无法运行,上网发邮件时附件无法粘贴；但是在cisco设备上，同样的组网没有发现问题；
现象2：
将AR2880路由器的以太口MTU改为512测试,邮件附件可以粘贴,但OA主页打开后无内容,刷新不了；将AR2880路由器的以太口MTU改为1200测试,邮件附件可以粘贴,OA主页可以正常显示,但是点击OA系统的"起草公文"无页面弹出,正常状况下应弹出新建公文页面；
告警信息：
无
原因分析：
原因分析：
可能是应用软件问题；可能是MTU 、TCP MSS值协商配置问题；
具体分析：
1、接口MTU、TCP MSS采用缺省值1500时，无法贴附件；
这是因为应用了三层MPLS VPN技术，增加了8bit的标签，MTU值协商出现问题。
AR28XX路由器默认在接口上自动分片，所以在普通的应用中采用默认值不会影响业务。但路由器接口上收到一个报文长度大于本接口MTU值的报文，如果该报文被强制打上不分片的标记，将丢弃报文，并返回一个ICMP差错报文（type 3,code 4），通知报文发起者丢弃原因。报文发起者将发送比较小的报文。通过多次上述报文协商，将得到对于某一个固定路径上的最小Mtu值，这个过程叫做Mtu Discovery ，通过MTU Discovery来确定报文路径上最小可通过的MTU；如果两个设备相连，没有MTU Discovery功能并且MTU值不一致，将可能导致丢弃报文。只有把双方设备的Mtu为对端设备MRU的最小值，才能正常通信。由于某些组网考虑到网络安全问题和性能，往往会把ICMP报文过滤掉，引起Mtu Discovery不能正常运行；应用软件由于程序算法问题或根本没有相应协商功能，也会导致了部分应用异常。
2、更改接口MTU值以后，仍然有部分业务不正常；
这是因为TCP MSS值协商的问题。
MSS值的计算方法是：MSS=MTU-IP-TCP（如果有其他pppoe、加密报文头的话也同样减去），也就是说MSS值其实就是TCP所承载的净载荷的长度。由于AR28XX接口缺省的MTU是1500字节，故一般要求加密报文头+链路层开销+IP头（20-60字节）+TCP报文（20字节）小于1500字节，即TCP分片配置1200左右比较适合。缺省情况下，TCP报文不分片。因此TCP MSS不匹配也会引起部分应用异常。
处理过程：
本例中通过修改路由器接口MTU、TCP MSS值，解决问题。
具体报文mtu 、tcp mss大小要根据具体应用，按经验值进行尝试，选择最佳值；其中MTU值的选择可以通过ping命令设置不分片来进行测试；TCP MSS值的选择则可以通过MTU减去相应其它加密、链路层开销、IP头、TCP头等字节计算。
具体过程如下：
1、本例中使用cisco路由器时相关应用正常。初步估计是mtu值问题，但是对普通应用AR28系列路由器会自动分片，不会影响业务。测试发现在client上ping大包的时候，如果不设置不允许分片，业务正常。看来客户应用中做了不允许分片的设置或其它原因mtu协商错误。更改路由器接口mtu为1500-8＝1492以后，业务正常。
2、更改接口mtu以后，其它部分业务还不正常。分析原因是tcp mss值的问题。减小tcp mss值8字节1460-8＝1452，但是还有部分业务不正常。询问软件集成商，得到答复部分软件中使用了加密技术。而且不同的应用加密强度不同。
3、逐步调整路由器接口的tcp mss值，减到到1200以后，所有业务测试通过。
命令说明：
1、mtu命令用来设置以太网接口的MTU（最大传输单元），undo mtu命令用来恢复MTU的缺省值。缺省的MTU为1500。使用mtu命令改变接口最大传输单元MTU后，需要先对接口执行shutdown命令，再执行undo shutdown命令将接口重启，以保证设置的MTU生效。
2、tcp mss命令用来配置TCP报文分片，undo tcp mss命令用来取消TCP报文分片。
个人总结：
MTU=MSS+IP header+TCP header+链路层开销+加密报文头（某些程序加密强度不一样）
MTU，对UDP和TCP报文都检测，当超过时，如果报文DF=0 ，就进行分段，如果DF=1，就丢弃，同时返回RFC 792定义的ICMP Type3 Code 4（ICMP Destination Unreachable-Fragmentation Needed and DF Set）或 RFC 1191定义的ICMP包（包含转发失败链路的MTU），主机收到后会调节MSS以适应，后续包不会分片就可进行传输。如果两端之间某Router 配置了ACL ，deny掉所有的ICMP，那就无法收到咯。
MSS其实就是TCP报文payload大小。一般的应用软件，当客户端和服务器端在建立TCP连接的时候需要根据实际传输的报文大小来协商TCP的窗口大小MSS。Tcp连接成功后会进行两次滑动窗口的协商,一次是pc与server，一次是与网关，然后在两次协商里选择一个较小的值作为窗口来发送报文。
当协商出来的MSS比较大时，加上IP header+TCP header+链路层开销+加密报文头后，就有可能大于MTU，当DF=1时，就会丢弃掉。
正如 所说：“对于UDP协议而言，这个协议本身是无连接的协议，对数据包的到达顺序以及是否正确到达不甚关心，所以一般UDP应用对分片没有特殊要求。”所以在路由器上进行ip tcp mss命令只对tcp packet检测就够了。
再提供一个案例：MSN是使用https方式登陆的，有时会有突发大报文，而且DF位是设置为1的。虽然目前大部分出现的故障现象都是：不能发送附件；不能打开网页等。都是在PPPoE中发生的。但就算源和目的网络的MTU都是1500，但是由于中间经过的节点链路可能存在不同，可能少于1500。或者在传输过程中的某个路由器设置了较小的MTU。而往往配置路由器或交换机时，习惯禁止了所有的ICMP信息，这样的话那路由器就无法返回ICMP 3/4的包给源主机了。 RFC 2923 （TCP Problems with Path MTU Discovery）。
所以，有时候出现的故障，不止要调试MTU值，还要调试MSS值，才能使所有应用正常
其实碰到此问题时，最好是借助Sniffer抓包分析（不过奇怪，锐捷NBR1000无法抓到ICMP Type 3 Code 4的包，所以无法抓包提供分析图，好可惜！是路由器不支持还是其他原因，以后有机会考证）
附：Sniffer抓包协助理解分片过程以及DF
上图是：Ping –l 2000
首先看IP header，More fragments位为1，向对方通告此数据包为多帧发送（分段），total lengt=1300bytes（1280bytes+IP报头20bytes）。再看ICMP处，可以看到分了两个包，大小分别为1280bytes和728bytes，2008 bytes of reassembled data指明重组后的数据为2008bytes（icmp包头8bytes，数据2000bytes）。然后看DLC部分，指明了以太类型0800（IP），帧大小为1314bytes（ICMP的1280bytes+IP报头20bytes+帧14bytes）
再接着看下一个帧。首先看到DLC部分写着了帧大小为762bytes，IP部分，continuation of frame 17 ，第17个帧的后续。Fragment offset 分段偏移量为1280bytes（第一个包的大小）。至此，第一个icmp echo包全部发送完毕。
ping –f –l 1200
-f命令：将数据报DF（don’t fragment）位设置为1（不能分段）
