PSA: Incorrect MTU size causes connectivity issues with Windows Server 2012 and Windows Server 2012 R2
Published Sep 20 2018 03:03 AM 35.2K Views

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.


KB 314496 tells us that

  • Each network media type has a maximum frame size.
  • 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 NC382
  • HP NC532
  • 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:

  • Remote file copies fail to complete
  • Shared folders on NAS servers or remote Windows computers cannot be accessed, including admins shares like \%server%c$ or \%server%ipc$
  • Event ID 30620 is logged in the File and Storage Services console
  • Cluster creation fails with RPC error 0x800706BE (where hex error 0x6BE = decimal error 17232 = symbolic error RPC_S_CALL_FAILED = friendly error "the remote procedure call failed" )
  • 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

HP configured smaller MTU defaults in driver version 7.8.x.x, released on 2/18/2014. To check the version of your current driver please look at the properties of bxnd60a.sys. If you are still experiencing issues or are unable to update the driver, please contact the OEM for assistance with this. It is strongly recommended that you update to the latest driver. Below are links to some updated drivers. NC382m




Please leave us comments if you have questions or if you have seen other network adapters/driver combinations affected by this issue. We will update this post if we get any other information.


Thanks, Greg Jaworski


Version history
Last update:
‎Feb 20 2020 06:07 AM
Updated by: