2

I recently discovered a Windows 7 client that couldn't connect to one of our servers. It turned out the problem was both that the server was set for an MTU of 1514 and that the client was set to 1504.

The server runs CentOS and grep -i MTU /etc/sysconfig/network-scripts/ifcfg* shows nothing. The non-public interface eth1 was still 1500. None of our other machines on the server side have anything other than 1500 for an MTU.

On the client side, there was one other Windows 7 machine in the mix that also had 1504. Taking these machines off-site caused them to work again (but I don't know if that was in spite of the bad MTU, or if the new location caused Windows to select a valid one), but failed once brought back.

  1. What would have caused these two Windows machines to have this non-standard MTU setting? How does Windows determine MTU settings?

  2. Why would eth0 have had an MTU setting of 1514? How does Linux determine MTU settings?

  3. Should I hard-code MTU=1500 into all my ifcfg files from now on for fear that something else will bump it higher? What would override the default of 1500?

Community
  • 1
rymo
  • 513
  • 1
  • 3
  • 13
  • I would do a grep of `/etc/` for 1514. The default is `1500`, I would bet you already have something changing it. – Zoredache Mar 14 '12 at 19:55
  • @Zoredache the only non-binary instance of `1514` found was in `/etc/services` (port naming) – rymo Mar 14 '12 at 20:15
  • 2
    If you are using trunked VLANs on an interface the MTU is automatically increased to 1504 to allow for the 4 byte 802.1Q header. – Mark Wagner Mar 14 '12 at 23:20
  • @MarkWagner +1 for the first plausible explanation of 1504, but in this case the client machine was directly connected to a combination cable modem/gateway from Comcast that had been reset to factory defaults and I didn't see any VLAN settings enabled in the web interface – rymo Mar 14 '12 at 23:24
  • 2
    The change in behavior between network locations is likely due to the dropping of ICMP packets in the main location; fix that if possible. Path MTU Discovery would prevent the issue that you're having. – Shane Madden Mar 15 '12 at 03:43
  • @ShaneMadden I've found I can replicate the behavior on other networks by manually setting MTUs higher than 1500 on both ends, which leads me to believe the location itself was causing Windows to choose 1504. Should I be able to see these dropped ICMP packets on Wireshark somewhere? `cat /proc/sys/net/ipv4/ip_no_pmtu_disc` returns `0` – rymo Mar 17 '12 at 00:16
  • Are there firewalls involved anywhere? They're usually the culprit when ICMP is stepped on. – Shane Madden Mar 17 '12 at 00:18

1 Answers1

1

The client can perform Path MTU Discovery, which is the smallest MTU on the complete path between two devices, and then reduce the MTU to match. This is particularly necessary for traffic that shouldn't be fragmented, such as IPSec.

As Shane Madden mentions in the comments above dropped ICMP packets in the path will break this. I suspect there are some switches on the market that have all ICMP blocked by default, so I would check to see whether any new switches or routers were introduced and whether they need to have ICMP traffic enabled.

dunxd
  • 9,482
  • 21
  • 80
  • 117