debian, kernel 3.2.54/60/73. i'm using gre interfaces on top of ipsec
tunnels. these gre interfaces have mtu 1400 on my entire network.
normally i see this kind of tracepath output:
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
but for some reason i got one case when tracepath gives different result:
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
all gre interfaces on 192.168.yyy.251 have mtu 1400, all are configured
identically. the 10.zzz.251.1 router doesn't send any ICMP fragm needed
packets, gre interface of course with mtu 1400. 192.168.yyy.251
generates ICMP fragm needed but i have no clue why. ip route get
10.zzz.255.111 on 192.168.yyy.251 router shows:
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
additionally from time to time (i suspect it depends on traffic) mtu of
the route changes and gets heavily lowered and for 10mins (mtu cache
expiry) i can't make any new connections that need bigger packets -- but
old established connections are working fine. so how the kernel
calculates mtu for routes? what else except mtu of outgoing interface is
taking its part in pmtu calculation?
--
... Rafał Mielnik
... RM-IT Usługi Informatyczne
... +48608025394
... r.miel...@rm-it.pl
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
