How to test if 9000 MTU/Jumbo Frames are working | Blah, Cloud

[mylesagray]

Written on 02/25/2018 12:20:51

URL: https://blah.cloud/hardware/test-jumbo-frames-working/

[mylesagray]

Comment written by rhonin powers on 10/23/2013 10:34:01

Great article... however (and you may have already mentioned and I missed it) but isn't the "L" switch on the windows side lowercase? (or is this just to make sure it's not confused with the "i"?

thanks again.

[mylesagray]

Comment written by Myles Gray on 10/23/2013 13:45:54

Rhonin, you can use either `-l` or `-L` - I left it upper case for clarity's sake,

Myles

[mylesagray]

Comment written by BernieC on 10/31/2013 18:22:15

"(Apple macs DO support packets up to 9000 bytes, just the ICMP implementation they sport doesn't…)"

Not entirely true. The Mac has a maximum datagram size for raw packets that can be sent. By default, it's 8192 bytes. And it's controlled by one sysctl:

sudo sysctl -w net.inet.raw.maxdgram=16384

There's another that can be set as well.

sudo sysctl -w net.inet.raw.recvspace=16384

As it turns out, more than just ICMP will use these settings. OSPF routing is another that will. But, basically, to get ping -s 9000 to work, you have to increase at least net.inet.raw.maxdgram.

[mylesagray]

Comment written by Myles Gray on 10/31/2013 21:53:26

Excellent info Bernie thanks, will add that to the guide!

[mylesagray]

Comment written by SLiX on 11/27/2013 04:46:01

Interesting commands and values but there are some mistakes about protocols: ICMP doesn't use TCP (nor UDP). This is the IP header that is causing all these size troubles... Its header is also 20 bytes long without options.

[mylesagray]

Comment written by Peter Markom on 01/23/2014 17:05:53

You should also show how to verifiy on the receiving end that the jumbo frames arrive in the right size and have not been fragmented on the way - which would lead to the same ping response on the senders end.
This can be done using tcpdump and/or wireshark.

[mylesagray]

Comment written by docbill on 03/02/2014 13:01:34

Not true. I just tried on my windows 8.1 box. If I use an uppercase -L I get a usage message. Incidently, I'm not getting any of the listed results either. What I see is

$ ping -f -l 8000 172.31.252.119

Pinging 172.31.252.119 with 8000 bytes of data:
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 172.31.253.119:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)

I actually didn't do anything to enable jumbo frames. I thought I would just test first and see what is already configured for jumbo frames and what isn't. I take it this message means windows is not configure for jumbo frames.

[mylesagray]

Comment written by Myles Gray on 03/03/2014 18:05:27

I hadn't tested for Windows 8/8.1 good to note, have added to guide.

Yes "Packet needs to be fragmented but DF set." means you need to enable jumbo frames on your NIC: http://www.maximumpc.com/ar...

[mylesagray]

Comment written by DQ on 03/10/2014 02:49:59

On a Mac, you need the -D switch, not -d (case matters). "D" is "don't fragment," while "d" sets the "SO_DEBUG" option.

[mylesagray]

Comment written by matejajovanovic on 02/26/2015 09:03:17

Is there a way to check if you are setting the DF bit?

[mylesagray]

Comment written by Myles Gray on 03/05/2015 18:52:46

At what level @matejajovanovic ?

You can either set it or not set it on the ping?

[mylesagray]

Comment written by matejajovanovic on 03/13/2015 12:42:20

I´m referring to the capture, is there a way to analyze the capture and use a filter that isolates the packets where DF is set?

[mylesagray]

Comment written by Dave Jones on 09/22/2015 15:23:06

Thank you. What I was looking for.

[mylesagray]

Comment written by JeanCarlos Chavarría Hugh on 02/17/2016 05:32:27

I have problems, with linux, when I try to send the ping +1500 packet size, it is not returning neither timeout nor success. I have modifed both MTU hosts to 9000. These are my commands:

mininet> h1 ifconfig h1-eth0
h1-eth0 Link encap:Ethernet direcciónHW 06:49:45:e2:7e:18
Direc. inet:10.0.0.1 Difus.:10.255.255.255 Másc:255.0.0.0
Dirección inet6: fe80::449:45ff:fee2:7e18/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:9000 Métrica:1
Paquetes RX:295 errores:0 perdidos:27 overruns:0 frame:0
Paquetes TX:36 errores:0 perdidos:20 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:67960 (67.9 KB) TX bytes:11499 (11.4 KB)

