Use the command below to test jumbo frames:
Windows:
ping {ip_address} -f -l 8972
-l 8972 value is actually equal to 9000
9000 – 20 (20 byte IP header) – 8 (ICMP header) = 8972
Remember the source like Windows is set to 1500 MTU by default so you’ll get “Packet needs to be fragmented but DF set.” responses. It’s best to run these commands with devices that are set for Jumbo Frames. The path end to end needs to have Jumbo Frames enabled.
Cisco:
ping {ip_address} size 8972 df-bit
The maximum size of a jumbo frame is 9216 bytes, but you must account for the additional headers: 9216 data + 8-bytes ICMP + 20-bytes IP = 9244 bytes. If your end system has an MTU of 9216 bytes, you should run the command “ping {ip-address} df-bit packet-size 9188” to test end-to-end jumbo frame connectivity. The packet size will be 9216 bytes when the 8-byte ICMP and 20-byte IP headers are added.
netsh interface ipv4 show interface <---- THIS GETS THE INDEX # FOR THE INTERFACE Idx Met MTU State Name --- ---------- ---------- ------------ --------------------------- 1 50 4294967295 connected Loopback Pseudo-Interface 1 4 10 1500 connected Ethernet Now we're going to issue a ping command with a "-f" parameter to tell it not to allow fragmentation and a "-l xxxx" command to tell if how large of a packet to send. This allows us to find the largest packet that we can get through without fragmentation. ping server.contoso.com -l -f 1472 <---- THIS IS 1500 MINUS 28, THERE IS ALWAYS 28 BYTES OF "OVERHEAD" Packet needs to be fragmented but DF set. <---- MTU STILL TOO LARGE 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 server.contoso.com -l -f 1400 <---- KEEP TRYING LOWER NUMBERS UNTIL SUCCESS Packet needs to be fragmented but DF set. <---- MTU STILL TOO LARGE 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 server.contoso.com -l -f 1350 <---- KEEP TRYING LOWER NUMBERS UNTIL SUCCESS Pinging X.X.X.X with 1350 bytes of data: Reply from X.X.X.X: bytes=1350 time=1ms TTL=255 <---- SUCCESS! NOW WE NEED TO TRY A MTU IN BETWEEN THE LAST FAILED Reply from X.X.X.X: bytes=1350 time=1ms TTL=255 Reply from X.X.X.X: bytes=1350 time=1ms TTL=255 ping server.contoso.com -l -f 1372 <---- KEEP NARROWING IT DOWN UNTIL SUCCESSFUL PING, IN OUR CASE 1372 Pinging X.X.X.X with 1372 bytes of data: Reply from X.X.X.X: bytes=1372 time=1ms TTL=255 Reply from X.X.X.X: bytes=1372 time=1ms TTL=255 Reply from X.X.X.X: bytes=1372 time=1ms TTL=255 ping server.contoso.com -l -f 1373 <---- AS A FINAL TEST, INCREMENT THE SIZE BY 1 AND IT SHOULD FAIL 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. Now that we know the exact size, we can set the MTU on the NIC using the index # that we grabbed earlier netsh inteface ipv4 set interface "4" mtu=1372 store=persistent
Source:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/mtu-size-matters/ba-p/1025286