一、如果路由器收到比端口MTU更大的数据包该怎么处理？
实验结论：丢弃
实验过程：
实验设计比较简单，配置两台思科7200的路由器，测试两种情况：（以下ping测已经设置了不可分片）
1、当R2 ping R1时，包大小比R2 的 g1/0 口MTU值要大
2、当R2 ping R1时，包大小比R1 的 g2/0 口MTU值要大
测试1：当R2 ping R1，包大小比R2 的 g1/0 口MTU值要大时，ping不通，在接口上抓包，没有数据包，包出不来
测试2：当R2 ping R1，包大小比R1 的 g2/0 口MTU值要大时，ping不通，在接口上抓包，有数据包，但没有回包，在设备上R1打印debug日志如下，接口上能接收到数据包，但是回包发不出去。
由上述两个实验结果可知，MTU值限制的是出去的包，不挡进入的包。至少对于这两台设备来说是这样的。
那么有没有什么规范写明了这一点，也许是我的英语不好，在IETF的文档里面没找到说明。但是在RFC6691上面有这样的描述，如果数据包太大会被碎片化或者丢弃。另外提一句，RFC6691并不是Proposed Standard RFC，只是Informational RFC。所以也没找到什么官方支持论点，思科的官网我就懒得查了。
二、路由来回不同路的问题
RFC1191、RFC1981、RFC4821规定了PMTUD的路径MTU发现机制，什么是PMTUD？这是知乎链接https://zhuanlan.zhihu.com/p/101811974，在知乎的这个回答的最后，写了一句“当网络中存在 tunnel 时，例如 GRE, IPsec 等我们需要对 MTU 格外的小心，因为 tunnel 的 header 会增加额外的数据长度，我们的 MTU 需要进一步的缩小。Tunnel 相关的 MTU 设定将在今后的文章中介绍。”
我不知他的今后的文章在哪里，我就说一下这问题，https://www.imperva.com/blog/mtu-mss-explained/，这个链接的文章就承接了知乎后面的内容，文章是英文的，我来翻译翻译（什么是TM的惊喜）
文章大概内容就是说，数据包一般大小是1500字节，因为碎片化的数据包有可能不被中间设备支持造成丢包，所以我们尽量避免碎片化，所以我们可以控制TCP MSS的方式来减小数据包的大小，如下图，减去包头包尾，只剩下1460字节的MSS。
上述是一般情况下，但如果我们使用了其他协议，诸如GRE协议，包头又会多一些字节，如下图，这样的话，如果MSS还是1460字节，数据包总大小就变成1524字节，超过原本1500的长度。这种情况下，可以在网络设备上配置TCP MSS的值，使之降到1436或者更低。
然后文章再列举了下面的例子，再三次握手建立时期，设备告知用户设备将TCP MSS调整了1420，那就一切问题都迎刃而解了。
但这就结束了吗？NO，重点来了。
单条GRE线路是如此，但多条线路呢？我拿上面的图P一下，假如用户有两种连接路径可以访问服务器呢？就像下图，我们在原有GRE线路（绿色）的基础上，新增了一条可访问的路径（红色），这条红色的路径因为没有使用GRE所以MSS的大小还是1460。
那么一个有意思的问题来了，如果TCP在三次握手的时候，用户到服务器的默认路径是走绿色这台，它告知服务器它使用的MSS是1460；服务器默认使用的是红色这条，它告知用户它MSS 也是1460，来去路径不一致。嘿嘿，问题就来了，如果服务器给用户发1500的数据包，走红色线，OK，包能到；如果用户给服务器发1500的数据包，走绿色线，就会被GRE路由器丢弃，服务器就收不到用户的包。
（跟文章第一点“如果路由器收到比端口MTU更大的数据包该怎么处理”呼应起来了嘿嘿嘿）
怎么处理呢？没建议，具体问题具体分析吧您嘞。
林总技术支持了一个思科的链接，也说明MTU相关知识
https://www.cisco.com/c/zh_cn/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html#anc21