Article ID: 159211 - View products that this article applies to.
This article was previously published under Q159211
For a Microsoft Windows XP version of this article, see 314825
On a TCP/IP wide area network (WAN), communication over some routes may fail if intermediate network segments have packet sizes smaller than the communicating hosts, and routers do not send appropriate ICMP responses to this condition. Alternatively, the firewall on the path may drop such responses. A router that causes this condition is sometimes known as a "black hole" router. The Ping utility, a standard utility installed with the Microsoft Windows TCP/IP protocol, can be used to find black hole routers. Some recommendations are provided to work around or fix problems with black hole routers.
When a network router receives a packet larger than the Maximum Transfer Unit (MTU) of the next network segment, and that packet's IP layer "don't fragment" bit is flagged, the router should send an ICMP destination unreachable message back to the sending host. When this does not happen, packets can be dropped, causing a variety of errors that will vary with the application that is communicating over the failed link. These errors will not occur when an application connects to a computer on a local subnet. The problem may seem intermittent, but on closer examination, it can be duplicated, such as in having a client read a large file from a remote host.
The Ping utility can be used to find black hole routers by using the -f (do not fragment) and the -l (buffer size) parameters. Setting the -f parameter will cause the Ping utility to send an ICMP echo packet with the IP "do not fragment" bit set. The -l parameter sets the buffer, or payload, size of the ICMP Echo packet. The largest buffer that can be sent unfragmented equals the MTU minus the IP and ICMP headers (MTU-28) of the smallest MTU along a route. For example, because Ethernet has an MTU of 1500 bytes, under the best circumstances, Ping could echo an unfragmented packet with an ICMP buffer of 1472 bytes. The syntax for Ping in this case would be:
Ping <computer name or IP address> -f -l 1472
This should work on all local IP addresses. If the MTU of all segments of a routed connection are 1500 or larger, the packet should be returned as well. If there are intermediate segments with smaller MTUs, and routers return the appropriate ICMP Destination Unreachable packet, the utility should display "Packet needs to be fragmented but DF set". If there are segments along the route with smaller MTUs, and the appropriate ICMP packet is not returned, the Ping utility should display "Request timed out." The default MTUs of common network media are described in Knowledge Base article 314496
By changing the -l parameter on successive Pings, the largest unfragmented packet that will travel a specific route can be found. The smallest MTU in general use is 576 bytes, so you should be able to safely start with an ICMP buffer of 548, then work up from there. For example, if Ping <host name or address> -f -l 972 returns packets and Ping <host name or address> -f -l 973 fails, the largest MTU that can be used over that route is 1000 (972+28).
To fix or work around black hole routers, there are four possible solutions:
(https://support.microsoft.com/kb/120642/ )TCP/IP and NBT configuration parameters for Windows 2000 or for Windows NT
(https://support.microsoft.com/kb/128797/ )Unable to transfer files across DEC 250 and DEC 500 routers
(https://support.microsoft.com/kb/136970/ )PMTU black hole detection algorithm change for Windows NT 3.51
(https://support.microsoft.com/kb/138575/ )Communication fails through Ethernet segment between FDDI rings
314496For more information, see Internet RFC 1191 and RFC 1435. To do this, visit the following Web site:
(https://support.microsoft.com/kb/314496/ )The default MTU sizes for different network topologies
http://www.faqs.org/rfcs/See also chapter 6, "TCP/IP Implementation Details," in the Windows NT Server Resource Kit. To do this, visit the following Microsoft Web site:
Article ID: 159211 - Last Review: March 1, 2009 - Revision: 6.2