A PMTUD black hole can cause a particularly subtle set of issues in hybrid cloud-based environments where the cloud resources are connected to a corporate office or other datacenter via IPSec tunnels. PMTUD black holes basically cause certain (but not all) traffic to not make it through the tunnel.

PMTUD Overview
Before we get down and dirty into the problems with PMTUD, let's quickly go over what PMTUD is.

PMTUD stands for Path Maximum Transmission Unit Discovery and it is a protocol/algorithm defined in RFC 1191 that determines the best packet size for IPv4 datagrams flowing between any two given hosts. In this way, it attempts to optimize traffic through the Internet by using the largest possible datagram that doesn't require intermediary routers to fragment the traffic (since fragmentation and, more importantly, reassembly are expensive operations for routers to perform).

It works like this ... if I'm a host (say an FTP server) who wants to send the largest packet I possibly can to another host (say an FTP client), I will start with what I know, which is the maximum transmission unit (MTU) of my underlying ethernet interface (normally 1500 bytes). I will then send this packet out with the Don't Fragment (DF) bit set in the IPv4 header. If a router in the path would need to fragment this packet in order to send it along to the next hop (because its outbound interface was, say 1450 bytes), it will send back an Internet Control Message Protocol (ICMP) reply indicating that fragmentation was needed, but the DF bit was set. The implication is that the packet was dropped. In this ICMP reply, it also specifies what the MTU should be (in this case 1450 bytes). The originating host will then resend a packet of this size. This can happen multiple times if, for example, another router later on down the path has an even smaller MTU on its outbound interface. Eventually the packet gets to the destination host using a size that is the most optimal for the path and all subsequent 'large' packets will also be this optimal size.

Nowadays, PMTUD often comes into play when we're talking about tunneling traffic. Since tunnels require that some extra headers be inserted, they have an effective MTU that is the original ethernet MTU less the size of the additional headers.

The Problem with PMTUD
There are a few common causes for not being able to get the ICMP replies necessary for PMTUD to work. Overzealous network administrators will configure their firewalls to drop all ICMP since certain ICMP messages are considered security threats. Routers are sometimes (mis) configured with PMTUD disabled and so will simply drop the packet without sending the required ICMP message.

As we can see, the ICMP messages that PMTUD requires to work can be kept from the originating host due to various factors beyond the host's control, and often beyond the control of even the network administrators responsible for the network to which the host is directly attached.

What's the problem with PMTUD. The real problem with PMTUD is that it fails closed. This is anathema to the Robustness Principle, and it is a well understood problem by the Internet Engineering Task Force (IETF) as evidenced by RFC 2923:

"PMTUD, as documented in RFC 1191, fails when the appropriate ICMP messages are not received by the originating host. The upper-layer protocol continues to try to send large packets and, without the ICMP messages, never discovers that it needs to reduce the size of those packets. Its packets are disappearing into a PMTUD black hole."

The most common symptom of hitting a PMTUD black hole is that some, but not all traffic seems to make it between hosts. A Transmission Control Protocol (TCP) connection may be established for a file transfer and then stall out. If the ICMP messages are only being dropped in one direction, the same file transfer in the other direction might work just fine.

RFC 1191 doesn't speak to what the host implementation should do if it fails to receive protocol packets. It leaves that as an exercise to the upper layer protocol implementor. Is this the fault of the RFC 1191 contributors? Probably. They should have dictated that, by default, when exceeding an implementation specific timeout, upper layer protocols must cease to set the DF bit in packets that they send.

RFC 2923 basically says as much by suggesting that TCP do this as a fix for the issue:

"TCP should notice that the connection is timing out. After several timeouts, TCP should attempt to send smaller packets, perhaps turning off the DF flag for each packet."

IPv6 takes the problem completely out of the hands of the routers by failing hard open. Again, from RFC 2923:

"Note that, under IPv6, there is no DF bit-it is implicitly on at all times. Fragmentation is not allowed in routers, only at the originating host. Fortunately, the minimum supported MTU for IPv6 is 1280 octets, which is significantly larger than the 68 octet minimum in IPv4. This should make it more reasonable for IPv6 TCP implementations to fall back to 1280 octet packets, when IPv4 implementations will probably have to turn off DF to respond to black hole detection."

RFC 2923 opines that:

"This creates a market disincentive for deploying TCP implementation with PMTUD enabled."

However, host networking stacks did implement PMTUD, but allowed it to fail closed. Since RFC 2923, host networking stacks have implemented variations of its suggestions. The Linux networking stack, as of 2.6.17 mainline, implemented TCP MTU probing described in RFC 4821, although it is not enabled by default. The Windows networking stack has implemented PMTUD black hole detection, and recently made it the default in Win2k8, Vista, Windows 7, and Windows 8.

Solutions
This leaves us still living with PMTUD black holes. I often see this when we connect our cloud networks, via an IPSec VPN, to our customer's corporate networks. Many of these customer networks are large and managed by various different groups; often there is a router or firewall that blocks all ICMP or simply doesn't participate in PMTUD. The hosts tend to be heterogenous, consisting of various versions of Windows and different *NIXs and so some of them will detect PMTUD black holes and others won't. This makes debugging difficult.

As a workaround, routers and tunnel endpoints have implemented MSS (Maximum Segment Size) clamping, which utilizes a part of TCP whereby the largest acceptable payload size (the MSS) is exported to the remote TCP connection endpoint as an option during the TCP connection handshake. The MSS is orthoganally bidirectional, meaning the MSS for one half of the connection can be different than the MSS of the other.

Normally the MSS is set by the originating host based on the MTU of its outbound interface. However, an intermediary router/firewall can modify the MSS based on the knowledge it has about the MTU of its interfaces. If the destination interface is one that has an MTU too small for the MSS it sees in the TCP SYN packet, it will rewrite the MSS option. In this way, intermediary routers attempt to fix PMTUD issues for TCP connections.

TL;DR
In summary, PMTUD is a protocol for discovering the maximum size of a packet you can send along a path between two hosts. It is fragile since it relies on the intermediary routers to send back information about this maximum size. If those informational packets are dropped along the way, the maximum packet size will be unknown and any traffic that exceeds it will fall into a PMTUD black hole. This means something like a file transfer or large content deliveries from web servers will fail or hang, but your ssh session and small web pages work just fine.

If you suspect that you might be the victim of a PMTUD black hole, the easiest way to validate this is by forcing the MTU of the failing host down to some relatively low value like 1300. Doing so will cause TCP to negotiate an MSS appropriate to that size. Retry your failing file transfer (or other network operation), and if it succeeds, you most likely have hit a PMTUD black hole. At this point, it's best to get your network administrator involved to help track down exactly where the black hole is, whether it can be fixed or not, and whether or not there is a router between the two networks that supports MSS clamping to work around the issue.