mtu范围不对怎么解决（谈谈MTU和ping的那些事）

弈心：从事计算机网络工作十年（新加坡7年，沙特3年），2013年考取CCIE，在新加坡先后任职于AT&T，新加坡交通部，苹果，Equinix，苏格兰皇家银行等大型企业、银行和政府部门。 目前供职于“世界第一土豪大学“沙特阿卜杜拉国王科技大学（KAUST），担任Senior Network Engineer，为KAUST校史上第一位也是唯一一位华人IT部门高级职员。2019年6月在知乎发布了华语圈第一本专门为编程零基础的网络工程师量身打造的Python教程《网络工程师的Python之路》。

前两篇讲ACL和四层碎片关系、C家和J家哪家在GRE隧道开启了DF-bit的技术文章有人说太过深奥，也有人说工作中不太会碰到，那今天就来一篇通俗易懂又兼具实用性的，对，就是MTU和ping。

MTU, （Maximum Transmission Unit 最大传输单元）是干什么用的大家都懂，想必各位也都知道可以用ping命令来测试网络设备MTU的大小来达到排错的目的，所以关于MTU和ping的具体原理就不讲了，今天主要讲下不同厂商设备（Cisco和Juniper）对待MTU的不同“态度”以及在C家和J家的设备商上使用ping这个命令时的一些细微差异。

先来说说Juniper。J家的Junos是搭建在FreeBSD上的（更精确点说，Junos的控制平面就是FreeBSD的kernal）。FreeBSD和Windows一样，用户在用ping这个命令的时候，实际的ping包大小是不包含20 Byte的IP header和8 Byte的ICMP header的。也就是说操作系统会自动给你的ping包加上这28 Byte，然后再将你的ping包发出去。什么意思呢？ 我们来做个实验：

在Windows上做三次ping，分别指定ping包大小为1500、1473和1472Byte, 三次ping均开启df-bit。

Windows

X:\>ping 192.168.1.1 -l 1500 -f Pinging 192.168.1.1 with 1500 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), X:\>ping 192.168.1.1 -l 1473 -f Pinging 192.168.1.1 with 1473 bytes of data: Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Packet needs to be fragmented but DF set. Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), X:\>ping 192.168.1.1 -l 1472 -f Pinging 192.168.1.1 with 1472 bytes of data: Reply from 192.168.1.1: bytes=1472 time=25ms TTL=255 Reply from 192.168.1.1: bytes=1472 time=4ms TTL=255 Reply from 192.168.1.1: bytes=1472 time=4ms TTL=255 Reply from 192.168.1.1: bytes=1472 time=3ms TTL=255 Ping statistics for 192.168.1.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 3ms, Maximum = 25ms, Average = 9ms

为什么ping包大小为1500，1473 Byte的时候ping不通呢？原理前面提到了，这是因为Windows“偷偷”地给你的ping包加上了28 Byte。所以你前两次ping包的实际大小为1528和1501 Byte，已经超出了默认的MTU (1500), 并且因为开启了df-bit，导致ping包无法被分片而被丢弃。而第三次当你指定ping包为1472的时候，加上windows给你的加上的28 Byte, 你的实际PING包大小刚好等于1500 byte，所以ping 通了。

同样的原理也适用于Junos:

JUNOS

root@Junos# run ping 10.10.1.2 size 1500 do-not-fragment rapid PING 10.10.1.2 (10.10.1.2): 1500 data bytes ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long . — 10.10.1.2 ping statistics — 5 packets transmitted, 0 packets received, 100% packet loss root@Junos# run ping 10.10.1.2 size 1473 do-not-fragment rapid PING 10.10.1.2 (10.10.1.2): 1473 data bytes ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long .ping: sendto: Message too long . — 10.10.1.2 ping statistics — 5 packets transmitted, 0 packets received, 100% packet loss root@Junos# run ping 10.10.1.2 size 1472 do-not-fragmentrapid PING 10.10.1.2 (10.10.1.2): 1472 data bytes !!!!! — 10.10.1.2 ping statistics — 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.861/0.908/1.065/0.079 ms

但是思科不一样，不论是C家的IOS还是IOS-XR，用户所指定ping包的大小已经包含了那个多出来的28byte (20 byte的IP header，8 byte 的ICMP header)，也就是说在C家的设备上的ping才是包含了各种header的完整的ping。

下面分别在C家的IOS和IOS-XR来做测试，测试结果证明了这点。

IOS

Router#ping 10.10.1.1 size 1500 df-bit Type escape sequence to abort. Sending 5, 1500-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds: Packet sent with the DF bit set !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms Router#ping 10.10.1.1 size 1501 df-bit Type escape sequence to abort. Sending 5, 1501-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds: Packet sent with the DF bit set ….. Success rate is 0 percent (0/5)

IOS XR

RP/0/RP0/CPU0:P2#ping 20.20.20.1 size 1500 donnotfrag Sun Feb 7 07:13:57.440 UTC Type escape sequence to abort. Sending 5, 1500-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms RP/0/RP0/CPU0:P2#ping 20.20.20.1 size 1501 donnotfrag Sun Feb 7 07:14:09.290 UTC Type escape sequence to abort. Sending 5, 1501-byte ICMP Echos to 20.20.20.1, timeout is 2 seconds: M.M.M Success rate is 0 percent (0/5)

前面讲到的是3层的ping包，在2层环境中，数据包还会被封装上一个14byte的Ethernet Header，因为这个14byte，导致端口MTU在C家和J家的设别上又有十分微妙的不同。

运行IOS的C家设备的端口MTU是不包括这个14byte的，但是IOS-XR和JUNOS却又相反，啥意思呢？还是举例来看吧：

Cisco IOS

router#sh ip interface g0/1 | i MTU
MTU is 1500 bytes

Cisco IOS XR

RP/0/RP0/CPU0:router#sh ip interface g0/1/0/1 | i MTU
MTU is 1514 (1500 is available to IP)

JUNOS

root@router# run show interfaces ge-0/0/1 | match MTU
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,MAC-REWRITE Error: None, Loopback: Disabled,
Protocol inet, MTU: 1500
Protocol iso, MTU: 1497
Protocol mpls, MTU: 1488
Protocol multiservice, MTU: Unlimited

另外一点，在你手动改变端口MTU大小的时候，IOS, IOS-XR, JUNOS之间也有很大的差异。举个例子，在使用dot1q的环境下，dot1q会给包额外加入一个4byte的VLAN tag，加上之前提到的2层封装的14byte，这样MTU变成了1518byte，在对待这个4byte的tag时，IOS和JUNOS不会理会它，你必须手添加这4个byte，而IOS-XR则不需要。

啥意思呢？也就是说在使用dot1q的环境中，如果你现在在IOS或者JUNOS设备上手动把端口MTU从1500改成1514，IOS和JUNOS会继续使用1514，不做任何改变。而IOS-XR不同，IOS-XR会主动为子端口（什么？为啥是子端口？你忘了啥叫“独臂路由”了吗）加上4byte，将子端口的MTU变成1518byte （主端口的MTU依然是1514byte）。

Cisco IOS

router#sh interfaces g0/1 | i MTU
MTU 1514 bytes, BW 100000 Kbit, DLY 100 usec,
router#sh ip interface g0/1.1 | i MTU
MTU is 1514 bytes

JUNOS

root@router# run show interfaces ge-0/0/1 | match MTU
Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,MAC-REWRITE Error: None, Loopback: Disabled,
Protocol inet, MTU: 1500
Protocol iso, MTU: 1497
Protocol mpls, MTU: 1488
Protocol multiservice, MTU: Unlimited

Cisco IOS XR

RP/0/RP0/CPU0:router#sh ip int g0/1/0/9 | i MTU
Wed Oct 6 21:35:07.274 CLT
MTU is 1514 (1500 is available to IP)

RP/0/RP0/CPU0:router#sh ip int g0/1/0/9.1 | i MTU
Wed Oct 6 21:35:11.972 CLT
MTU is 1518 (1500 is available to IP) --------- 看到变化了吗？

不要小看这些细小的差距，细微之处见真功夫，任何涉及到MTU的网络问题都不简单，与大家共勉。