mininet> h2 ifconfig h2-eth0
h2-eth0 Link encap:Ethernet direcciónHW 2e:96:2a:84:5f:88
Direc. inet:10.0.0.2 Difus.:10.255.255.255 Másc:255.0.0.0
Dirección inet6: fe80::2c96:2aff:fe84:5f88/64 Alcance:Enlace
ACTIVO DIFUSIÓN FUNCIONANDO MULTICAST MTU:9000 Métrica:1
Paquetes RX:304 errores:0 perdidos:28 overruns:0 frame:0
Paquetes TX:33 errores:0 perdidos:0 overruns:0 carrier:0
colisiones:0 long.colaTX:1000
Bytes RX:70325 (70.3 KB) TX bytes:6954 (6.9 KB)

mininet> h1 ping h2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.41 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.386 ms
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.386/1.399/2.412/1.013 ms

mininet> h1 ping -d -v -M "do" -s 1473 -c 3 h2
PING 10.0.0.2 (10.0.0.2) 1473(1501) bytes of data.

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2017ms

mininet> h1 ping -d -v -M "do" -s 1472 -c 3 h2
PING 10.0.0.2 (10.0.0.2) 1472(1500) bytes of data.
1480 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=2.65 ms
1480 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.419 ms
1480 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.089 ms

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.089/1.055/2.657/1.140 ms

mininet> h1 ping -M "do" -s 8972 -c 3 h2
PING 10.0.0.2 (10.0.0.2) 8972(9000) bytes of data.

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

[mylesagray]

Comment written by dsev77 on 04/27/2016 13:06:31

I would say the 28 bytes consist of 8 byte ICMP header and 20 byte IP header, NOT TCP header. ICMP uses IP directly and NOT TCP neither UDP

[mylesagray]

Comment written by Juan Camilo (@JuAnKmil0) on 05/13/2016 14:41:05

ICMP itself it's a protocol at the same level than TCP. When you ping you're sending "echo request" message. The article makes a wrong reference to TCP, instead would be focused on Ethernet Frame Size that undelayed both TCP/ICMP protocols. However, article is very useful to easily explaining how to "test jumbo frames working" without falling too depth technnical.

[mylesagray]

Comment written by Myles Gray on 05/15/2016 15:28:14

Have updated the post to reflect this.

[mylesagray]

Comment written by Myles Gray on 05/15/2016 15:28:55

Post updated.

[mylesagray]

Comment written by Ariel Sandberg-Maitland on 12/07/2016 20:51:56

Also it appears that windows 2012 r2 requires that the ICMP and Ethernet frame bytes subtracted from the jumbo ping packets(9000 - 28).
ping -f -l 8972 1.1.1.1

Thanks for the article. Very Helpful.

[mylesagray]

Comment written by EvilCreamsicle on 01/12/2017 22:15:17

This is from a long time ago but in case anybody else has the same question:
Win 10 [and probably 8] does the same encapsulation thing that Linux does.
So 'Packet needs to be fragmented but DF set.' means try it with 8972 instead of 9000 and it should work. 8973 will fail.

I just tested this.

[mylesagray]

Comment written by Rudolph on 11/18/2017 15:35:00

Same with Windows 7, 8972 max size.

[mylesagray]

Comment written by Zlatko Mitev on 02/18/2018 20:21:53

You might want to revise the part of the article where you do specify how to test Windows Jumbo Frame.

Have a look here: https://kb.vmware.com/s/art...

[oddmyth]

Helpful article! Do note that 8192 - 28 = 8164 not 8184.

[mylesagray]

@oddmyth - right, that’s why I said that the Mac ping implementation includes the 20 byte IP header already, so you only need to subtract the 8 byte ICMP header - hence 8184

[oddmyth]

Can’t say what version of MacOS you tested on for the article but I can confirm in my testing in 11.x and 12.x the payload size for successful ping has been 8164.

Sent from my iPhone

On Mar 9, 2022, at 9:06 PM, Myles Gray @.***> wrote:

 @oddmyth - right, that’s why I said that the Mac ping implementation includes the 20 byte IP header already, so you only need to subtract the 8 byte ICMP header - hence 8184

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.

[boy412]

Confirmed here as well (macOS 12.4). The payload size for a successful ping for me was 8164 bytes.

[mylesagray]

Thanks for the confirmations! I’ve updated the post to highlight this :)

On 18 Jun 2022, at 18:51, boy412 @.***> wrote:

 Confirmed here as well (macOS 12.4). The payload size for a successful ping for me was 8164 bytes.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.