UDP fragmentation

[ranga2002]

Hi ,

As we know UDP is a protocol, which doesn't have a MSS filed in the UDP header unlike in TCP header, where we have MSS field. 

My questions is when it comes to fragmentation, how does UDP packets get fragmented provided that it does not have a MSS? 

If I set the interface MTU to 1472, will that avoid UDP fragmentation? (IPv4 header being 20 bytes and the UDP header being 8 bytes, the payload of a UDP packet should be no larger than 1500 - 20 - 8 = 1472 bytes)

Thanks in advance.

[Harold Ritter · Accepted solution]

Hi @ranga2002 ,

Fragmentation is done at the IP level, not at the TCP or UDP level.

https://en.wikipedia.org/wiki/IP_fragmentation

> As we know UDP is a protocol, which doesn't have a MSS filed in the UDP header unlike in TCP header, where we have MSS field.

The TCP MSS is not used by the IP fragmentation process, but it is rather negotiated between the end hosts.

> if I set the interface MTU to 1472, will that avoid UDP fragmentation? (IPv4 header being 20 bytes and the UDP header being 8 bytes,

> the payload of a UDP packet should be no larger than 1500 - 20 - 8 = 1472 bytes)

Reducing the local MTU will reduce the UDP payload. (1472 - 20 - 8 = 1444 bytes) and will not necessarily avoid fragmentation depending on the path MTU between soucre and destination hosts.

If all MTU between source and destination hosts are set to 1500, there is not reason to change the MTU locally.

Regards,

[Giuseppe Larosa]

Hello @ranga2002 ,

as already noted by dear @Harold Ritter  fragmentation happens at OSI layer 3 at IP level regardless of upper layer protocol.

The IPv4 packet header is able to handle fragmentation .fragment resulting packets and the re-assemby at the final destination.

>> If I set the interface MTU to 1472, will that avoid UDP fragmentation? (IPv4 header being 20 bytes and the UDP header being 8 bytes, the payload of a UDP packet should be no larger than 1500 - 20 - 8 = 1472 bytes)

In Cisco devices running IOS or IOS XE MTU of an interface is again an OSI layer 3 concept . UDP is in the payload of IP packets.

Reducing IP MTU you will reduce the max size of payload.

Hope to help

Giuseppe

[Joseph W. Doherty]

The other posters have already described how IP fragmentation does not depend on MSS.  I would like to add, though, TCP's MSS doesn't depend on MTU either.

Perhaps, what's a bit confusing is TCP generally uses a MSS that just "fits" in the media's maximum MTU.  However, TCP could use a MSS larger than MTU, and then MSS would be "fragmented" across multiple packets, but this isn't IP packet fragmentation.

To further clarify your question about changing MTU to avoid UDP fragmentation.  First, there is no UDP fragmentation because UDP doesn't have a logical transmission size of its own, like TCP's MSS.  UDP can generate, from the sender, IP fragmented packets, like TCP, that's generally avoided.  Second, reducing your local MTU only avoids IP fragmentation if it doesn't exceed the end-to-end minimal MTU.

BTW, the one way to avoid IPv4 fragmentation is to use the minimum media MTU standard, of 576 (when you're "know" your destination isn't local).  Otherwise, the usual option would be to set the DF bit and deal with detected fragmentation.

[Richard Burts]

I would like to suggest looking at this question from a slightly different perspective. A Cisco device (router or switch) will fragment when it receives a packet/frame that is larger than what the Cisco will use to forward the packet/frame toward the destination. There is not anything you can configure on the Cisco that will prevent fragmentation. If the device that originated the packet/frame (which might be a locally connected end station or might be a router/switch on the path between source and destination) produced something that is larger than what Cisco can forward then fragmentation will occur. The only way to prevent fragmentation on Cisco is to do something with the device that originally produced the packet/frame.

[Joseph W. Doherty]

NB: like Rick, I too am implicitly referring to IPv4.

Agreed, it's the source that controls whether fragmentation will be precluded.  (Again, either by using the 576 minimum MTU standard or by setting the DF [don't fragment] bit [although, I recall on the latter, network devices can be configured to ignore the DF bit and forward fragmented packets anyway].)

Also for additional clarification, when a L3 device forwards toward a destination it only takes into account its connected "link(s)".  It's possible a single device can have multiple connections to choose from, for forwarding the packet, and they can have different MTUs, leading to the possibility that some packets get fragmented, and some don't, all with the same destination address.  This is uncommon except in cases where one connection uses a tunnel whose overhead reduces the encapsulated packet's effective MTU.  In such cases, often setting a routing metric can determine whether packets get fragmented for not, on the L3 device.

Lastly, since L3 devices only fragment by their directly connected "link"'s MTU, it's possible you can also have cascaded fragmentation.  I.e. fragmentation of fragmented packets.

E.g.:

host A <MTU 1500> R1 <MTU 1000> R2 <MTU 700> R3 <MTU 1500> host B

host A sending a 1500 byte packet would have it fragmented both on R1 and R2.

host B sending a 1500 byte packet would have it fragmented only on R3

[Harold Ritter]

Hi Richard,

> There is not anything you can configure on the Cisco that will prevent fragmentation.

Excellent observation in the IPv4 context. As an IPv6 advocate, I would say moving to IPv6 would be one way to ensure that your network does not get in the fragmentation business. In the IPv6 realm, fragmentation always takes place on the end devices.

Regards,

[Richard Burts]

Harold

Thank you for that observation. I must admit that I typically think in terms of IPv4 and this point reminds me that I should broaden my horizons. People who are concerned about fragmentation should bear this in mind as they think about protocols to deploy. 

[S.u.l.t.a.n]

---

@Harold Ritter wrote:

Hi Richard,

> There is not anything you can configure on the Cisco that will prevent fragmentation.

Excellent observation in the IPv4 context. 

---

@Richard Burts @Harold Ritter 

Well, you can actually!

You can apply PBR on the receiving traffic, setting the DF bit On, in which case it will fail to fragment if that's what was going to be needed such as when having to egress a tunnel interface with a lower IP MTU. In this case, the router would act just as it would for PMTUD initiated from an end-host, by replying with an

ICMP: dst (x.x.x.x) frag. needed and DF set unreachable rcv from y.y.y.y mtu: z

Best,
S.u.l.t.a.n

[Richard Burts]

The original post began with references to MSS and asked about ways to avoid fragmentation. The perspective was clearly that they wanted the Cisco device to forward the traffic and where possible to avoid fragmentation. In my response I unintentionally changed the phrasing to "prevent fragmentation" instead of "avoid fragmentation". Perhaps I should have been more precise in my response and said that there is not anything you can configure on the Cisco that will prevent fragmentation without impacting the ability to forward the traffic.

This most recent response looks at my statement literally and points out that there is a way to configure the Cisco that will prevent fragmentation, but at the cost of dropping the traffic instead of forwarding the traffic. I accept the suggestion that either I should not have changed the phrasing or should have been more specific about the context of my response.

Yes there is a way to configure the Cisco that will prevent fragmentation. But I do not believe that this is the kind of solution the original post was looking for. 

[S.u.l.t.a.n]

I respect your clarification about what you meant, however, I would not agree that that was the most proper answer though, either way, because after all, forwarding traffic without fragmentation is not necessarily the only thing we might wanna think about.

I do agree that forwarding traffic without fragmentation is what we want, but if we think about the reason why, it comes down to router resources which might not be able to bear with the fragmentation which can also crash the router, which would result in traffic drop either way besides others. That means that we also might wanna think about finding a way to save the router from crashing if that's a potential issue when having to deal with fragmentation. I suggest that it is more wise to drop traffic than crashing the router and again dropping traffic either way besides others.

So yes, you want the router to forward traffic smoothly, i.e. without fragmentation; if not possible, you want it to forward traffic the harder way, i.e. fragment it, but then this is just one of the options! - if forwarding traffic the harder way, i.e. fragmenting it, is not possible, i.e. fragmentation crashes the router, then between dropping traffic and crashing the router, i.e. again dropping traffic, you wanna drop traffic and keep the router alive at least, and you can achieve that by making sure the incoming traffic has the DF bit set and the router honors it, meaning it drops such traffic when not able to forward it without fragmentation. 

So as you can see, it comes down to how you see it.. And  then, not only, this can also help in avoiding fragmentation while forwarding traffic actually.

Think of UDP traffic which doesn't understand MSS and the router cannot set the MSS for such packets to indicate the MSS to the end hosts, even when enabled on the router, and so it relies on PMTUD only. However, PMTUD can be broken for many reasons (ex. ICMP unreachables generation in the router, disabled, ICMP unreachables filtered out along the path back to the source, etc), one of them being the DF bit Not-Set (note that PMTUD function relies on it). Now, if the DF bit is for some reason being purposely cleared somewhere along the path before reaching the router, the router would never reply with an ICMP unreachable, hence the PMTUD would fail. Doing what I mentioned with PBR could help us restore the PMTUD functionality too. Note that when PMTUD succeeds, we avoid fragmentation AND forward traffic too. Not saying that this is such a scenario what you'll be necessarily facing in the real world, but just to mention. 

Best,
S.u.l.t.a.n

[ranga2002]

Thank you Harold,Giuseppe,Joseph and Richard.