UDP fragmentation. Why should you avoid it? (updated)

UDP fragmentation is avoidable when certain unusual network problems occur. Here are some tips on how to diagnose and address the issues.

Do you experience intermittent performance problems, particularly at branch offices?

Do some applications “not work” and then self-correct before you can address them?

Limitations in path MTU may be the cause.

Diagnosing UDP fragmentation

In many networking environments, you may encounter situations where your traffic passes through a path with an MTU that is lower than the standard 1500 bytes, like when you are using a PPPoE DSL or an IPSec VPN.

If there is a limitation in the MTU along a path, you should use the IP MTU command on the interface of this path to limit the MTU. You want to do this as close to the traffic source as possible to ensure messages immediately inform the client of the limitations without risking lost or ignored messages.

These network settings will result in packet fragmentation.

TCP vs. UDP

Since TCP is a stream-oriented protocol that handles packet re-ordering and the retransmission of lost packets, it should not suffer packet loss directly tied to fragmentation but will suffer performance degradation.

On the other hand, UDP is a message-oriented protocol that does not have a built-in reordering or retransmitting mechanism, so fragmentation should be avoided. Avoid UDP fragmentation at all costs when your traffic flows through devices on which you have no control or visibility (such as sending traffic over the internet).

Your traffic may traverse content-aware firewalls. This can drop a fragmented UDP packet because it was received out of order and was unable to identify the application used.

Other devices

Other 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. And because the device has no visibility of 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. The DF bit will drop the packets 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 as long as you control the devices the traffic will traverse. You should not ignore or remove the DF bit with uncontrolled devices because there is no guarantee the traffic will make it through all the way.

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 perform 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.

Example response

Below is an example of what a PMTUD response could look like. This response was for a 1500-byte packet with the DF bit set to a max MTU size of 1492. In this case, if the application supports PMTUD, it should adjust the packet size to a max of 1492 bytes. Unfortunately, network or host firewalls may drop these critical packets because devices have PMTU message limits in a given time period.

Final thoughts

Careful attention to MTU and appropriate configuration can save you lots of trouble, particularly with challenging applications and intermittent, difficult-to-diagnose 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 address the issue more efficiently. 

If you need help resolving UDP fragmentation issues, contact us or call Sales at +1-844-940-1600. For details on how to resolve other Cisco UC issues, explore our managed services.

—

Editor’s Note: This post was originally published on May 12, 2016.