Home / server / Questions / 234311
Accepted
pufferfish
Asked: 2011-02-12 02:53:51 +0800 CST

Testing whether jumbo frames are actually working

  • 772

Is there a command to test whether jumbo frames are actually working? i.e. some sort of "ping" that reports whether or not the packet was broken up along the way.

I've an ESXi host with an Ubuntu VM which mounts a Dell MD3000i via iSCSI. I suspect jumbo frames are not enabled on the switch, and can't easily get admin access to it. I have the option to connect the disk array directly to the ESXi host, but would like some way of confirming that jumbo frames are a problem first.

ubuntu jumboframes storage-area-network iscsi

4 Answers

  1. Best Answer

    Enabling Jumbo Frames means allowing a larger Maximum Transmission Unit (MTU), usually by setting the MTU to 9000.

    To verify this has worked you can use ping in windows with the -l flag to set the packet size, and the -f flag to set Don't Fragment flag in the packet.

    ping my.test.host -f -l 8972

    If the packet gets fragmented you will see

    Packet needs to be fragmented but DF set

    in place of what you would normally see.

    For Linux, the ping command uses different flags. -s sets the packet size, and -M do sets Do Not Fragment. So the above command would be:

    ping my.test.host -M do -s 8972

    By adjusting the packet size, you can figure out what the mtu for the link is. This will represent the lowest mtu allowed by any device in the path, which could be your switch, your computer, target or anything else inbetween.

    This won't by itself tell you where the lowest MTU is - you may be able to work that out by running the test to different devices in the path, but there could always be transparent routers that limit the MTU but don't show up for traceroute.

    Note there is an overhead of 28 bytes for the ICMP headers, so the MTU is 28 bytes larger than the figure you establish through the method above. So to check for MTU of 9000, you actually need to set your ping packet size to 9000-28 = 8972.

    Update I found some resources which will specifically figure out the MTU across the path between the host and the target:

    • For Windows mturoute
    • For *nix tracepath or traceroute --mtu

    And some more discussion on finding the MTU of a path.

    • 43

  2. I'm not sure this would work but you could give it a try:

    On the computer that has the MDSM client make sure Jumbo Frames are supported and enabled, then go to the support tab in the MDSM client and select the "Gather Support Information" link, select a location on the MDSM client to download the file to, start a packet capture on the MDSM client, and click the start button to start collecting and downloading the support info (zip file). When the collection/download is done look at the capture and see how big the Ethernet frames are from the MD3000i to the MDSM client. If the switch, the MD300i, and the MDSM client are all configured for Jumbo Frames you should see that in the Ethernet frame size in the capture.

    • 1

  3. In ESXi you need to specify which interface you would to use, otherwise ping is routed via the mgmt interface, plus in -d to set DF (do not fragment):

    vmkping -I vmkX -s 8972 -d x.x.x.x

    http://kb.vmware.com/kb/1003728

    • 1

  4. You also can check it from ESXi console via SSH: turn on Security->Firewall->Remote Tech.support (SSH) and after ssh login do "vmkping -s 8000" or something like that (don't remember its options exactly)

    • -1