下面转自： http://ccie911.blog.163.com/blog/static/127469709201122492513954/
关于MTU、IP MTU、TCP MSS探讨与分析
1. 概述
本文主要分析了二层MTU，IP MTU，MSS之间的关系和在不同网络场景中的应用，最后通过一个案例分析来进一步认识MTU对实际IP数据包转发的影响。
2. MTU
最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议在某一层上面所能通过的最大数据报大小（以字节为单位），它通常与链路层协议有密切的关系。EthernetII帧结构如下：
由于以太网传输电气方面的限制，每个以太网帧都有最小的大小64bytes，最大不能超过1518bytes，对于小于或者大于这个限制的以太网帧，我们都可以视之为错误的数据帧。一般的以太网转发设备会丢弃这些数据帧。（注：小于64Bytes的数据帧一般是由于以太网冲突产生的 “碎片”或者线路干扰或者坏的以太网接口产生的，对于大于1518Bytes的数据帧我们一般把它叫做Giant帧，这种一般是由于线路干扰或者坏的以太网口产生）。
由于以太网EthernetII最大的数据帧是1518Bytes，除去以太网帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes （这个部份有时候大家也把它叫做FCS），那么剩下承载上层协议的地方也就是Data域最大就只能有1500Bytes，这个值我们就把它称之为MTU。
这个MTU就是网络层协议非常关心的地方，因为网络层协议比如IP协议会根据这个值来决定是否把上层传下来的数据进行分片。就好比一个盒子没法装下一大块面包，我们需要把面包切成片，装在多个盒子里面一样的道理。当两台远程PC互联的时候，它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端，网络中不同媒介的MTU各不相同，就好比一长段的水管，由不同粗细的水管组成（MTU不同 ）通过这段水管最大水量就要由中间最细的水管决定。
3. IP MTU
对于网络层的上层协议而言（我们以TCP/IP协议族为例），网络层IP协议会检查每个从上层协议下来的数据包的大小，并根据本机MTU的大小决定是否作“分片”处理。分片最大的坏处就是降低了传输性能，本来一次可以搞定的事情，分成多次搞定，所以在网络层更高一层（就是传输层）的实现中往往会对此加以注意！有些高层因为某些原因就会要求我这个面包不能切片，我要完整地面包，所以会在IP数据包包头里面加上一个标签：DF（Donot Fragment）。这样当这个IP数据包在一大段网络（水管里面）传输的时候，如果遇到MTU小于IP数据包的情况，转发设备就会根据要求丢弃这个数据包，然后返回一个错误信息给发送者。这样往往会造成某些通讯上的问题，不过幸运的是大部分网络链路MTU都是等于1500或者大于1500。
对于UDP协议而言，这个协议本身是无连接的协议，对数据包的到达顺序以及是否正确到达不甚关心，所以一般UDP应用对分片没有特殊要求。对于TCP协议而言就不一样了，这个协议是面向连接的协议，对于TCP协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些TCP应用对分片有要求---不能分片（DF）。
4. MSS
MSS是最大传输大小的缩写，它是TCP协议里面的一个概念。如下图1-1所示：
图1-1 TCP头部
注：URG等参数指的是 ACK URG PSH SIN FIN RST等参数
在TCP报文中 MSS的位置就在选项的位置，根据RFC1323和RFC793规定，选项中内容有很多种，MSS是其中的一种，用kind=2表示；kind=1表示无操作，kind=4、5、6、7称为选择ACK及回显选项，但是由于回显选项已经被时间戳选项取代，同时，目前定义的选择ACK选项仍未定论，也没有包括在RFC1323中，所以具体代表什么含义还无定论。在实际网络数据传输，要求MSS+20TCP包头 +20 IP包头不大于MTU。MSS在TCP报文中是可选项，不是必选项，换句话说，MSS是可协商项，而且在协商过后，该选项内容可以改变，也可以没有；在协商MSS时，一般是建立TCP连结的两端发送Syn标志报文时互相通报，然后选取最小MSS作为双方的约定，如果双方都不通报或有一方不通报。
MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能，TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes），所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。
5. 区别及联系
由前面的叙述可知：MTU是一个二层的概念，以太网最大的mtu就是1500（它是不包含二层头部的，加上头部应该为1518 bytes），当然这里说的是很常规的情况，也有些server，比如server 2008，出来的就是jumbo frame了，我们在这里讨论常规情况。IP MTU是一个三层概念，它包含了三层头部及所有载荷，根据下层为上层服务的，上层基于下层才能做进一步的扩展的原则，尽管IP MTU的变化范围很大（68-65535），但也不得不照顾以太网MTU的限制,说白了就是ip对以太网的妥协。MSS是TCP里面的一个概念，它是TCP数据包每次能够传输的最大数据分段，不包含包头部分，它与IP MTU满足如下关系：IP MTU=MSS+20bytes（IP包头）+20bytes（TCP包头）。当然，如果传输的时候还承载有其他协议，还要加些包头在前面，简言之，mtu就是总的最后发出去的报文大小，MSS就是需要发出去的数据大小，比如PPPoE，就是在以太网上承载PPP协议（点到点连接协议），它包括6bytes的PPPoE头部和2bytes的PPP协议ID号，此时，由于以太网的MTU值为1500，所以上层PPP负载数据不能超过1492字节，也就是相当于在PPPOE环境下的MTU是1492字节，MSS是1452字节。
6. MTU问题解决方法
通常情况下，MTU不匹配会表现为两种故障情况：
- ping大包时不通
- 无法访问某些站点
在这种情况下，通常有两种解决方法：
- 修改用户端MTU值（不推荐使用）
- 修改传输路由所有设备MTU值，确保路径MTU值大于用户发送的IP报文的长度，以保证用户报文不会因为超过设备的MTU值被丢弃。主要要考虑下面几种情况：
· 对于纯IP网络，要保证：路径MTU值>最大用户报文长度
· 对于纯MPLS网络（没有VPN业务），要保证路径MTU值>最大用户报文＋一层标签长度（4）
· 对于三层VPN业务，要保证：路径MTU值>最大用户报文＋两层标签长度（8）；
· 对于二层VPN业务，要保证：路由MTU值>最大用户报文长度＋两处标签长度（8）＋二层帧头长度（18）。
值得注意的是：fastethernet接口不能调整MTU，所以说在有些设备中，使用MTU命令不能解决问题的。此外，更改MTU后，如果IGP是OSPF的话，不同的MTU可能会造成OSPF 停留在INIT状态，此时需要将两端的MTU调整一致。
7. 案例分析
下面通过一个某公司TCP MSS配置不匹配导致应用不正常的案例分析，来加深对上述概念的理解。其拓扑图如下图1-2所示:
图1-2 某公司网络拓扑示意图
设备
角色
说明
NBR2000
公司总出口路由器
l NBR2000启用L2TP功能，同时在L2TP虚拟模板接口中配置了TCP MSS为1300。
l NBR1200启用2LTP功能，同时在L2TP虚拟模板接口中配置了TCP MSS为1400。
l NBR1200与NBR2000通过L2TP协议建立隧道，NBR2000作为服务端，NBR1200作为客户端。
NBR1200
分公司出口路由器
故障现象：
l 在分公司NBR1200的PC上登录总公司ISOFLOW服务器，在ISOFLOW里签核表单的时候，会无法签核下去而导致IE死掉的现象。 如果碰见ISOFLOW单子的附件，会发现附件要过很长、很长的时间才能打开。
l 访问ERP系统普通表单的速度不错，但是一旦进行数据库的读写，速度极慢；数据查询时经常超时。
诊断故障原因及分析：
1.故障诊断的思路
登录到总公司NBR2000和分公司NBR1200，查看配置，具体如下：
NBR2000 虚拟模板配置：
interface Virtual-Template 1
mtu 1400
ppp authentication pap
ip nat inside
ip tcp adjust-mss 1300
ip unnumbered GigabitEthernet 0/0
peer default ip address pool VPDN
NBR1200 虚拟模板配置：
interface Virtual-ppp 1
pseudowire X.X.X.X 20 encapsulation l2tpv2 pw-class pw
mtu 1400
ppp pap sent-username star-net password 7 0058274d4c24
ip tcp adjust-mss 1400
ip address negotiate
故障诊断的分析
1、 判断网络层是否正常
在现场从分公司PC PING总公司ISOFLOW服务器IP，长PING没有丢包，说明网络层是正常的。
2、应用异常
目前用户应用是通过HTTP来访问，出现能访问，但很慢的现象，说明是在应用层上出现了问题。一般来说，在应用层出问题，在排除软件本身问题的情况下，基本可以定位是MTU或TCP MSS不匹配原因引起。
3、TCP MSS分析
一般来说一般的应用软件，当客户端和服务器端在建立TCP连接的时候需要根据实际传输的报文大小来协商TCP的窗口大小MSS。在TCP协商的第一个报文也就是SYN置位的报文中会告知对方自己所能接收的最大TCP数据净荷（也就是TCP报文中的数据长度）----MSS，对方收到TCP同步报文也会回复一个SYN置位的TCP报文，其中也携带了MSS参数来告知对方自己能接收的最大MSS。根据以上分析，我们来看一下总公司与分公司路由器是怎么协商TCP MSS的：
（1）分公司-》总公司
PC发起TCP SYN报文与总公司ISOFLOW服务器进行协商，在TCP SYN报文经过分公司路由器虚拟模板接口（out方向）时，路由器会将接口配置的MSS值1400（分公司路由器在虚拟模板接口上配置了ip tcp adjust-mss 1400）与TCP报文中的MSS值1460（windows XP系统默认是1460）比较，取二者的最小值1400。ISOFLOW服务器收到此TCP同步报文，查看其中的MSS=1400，服务端在后续发送数据时封装的最大TCP数据载荷为1400。一般来说TCP MSS是不分包的，DF置位为1。
（2）总公司-》分公司
ISOFLOW发响应TCP SYN ACK报文给分公司的PC，在TCP SYN报文经过总公司路由器虚拟模板接口（out方向）时，路由器会将接口配置的MSS值1300（总公司路由器在虚拟模板接口上配置了ip tcp adjust-mss 1300）与TCP报文中的MSS值1460（windows XP系统默认是1460）比较，取二者的最小值1300。PC收到此TCP同步确认报文，查看其中的MSS=1300，PC在后续发送数据时封装的最大TCP数据载荷为1300。一般来说TCP MSS是不分包的，DF置位为1。
PC在向ISOFLOW发送请求，作为ISOFLWO的被请求端，发出的数据包括的数据文件，数据包较大，需要封装成最大MSS载荷传送（提高效率），在此MSS=1400,当数据包经过总公司L2TP VPN虚拟模板接口时，由于配置了mtu 1400，而此时数据包的MTU（MTU=1400+TCP(20)+IP(20)+PPP (4)+L2TP（8）+UDP（8）+IP（20）=1480）远远大于总公司路由器虚拟模板接口MTU 1400，且IP包头强制不分片位被置位，导致在出VPN隧道时报文被丢弃，所以现象就是能够建立TCP连接，但服务器端返回大数据包时，出现IE应用程序没有响应现象。同理，如果是从服务端发起的访问客户端口PC，由于客户端接收到的TCP同步报文中的MSS=1300，那么其封装的数据经过分公司路由器L2TP VPN隧道时，数据包的MTU(MTU=1300+ TCP(20)+IP(20)+PPP (4)+L2TP（8）+UDP（8）+IP（20）=1380)小于分公司路由器隧道MTU=1400，所以能够正常。
