我在我的networking中观察到相当奇怪的（至less对我来说）几条路线的行为。 我在ipsec隧道上使用gre接口。 这些gre接口在我的整个networking上都有mtu 1400。 通常我看到这种tracepath输出：
1?: [LOCALHOST] pmtu 1500 1: 10.xxx.101.1 13.625ms 1: 10.xxx.101.1 13.178ms 2: 10.xxx.101.1 13.973ms pmtu 1400 2: 192.168.yyy.251 56.555ms 3: 192.168.yyy.92 643.252ms 4: 192.168.yyy.28 417.291ms 5: 192.168.zzz.129 517.893ms reached 但由于某种原因，当tracepath给出不同的结果时，我得到了一个案例：
1?: [LOCALHOST] pmtu 1500 1: 10.xxx.101.1 13.625ms 1: 10.xxx.101.1 20.857ms 2: 10.xxx.101.1 11.954ms pmtu 1400 2: 192.168.yyy.251 46.456ms 3: 192.168.yyy.251 45.563ms pmtu 1376 3: 10.zzz.251.1 56.648ms 4: 10.zzz.255.111 55.212ms reached
所有192.168.yyy.251上的gre接口都有mtu 1400，全部configuration完全相同。 10.zzz.251.1路由器不发送任何ICMP碎片需要的数据包，gre接口当然与mtu 1400. 192.168.yyy.251产生ICMP碎片需要，但我不知道为什么。 ip route get 10.zzz.255.111在192.168.yyy.251上ip route get 10.zzz.255.111路由器显示：
10.zzz.255.111 from 10.xxx.101.253 tos lowdelay via 10.zzz.251.1 dev GRE_OUTPUT_INTERFACE src 192.168.yyy.251 mark 0x2071 cache expires 264sec ipid 0x607b mtu 1376 iif GRE_INPUT_INTERFACE
另外时不时（我怀疑这取决于交通）路线MTU的变化，并大大降低和10分钟（MTUcaching到期）我不能做任何新的连接，需要更大的数据包 – 但老build立的连接工作精细。 嗯？
我想说这是由于GRE隧道被路由到另一个GRE隧道造成的。 您的临时问题可能是IPSEC隧道出现故障几秒钟。