Do you experience intermittent performance problems, particularly at branch offices? Do some applications “not work” and then self-resolve before you can address them? Limitations in path MTU may be the cause of your problems!

In today’s networking environment, you may encounter situations where your traffic passes through a path with an MTU that is lower than the standard 1500 bytes, for example if you are using a PPPoE DSL or an IPSec VPN. If you are aware of a limitation in the MTU along a path you should use the IP MTU command on the interface facing this path to limit the MTU. This should be done as close as possible to the traffic source so that messages are sent back immediately informing the client of the limitations while reducing the chances of them being lost of ignored.

These network settings will result in packet fragmentation. Since TCP is a stream oriented protocol which handles packet re-ordering, as well as, the retransmission of lost packets, it should not suffer packet loss directly tied to fragmentation but will suffer a performance degradation.

However, on the other hand, UDP being a message oriented protocol, it does not have a built-in reordering or retransmitting mechanism, so fragmentation should be avoided. Further, when your traffic flows through devices that you have no control over nor visibility on such as sending traffic over the internet, then this should be avoided at all cost.

Your traffic may traverse content aware firewalls which may drop a fragmented UDP packet because it was received out of order and was unable to identify the application used, indicating that this type of behaviour could be a DoS attack.

Some others devices your traffic may traverse will not attempt to identify the applications used and may simply drop all UDP fragmented packets regardless of whether they arrived in the correct order because the device has no visibility on the traffic, it takes a more radical approach than the former and assumes that traffic could be a DoS attack.

For those reasons some applications may decide to set the DF (Don’t Fragment) bit to 1 in your IP datagram which would result in the packets being dropped if it traverses a link with a lower MTU value than its packet size.

It is possible to ignore or remove the DF bit with certain network equipment, however, it is not recommended unless you control the devices the traffic will traverse as there is no guarantee the traffic will be permitted all the way through.

RFC5405 dictates some guidelines for application developers to use to prevent issues where an application sends traffic that is greater than the allowed MTU, those measures could be performing PMTUD (Path MTU Discovery) to determine the max MTU on the path or to limit the message size to the EMTU_S (Effective MTU Size) which for IPv4 would be 576 bytes.

Below is an example of what a PMTUD response would look like, this response was for a 1500 byte packet with the DF bit set where the max MTU size was 1492 if the application supports PMTUD it should then adjust the packet size to a max of 1492 bytes. Unfortunately network or host firewalls may drop these critical packets and there are limitations on how many PMTU messages can be sent by a device in a given time period.

Careful attention to MTU and appropriate configuration can save you lots of trouble, particularly with challenging applications and difficult to diagnose intermittent issues. When facing unusual network problems performing packet captures on both ends of the connection and thinking about MTU and other factors can help you diagnose and then address the issue.

Looking for support to help you proactively manage network and security issues or would like to read more about how we have help Stanley Security minimize cost, optimize security and obtain operational independence with a custom hardware and software solution with the help of our managed services.