27

When I ping a remote site with the DF bit set and a packet size that is too big for my router the first ICMP "fragmentation required" message is sent from the router. After that the message comes from my localhost.

Netstat -rC (on Linux) allows me to view the routing table cache, but

1) Seems to show MTUs under a column called MSS (which I would expect to be the lower TCP MSS of the link)

2) Always shows the value as 1500

My localhost must be caching the PMTU somewhere so it can generate the fragmentation required message. But how do I see that?

Here is an example on my machine (-n on netstat inhibits reverse DNS lookups):

[root@vbcentos ~]# ping -c 4 -M do -s 1431 212.58.244.69
PING 212.58.244.69 (212.58.244.69) 1431(1459) bytes of data.
From 217.155.134.6 icmp_seq=1 Frag needed and DF set (mtu = 1458)
From 217.155.134.4 icmp_seq=2 Frag needed and DF set (mtu = 1458)
From 217.155.134.4 icmp_seq=2 Frag needed and DF set (mtu = 1458)
From 217.155.134.4 icmp_seq=2 Frag needed and DF set (mtu = 1458)

--- 212.58.244.69 ping statistics ---
1 packets transmitted, 0 received, +4 errors, 100% packet loss, time 1002ms

[root@vbcentos ~]# netstat -rCn
Kernel IP routing cache
Source          Destination     Gateway         Flags   MSS Window  irtt Iface
217.155.134.3   217.155.134.4   217.155.134.4   il        0 0          0 lo
217.155.134.4   212.58.244.69   217.155.134.6          1500 0          0 eth0
217.155.134.4   217.155.134.4   217.155.134.4   l     16436 0          0 lo
217.155.134.3   217.155.134.255 217.155.134.255 ibl       0 0          0 lo
217.155.134.4   212.58.244.69   217.155.134.6          1500 0          0 eth0
217.155.134.6   217.155.134.4   217.155.134.4   il        0 0          0 lo
212.58.244.69   217.155.134.4   217.155.134.4   l         0 0          0 lo
[root@vbcentos ~]#

EDIT: As per suggestion:

ip route get to 212.58.244.69

gives

212.58.244.69 via 217.155.134.6 dev eth1  src 217.155.134.4
    cache  mtu 1500 advmss 1460 hoplimit 64

Which also seems wrong as the MSS is just 40 less than the mtu, which is the interface mtu rather than the PMTU

3
  • 1
    On Fedora 22, netstat -rCn returns nothing, but watch ip route get to $HOST shows what's up, including the cache TTL. ip route show cached shows probably also output something but does not. Feb 13, 2016 at 20:53
  • 1
    I've tried on both Debian 9 and on Fedora 34 ip route get to IP and it does not show the mtu
    – sebelk
    Oct 19, 2021 at 22:16
  • @sebelk From man ip-route: Starting with Linux kernel version 3.6, there is no routing cache for IPv4 anymore. Aug 1, 2022 at 0:07

4 Answers 4

14

Maybe

ip route get to 212.58.244.69
1
  • Edited question to add this.
    – Neik
    Aug 28, 2013 at 9:17
4

Under Windows, use the netsh command to view the "destination cache" which holds this information. For example (assuming IPv4):

netsh interface ipv4 show destinationcache
2

MSS should be 40 bytes less than your MTU (it doesn't include IPv4 (20 bytes) and tcp (20) byte headers). So that is correct.

ICMP fragmentation needed message is sent by the router, not your server.

1
  • MSS should be 40 bytes less than the PATH MTU, which is 1458 (assuming PMTUD is working, which appears to be the case.) And yes, of course, the ICMP fragmentation is sent from the router, which is what the OP says. Aug 24, 2022 at 20:22
1

The route get doesn't work for me either. But what worked was route show cache For IPv6 ip -6 route show cache shows everything that is currently cached. And the ip -6 route get 2001:470:1:18::3:1280 shows the PMTU for the specified target.

To test this use the curl command from this test page: https://test-ipv6.com/faq_pmtud.html

Related ip route documentation: http://linux-ip.net/html/tools-ip-route.html#tools-ip-route-show-cache

If you want an alternative to PMTU on IPv4 look at this cloudflare article: https://blog.cloudflare.com/path-mtu-discovery-in-practice/ which mentions "Enable smart MTU black hole detection" which can be enabled (temporarily) by: echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing; echo 1024 > /proc/sys/net/ipv4/tcp_base_mss

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .