Identifying IP MTU fragmentation issues

[hmc2500]

Not sure if I'm asking this question the right way. How do you know (or can you verify) if fragmentation actually becomes an issue? Let's say the WAN devices (in this case velocloud SDWAN) have the MTU set to 1280. As from what I understand Velocloud has DMPO (dynamic multipath optimization) and should discover the right MTU size. So will Windows and applications be able to discover the right MTU size and fragment without issues? how can you verify if this is really an issue or not?

[MHM Cisco World]

show ip traffic

 
this give you some hint if the Router do fragment or not.

[hmc2500]

thanks, this is helpful. what if you suspect this is happening within the ISP network and don't have access to the equipment to verify?  

[MHM Cisco World]

if fragment is happened in ISP that there issue not yours, but if you sense any slow speed (due to ISP router frag and assemble the packet) then you can reduce yours MTU. 
why you suspect that there is MTU fragment ?

[hmc2500]

We suspect it (but are not sure) because we're seeing issues with file transfers across sites over our SDWAN network.  that's why I'm trying to see if there's a way to find out conclusively. 

[Joseph W. Doherty]

BTW, I recall [?]

show IP traffic

might only show fragmentation if the host is the source of the traffic, i.e. it might not increment this stats for transient traffic being fragmented.  I also recall, Cisco routers, generally, don't have PMTUD enabled.

[Joseph W. Doherty]

Fragmentation is always an issue, it's just a question of how impactful it is to your operations.  (If you dig into all the ins and outs of fragmentation, you'll understand why you really, really [really] like to avoid it happening, especially, but not exclusively, if dealing with the older IGMP notification standard that doesn't indicate what the acceptable MTU is.)

Sending hosts, such as Windows, to "discover" there's fragmentation, need to have PMTUD (path MTU discovery) in operation (I recall [???] Windows might have it off by default).  This sets the DF bit on IP packets, and adjusts packet size to conform to a IGMP too large packet messages.

[paul driver]

Hello

---

@hmc2500 wrote:

Not sure if I'm asking this question the right way. How do you know (or can you verify) if fragmentation actually becomes an issue? 

---

Perform some extended pings with the df-bit set to test.

ping x.x.x.x df-bit size 1280

or 

Router#ping
Protocol [ip]:
Target IP address: 1.1.1.2
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Ingress ping [n]:
Source address or interface: GigabitEthernet1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0x0000ABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1200
Sweep max size [18024]: 1500
Sweep interval [1]: 10
Type escape sequence to abort.
Sending 155, [1200..1500]-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
Packet sent with the DF bit set

[hmc2500]

We did this but if I understand it correctly does not mean it's an issue necessarily because I thought windows is supposed to be able to fragment packets if needed. 

ping -f -l 1280 192.168.1.1

Pinging 192.168.1.1 with 1280 bytes of data:
Reply from 192.168.1.2: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),

ping -f -l 1238 192.168.1.1

Pinging 192.168.1.1 with 1238 bytes of data:
Reply from 192.168.1.1: bytes=1238 time=62ms TTL=251
Reply from 192.168.1.1: bytes=1238 time=64ms TTL=251
Reply from 192.168.1.1: bytes=1238 time=64ms TTL=251
Reply from 192.168.1.1: bytes=1238 time=63ms TTL=251

Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 62ms, Maximum = 64ms, Average = 63ms

[MHM Cisco World]

if DF bit is set then the Win not fragment the packet. 
Use IP tcp adjust-mss under the interface connect to SP.

[Joseph W. Doherty · Accepted solution]

". . . I thought windows is supposed to be able to fragment packets if needed."

Windows doesn't fragment.

What Windows can do, is use PMTUD (set DF bit, like your ping test), and if it receives an IGMP packet too large message (the cause of your ping test's "Packet needs to be fragmented"), it can then reduce the outgoing packet size, to stop the transit fragmentation.  This packet size reduction is not fragmentation, the newly reduced sized packet will not need to be fragmented.

I recall (?) Windows enables PMTUD by default for TCP traffic (UDP traffic often excluded from PMTUD, as often its traffic is more sensitive to delay and/or packet loss).  There are pros and cons to using PMTUD.

To begin with, with PMTUD enabled, your packets cannot be delivered until packet size is small enough that fragmentation isn't needed.  This takes some time to figure out, especially if the older version of the IGMP too large message is being used, which only informs sender the packet it sent was too large.  I.e. the sender has to try to find the max size it can transmit, by experimentation.  (Notice how Cisco's extended ping test offers a option to sweep a range of sizes.)  (NB: besides dealing with a too large packet notification taking time, it also "wastes" bandwidth, as minimally, too large packets need to be resent [after being sized smaller] and probing for correct size wastes even more bandwidth.)

If the later IGMP message format is being used, the message will contain how large the packet can be (avoiding the trial and error detection).  This also assumes host can recognize the later IGMP message info.  (NB: now a days, I would expect the newer IGMP message format to be sent and host able to understand it.)

Another issue, with PMTUD, it resets itself after some amount of time, usually 10 minutes.  (This in case the transit path has changed and a larger MTU can actually be used.)  The reset, though, forces a repeat of the failure and resized (again, not fragmentated) packets being sent, process.

BTW, I recall it's possible for fragmented packets to also need to be fragmented.

E.g. sending host <1500 MTU> R1 <1000 MTU> R2 <500 MTU> R3 <1500 MTU> receiving host

In the above example, if you knew the network was as shown, you might set the two end hosts to use a MTU of 500 or, on a Cisco router, uses IP TCP adjust-MSS.

Oh, BTW, if PMTUD is not enabled, I recall IPv4 hosts are to send all traffic, off the connected network, with a MTU no larger than 576, a sized guaranteed that should avoid fragmentation.

Lastly, there other issues with fragmentation, not touched upon, in the above.