To reproduce: create a static IPv6 route with a specific mtu/advmss attribute, then open a TCP connection to a host (never contacted before) within this route: this creates a cache entry with additional information (such as rtt); when these data expire, the route mtu/advmss are also forgotten, even though they are specified in the (static) routing table. E.g. (using www.kame.net = 2001:200:dff:fff1:216:3eff:feb1:44d7 as example): david@terre:~$ sudo ip route get 2001:200:dff:fff1:216:3eff:feb1:44d7 2001:200:dff:fff1:216:3eff:feb1:44d7 from :: via fe80::20e:a6ff:fef1:db7f dev eth0 src 2001:7a8:78ae:37:21f:c6ff:fec1:c877 metric 0 cache david@terre:~$ sudo ip route add 2001:200:dff:fff1::/64 from :: via fe80::20e:a6ff:fef1:db7f dev eth0 src 2001:7a8:78ae:37:21f:c6ff:fec1:c877 mtu 1460 advmss 1400 david@terre:~$ sudo ip route get 2001:200:dff:fff1:216:3eff:feb1:44d7 2001:200:dff:fff1:216:3eff:feb1:44d7 from :: via fe80::20e:a6ff:fef1:db7f dev eth0 src 2001:7a8:78ae:37:21f:c6ff:fec1:c877 metric 0 cache mtu 1460 advmss 1400 david@terre:~$ wget -O /dev/null 'http://[2001:200:dff:fff1:216:3eff:feb1:44d7]/' (...) david@terre:~$ sudo ip route get 2001:200:dff:fff1:216:3eff:feb1:44d7 2001:200:dff:fff1:216:3eff:feb1:44d7 from :: via fe80::20e:a6ff:fef1:db7f dev eth0 src 2001:7a8:78ae:37:21f:c6ff:fec1:c877 metric 0 cache mtu 1460 rtt 324ms rttvar 324ms cwnd 10 advmss 1400 hoplimit 255 david@terre:~$ sleep 30 david@terre:~$ sudo ip route get 2001:200:dff:fff1:216:3eff:feb1:44d7 2001:200:dff:fff1:216:3eff:feb1:44d7 from :: via fe80::20e:a6ff:fef1:db7f dev eth0 src 2001:7a8:78ae:37:21f:c6ff:fec1:c877 metric 0 cache hoplimit 64 In the last output, the mtu and advmss for the route have been forgotten, even though the route is still supposed to be active. This is not just the output of "ip" which is bad: actually opening a TCP connection at this point will use a wrong MSS. A similar bug might be present in IPv4 routes, but I found it trickier to reproduce, so I'm not entirely sure whether this is really an IPv6-related problem.
Please test this bug to see if it's fixed on the latest kernels. Cheers Nick
Fixed in 8e2ec639173f325977818c45011ee176ef2b11f6 (merged in v3.1-rc7).