【MTU】关于MTU size| MTU size, PMTUD 和分段
目录
原文：https://www.networkworld.com/article/2224654/mtu-size-issues.html
最大传输单元（MTU）是单个数据报在特定数据通信链路上可以具有的最大字节数。使用封装，加密或覆盖网络协议会导致端到端有效MTU Size会减小（增加协议头占用有效载荷？）。某些应用程序在减小的MTU Size上可能无法很好地工作，并且无法执行路径MTU发现（PMTUD）。作为应对，能够增加网络链路的MTU Size将是很好的。
MTU Size
最大传输单元（MTU）是OSI模型2层网络数据单元（PDU）的最大可能帧大小。大小取决于通信媒体的物理属性。历史网络媒体速度较慢，更容易出错，因此MTU Size设置得较小。对于大多数以太网，此设置为1500字节，并且此大小几乎在接入网络上普遍使用。以太网第2版网络的标准帧大小为1518字节（包括14字节的Ethernet II标头和4字节的帧检查序列（FCS））。
不过其他通信媒体类型具有不同的MTU Size。例如，T3 / DS3（或E3）和SONET / SDH接口的MTU Size为4470字节（带标头的4474）。
封装开销 Encapsulation Overhead
当一个协议的数据包或帧封装在另一个协议中时，帧大小会整体增加。封装会增加协议标头的开销，因此，通过网络发送1500字节数据包的系统无法以大包的形式发送到另一端（超过默认MTU size，要么分段，要么被丢弃）。协议开销的字节数根据封装类型而变化。
以下是不同的协议封装的开销列表：
- GRE（IP协议47）（RFC 2784）添加24字节（20字节IPv4标头，4字节GRE标头）
- 6in4封装（IP协议41，RFC 4213）增加了20个字节
- 4in6封装（例如DS-Lite RFC 6333）增加了40个字节
- 每当您添加另一个外部IPv4标头时，都会添加20个字节
- DMVPN执行的IPsec加密为ESP-AES-256和ESP-SHA-HMAC开销增加了73个字节（开销取决于传输或隧道模式以及加密/认证算法和HMAC）
- MPLS为堆栈中的每个标签添加4个字节
- IEEE 802.1Q标签添加4个字节（Q-in-Q将添加8个字节）
- VXLAN增加了50个字节
- OTV增加了42个字节
- LISP为IPv4添加了36个字节，为IPv6封装添加了56个字节
- NVGRE增加了42个字节
- STT增加了54个字节
在许多其他情况下，也会发生协议封装，因此您必须注意，这是在传输路径上发生的。尽管这可能很难检测到，但是您的网络文档应注意MTU size小于1500字节的位置。
路径MTU发现（PMTUD）
（路径MTU发现是用来确定到达目的地的路径中最大传输单元(MTU)的大小。通过在IP报头中设置不分片DF(Don't Fragment)标志来探测路径中的MTU值, 如果路径中设备的MTU值小于此报文长度，并且发现DF标志，就会发回一个Internet控制消息协议(ICMP)(类型3、代码4需要分片的消息ICMP_FRAG_NEEDED)，消息中包含它可接受的MTU值。
链接：https://www.jianshu.com/p/b1d890622cb4）
路由器能够对数据包进行分段以将其缩减为较小的尺寸，从而使其适合较小的MTU-size 的隧道，但这并不是最佳选择。当进入网络设备的数据包由于封装而增大时，如果新的总数据包大小超过了发送端口的MTU-size，则网络设备可以在转发数据包之前将其分成两个较小的数据包。 IPv4路由器将对数据包进行分段和转发，并向数据源发送ICMP“数据包太大”错误消息以通知源它应使用较小的MTU-size。 IPv6路由器不会替源对数据包进行分段，而只是丢弃数据包并发回ICMPv6错误消息。
MTU size减小（作者的意思应该是有效载荷减小）导致的主要问题是某些应用程序可能无法在这种环境下正常工作。
一些节点将1500字节数据包发送到DMVPN并随后接收到来自路由器的ICMPv4“数据包太大”消息，节点可能会选择忽略此消息。
这些节点未按照IETF Internet RFC 1191或RFC 1981的规定执行路径MTU发现（PMTUD），因此依赖于IPv4路由器替源主机执行此分段。 RFC 2923还涵盖“路径MTU发现的TCP问题”主题。如果应用程序在此环境中无法正常运行，则可能会对最终用户造成影响。另外，如果通信路径中间有防火墙阻止了ICMP错误消息，那么那肯定会阻止PMTUD正常运行。
测试和检测MTU size减小的一种方法是使用具有large packet size的数据包进行ping测试。
PMTUD方法：
tracepath -n 192.169.31.54
以下是一些有关如何执行此操作的示例：
（ping的参数解释，可以执行 man ping 查看）
C:\Users\ScottHogg> ping -l 1500 192.168.10.1
在Windows主机上，还可以使用“ -f” ping参数将“不分段（DF）”位设置为1。
C：\ Users \ ScottHogg> ping 192.168.10.1 -l 1500 –f
在Linux上，命令为：
RedHat# ping -s 1500 -M do 192.168.10.1
在Cisco IOS设备上，命令将是：
Router1# ping 192.168.10.1 size 1500 df-bit
在Cisco NX-OS设备上，命令为：
Switch7K# ping 192.168.10.1 packet-size 9216 c 10
在Cisco IOS XR设备上，命令将是：
RP/0/RP0/CPU0:Router1#ping 192.168.10.1 size 1500 donnotfrag
在JUNOS设备上，命令如下所示：
root@J4350-1# run ping 192.168.10.1 size 1500 do-not-fragment rapid
分段 Fragmentation
IPv4路由器替源节点对发送的更大数据包的进行分段。除非IPv4标头中的“Do-Not-Fragment (DF)”位设置为1，否则路由器可以对IPv4数据包进行分段。如果DF位设置为0（默认值），则路由器将拆分太大的数据包以适合输出接口，然后将这两个数据包发送到目的地。当目的地接收到两个片段时，目的地的协议栈必须在处理协议数据单元（PDU）之前执行片段的重组。
潜在风险在于应用程序发送其DF = 1的数据包，而没有注意ICMP“数据包太大”消息，并且不执行PMTUD的情况。
windows实验：
-l size 发送缓冲区大小。
-f 在数据包中设置“不分段”标志(仅适用于 IPv4),即“Do-Not-Fragment (DF)”位设置为1PS C:\Users\l24514> ping -l 2000 182.200.31.59
来自 182.200.31.59 的回复: 字节=2000 时间<1ms TTL=64
来自 182.200.31.59 的回复: 字节=2000 时间<1ms TTL=64
PS C:\Users\l24514> ping -f -l 2000 182.200.31.59
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。
来自 182.200.31.254 的回复: 需要拆分数据包但是设置 DF。
所有IPv6网络都必须支持1280字节或更大的MTU size （RFC 2460）。这是因为IPv6路由器不会代替源对IPv6数据包进行分段。 IPv6路由器会丢弃该数据包，并将ICMPv6 Type 4数据包（尺寸超限）发回源，指示正确的MTU size 。然后，它落在源的肩膀上，自行执行分段，并为该目标缓存新的减小的MTU size ，以便将来的数据包使用正确的MTU size 。（It then falls on the shoulders of the source to perform the fragmentation itself and cache the new reduced MTU size for that destination so future packets use the correct MTU size.）
使路由器代替源执行分段的主要问题是会增加路由器上CPU处理的开销。如果使用IPsec，则通道两端的路由器将需要处理数据包的分段和重组。如果路由器代替源节点执行分段，则可能需要在加密之前执行加密 分段。这避免了目标隧道路由器必须（先）重新组装片段然后（才能）执行解密。（it may be desirable to have the encryption performed prior to encryption. This prevents the destination tunnel router from having to reassemble the fragments and then perform the decryption.）
在其他情况下，我们可能希望在加密后进行分段。如果在加密后发生分段，则目标隧道路由器将需要执行重组，然后才能解密数据包，这可能会增加CPU开销。因此，建议大多数网络在加密之前先进行分段。
以下两个Cisco IOS全局配置命令可以控制此行为。
Router(config-if)# crypto ipsec fragmentation before-encryption
Router(config-if)# crypto ipsec fragmentation after-encryption
思科在7600交换机上提供了一份很好的文档，标题为“如何解决这些问题”。 “配置IPSec VPN分段和MTU”：Configuring IPSec VPN Fragmentation and MTUhttps://www.cisco.com/c/en/us/td/docs/interfaces_modules/services_modules/vspa/configuration/guide/ivmsw_book/ivmvpnb.html
MTU 和 MSS
处理由于封装而导致的size增加以及由此产生的分段的另一种方法是利用TCP Maximum Segment Size (MSS)参数。
MSS是能够在单个TCP数据包中发送的最大有效载荷数据字节数。
换句话说，MSS是可以在计算机网络上传输的最大TCP数据（以字节为单位），（MSS size）这是在SYN数据包中的TCP 3次握手过程中协商的。在IPv4的RFC 879和IPv6的RFC 2460中定义了MSS。 MSS不包括TCP标头（20个字节）或IPv4标头（20个字节）（IPv6标头为40个字节）。
在使用IPsec的情况下，习惯上将隧道接口(tunnel interfaces)上的MTU大小设置为1400字节，并将TCP-MSS-adjust设置为1360字节。可以使用以下命令在Cisco IOS设备中进行配置。
Router(config)# interface tunnel 4
Router(config-if)# ip tcp adjust-mss 1360
Router(config-if)# ip mtu 1400
对于支持IPv6的接口，我们可以使用相同类型的功能，但是IPv6 header 为40字节，而不是IPv4的20字节header 。我们还必须考虑20字节的TCP header ，该header 对于IPv4和IPv6是相同的。
Router(config)# interface tunnel 6
Router(config-if)# ipv6 tcp adjust-mss 1340
Router(config-if)# ipv6 mtu 1400
此MSS选项不适用于UDP应用程序，因为在握手过程中由于UDP是无连接协议，因此无法协商此方法。对于不执行PMTUD并将DF = 1设置为UDP的UDP应用，一种选择是配置将DF设置回0的策略。
这是思科关于该主题的一份很好的文档，标题为“解决GRE和IPSEC的IP碎片，MTU，MSS和PMTUD问题”。
“Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC”.：https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
增加MTU Size进行补偿
当站点之间的链接仅支持1500字节MTU，MTU Size的主要问题是封装。通常，企业路由器和上游ISP路由器之间的链接仅支持1500字节的MTU。在CE路由器和PE路由器之间的链路上也是如此。
非常希望能够通过WAN增加MTU Size。如果能够通过WAN增加MTU Size，则可以通过路由器的WAN接口来补偿增加的封装开销。这样就无需减少隧道接口上的MTU大小 就不会减少MTU size的有效载荷，调整MSS并减轻路由器执行任何分段的工作。
推荐建议
重要的是要注意与封装有关的端到端有效MTU Size减少的问题。
这可能发生在unnels, overlay technologies, IPsec links和新的第2层数据中心互连协议中。检测这些问题，对其进行故障排除并纠正问题可能很困难。如果使用封装技术，则应考虑增加MTU Size（如果可能）。您可以询问您的服务提供商，他们是否在其网络内以及在PE与CE路由器之间的链路上支持更大的帧尺寸。至少，您应该记录这些MTU size问题可能在网络拓扑中出现的位置，以便您可以快速解决可能导致的任何应用程序问题。
摘要和笔记
IBM
https://www.ibm.com/docs/en/aix/7.2?topic=tuning-mtu-size-performance-impacts
使用大的MTU size可使操作系统发送较少的大数据包就能达到相同的网络吞吐量。假设工作负载允许发送大消息，则较大的数据包将大大减少操作系统中所需的处理。如果工作负载仅发送小消息，则较大的MTU size 对性能没有提升作用。
如果可能，请使用适配器和网络支持的最大MTU size。例如，在异步传输模式（ATM）适配器上，默认的MTU size=9180比使用1500字节的MTU size（通常由LAN仿真使用）更有效。使用千兆位和10千兆位（ Gigabit and 10 Gigabit）以太网，如果网络上的所有计算机都具有千兆位以太网适配器，而没有10/100适配器 限制，那么最好使用巨型帧模式。例如，计算机实验室内的服务器到服务器连接通常可以使用巨型帧来完成。
延迟将以线性方式随着数据包大小而增加，直到数据包达到MTU限制为止，然后由于数据包必须分段且引入了新的报头，出现明显的（性能）下降。 1500字节的MTU并不意味着将每个数据包都填充到该确切大小。
MTU中jumbo frame性能探讨
首先jumbo frame一般只能提升iSCSI性能，对Server/Client这样的模式提升不大，甚至还会影响到应用。因此通常建议主机至少要两块网卡，一块给应用，一块给iSCSI存储。
大致想了下适用于jumbo frame的应用，主要是大文件、长时间的传输，比如数据备份、音频/视频流媒体和视频/图像编辑。
不适用jumbo frame的情形主要是大小封包共存的环境，这个就主要看对自己应用的了解程度了。
无论文件大小，往返时间长短，何种应用，理论上都可以启用Jumbo Frame的。不过实施时要确保每一个端口都启用。
如果说实施正确的Jumbo Frame反而起了负面作用，我只能想到丢包处理时的不同状况。举个例子，假如现在有8000字节的数据要传，在Jumbo Frame和非Jumbo情况下都有丢包现象，会出现这样的状况：
Jumbo的情况:
source --> dest 巨帧丢失
source陷入等待，这段时间会很长，发送窗口会置为1个MSS。
source --> dest 重传巨桢。
非Jumbo的情况：
Source-->dest 第一个小包
Source-->dest 第二个小包 小包丢失
Source-->dest 第三个小包
Source-->dest 第四个小包
Source-->dest 第五个小包
Source-->dest 第六个小包
dest-->source ack 2号包
dest-->source ack 2号包
dest-->source ack 2号包
dest-->source ack 2号包
Source-->dest 第二个小包 重传二号小包
这种情况下实现了快速重传，所以不需要等待，发送窗口也没有减小得那么厉害。总体来说在这种状况下非jumbo frame性能更好。
