First published on TechNet on Dec 01, 2014 Greg Jaworski here to make readers aware of a support issue where network interface drivers may set an overly large MTU value of 1514 bytes.
Problems arise when such large packets cannot be passed by the underlying network infrastructure. As this blog post will illustrate, connectivity failures caused by this condition can cause an array of operational failures as simple a file copy to RPC connectivity disruptions used by numerous management and distributed operations on Windows computers.
Maximum Transfer Unit (MTU) specifies the maximum packet size for a given network interface
The largest packet allowed by Ethernet networking layer is 1500 bytes.
Larger MTU support (jumbo frames) may be configured when using overlay technologies like Hyper-V network virtualization and network operators must make sure that all the networking equipment like switches and routers can support larger MTUs.
Software developers have been known to configure > 1500 byte MTUs as was the case when several drivers for HP-branded Broadcom NICs slipped out the door with a default MTU of 1514 bytes. Support cases involving the following NICS have been opened but other make and model NICs could be impacted.
HP Flex-10 10Gb 2-port 530FLB
Affected NIC driver versions for the HP-branded 1 GB Broadcom NICs start with version 7.4.X.X. In some rare cases Windows Server 2008 R2 is also affected. For Windows Server 2008 R2 this scenario only occurs if the NCU software was never installed or is removed.
Regardless of what make and model NIC you have, we recommend that you run two simple NETSH and PING commands to verify that the network drivers connected to your networks are using MTU values compatible with the underlying network.
Operational failures and errors caused by large MTU values include but are not limited to:
Server Manager and other administrative tools connect or manage remote computers
Creating a new 2 node failover cluster or adding a new node to an existing cluster fails with error "RPC_S_CALL_FAILED" (The remote procedure call failed)
Sending WMI commands to a remote server fails with error "RPC_S_SERVER_UNAVAILABLE" (The RPC server is unavailable)
RPC operations, SMB connection, WinRM and other operations fails with error including but not limited to:
"The remote procedure call failed"
"The client cannot connect to the destination specified in the request"
"The specified network name is no longer available"
These types of network issues can be especially difficult to troubleshoot since MTU size is not typically a top-of-mind root cause.
Determining if your system is affected:
The NETSH command can be used to verify the current MTU settings used by IPv4 and IPv6. This is a good command to run regardless of the hardware make and link speed you have. < netsh int ipv4 show int >
< netsh int ipv6 show int > Good system: Idx Met MTU State Name
--- ---------- ---------- ------------ --------------------------- 1 50 4294967295 connected Loopback Pseudo-Interface 1 17 5 1300 connected Local Area Connection* 11 22 5 1500 connected vEthernet (Corpnet) 13 10 1500 connected Private 14 10 1500 connected iSCSI Bad System: Idx Met MTU State Name ---- ---------- ----------------- --------------- --------------------------- 1 50 4294967295 connected Loopback Pseudo-Interface 1 13 10 1514 connected Local Area Connection 1 14 10 1514 connected Local Area Connection 2 18 5 1500 connected Local Area Connection 3 If Jumbo Frame support is enabled, you'll see an even larger value like 9000 for MTU. Don't modify the MTU value.
An MTU value of 1514 however is likely caused by NIC driver and could cause problems If the underlying network infrastructure doesn't support jumbo frames (in which case the MTU value would be much bigger than 1514) You can also use the PING command to identify the largest unfragmented ICMP packet that a given computer can send to various remote computers on your network. An example here would be: ping–f –l 1472 hostname Where –f sets the Do Not Fragment bit –l sets the length of the ICMP packet IPv6 does not support the DF flag so the -4 argument can only be used with IPv4 and is not needed with -f. Retry the PING command using larger values for the –l parameter until you either reach 1500 bytes or the command fails with the error: Packet needs to be fragmented but DF set
From an admin-privileged CMD prompt, reset the MTU to the Ethernet default of 1500 bytes:
netsh interface ipv4 set subinterface 13 mtu=1500 store=persistent netsh interface ipv4 set subinterface 14 mtu=1500 store=persistent netsh interface ipv6 set subinterface 13 mtu=1500 store=persistent netsh interface ipv6 set subinterface 14 mtu=1500 store=persistent