Tag Info

Hot answers tagged

31

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 8792 If the packet gets fragmented you will see Packet needs to ...


18

First, it might be best to explain what jumbo frame ethernet is. Ethernet is a layer 2 networking technology and its Protocol Data Unit (PDU) is a frame. For reference, an L3PDU (IP layer) is a packet, and an L4PDU (tcp/udp) is a segment. An ethernet frame (there are several types of ethernet but we can generalize here) consists of a header (containing, ...


10

You may find Jeff Atwood's post on Jumbo Frames informative. Highlights of the post: 20% Performance Boost For a large frame to stay intact, every device it passes through must support that frame size Switches that don't support Jumbo Frames will drop them


8

Yep. I just looked at the PDF datasheet for your NIC No mention of Jumbo Frame support there, so I suspect you're out of luck. Buy a new nic. Go for something Intel or Broadcom and you'll probably have more luck. Shouldn't set you back too much.


6

The key here is that you can control your little segment of the network and enable large MTUs but you can't control the path your packets take over the internet and certainly can't control the configuration of the routers your packets will pass through. Most internet routers aren't configured above 1500 so you aren't going to have much luck with this ...


6

What needs to happen is that the MTU setting on the ethernet network needs to be increased from 1500 to something north of 4096. These settings are typically set on the Driver settings page. For good networking you really want all devices (including all ethernet switches) on the same ethernet to have the same MTU setting. That's where you'd change it on ...


5

Don't do this unless you know exactly what you're doing. Really only do it on your dedicated iSCSI NICs and connected switch ports and SAN NICs. There's really not many reasons to have non-storage ports set for Jumbo Frames with modern equipment.


4

You can use ping.exe to check the max size of the packets and compare that to your Jumbo Frames settings. ping -l 4096 -f server Adjust the packetsize used by -l, and use -f to set the DO_ NOT_FRAGMENT flag. When you reach your maximum packetsize you'll get a "Packet needs to be fragmented but DF set". That will give you an indication if Jumbo Frames ...


4

It depends greatly on the kind of I/O you're doing. It works great for iSCSI and FCoE because those protocols rely on a data frame size larger than the standard 1500b MTU for Ethernet. For regular old file transfers, the improvement isn't always apparent. And for databasy stuff that tends to be smaller than 1500b anyway, it doesn't do a thing. It's generally ...


3

What kind & how many hard disks does your SAN have? 2Gbps is around 250MB/sec which is very decent performance if you have a pretty large array of 7200rpm SATA drives. If you need higher performance you should look into equipping your SAN with SSD disks which offer higher I/O.


3

Jumbo frames means a larger than normal MTU. Usually the MTU is set as 1500 (or 1492), at least for 802.11 networks. Each network device will have an MTU size set on it. Any frame that arrives at a device larger than its MTU will get fragmented. So you would need to make sure the MTU on all your network devices was set at or more than the MTU on the NAS ...


3

ESX/ESXi's vSwitches are just that, switches, nothing more or less, and can happily handle both jumbo and regular frames. By default ESX/ESXi itself won't use jumbo frames (for v4.0-v.4u1 anyway) without the instructions below. So I suspect that your Centos guest itself is trying to use jumbo frames, obviously you can switch them off if you're infrastructure ...


3

Unless your view of the internet is from you via a single entity who will allow you to be extremely specific about this issue with and then on to some equally controllable end point then there's a >99.9% chance you traffic will not be transited 'intact' and maintain it's JF's. The reason is that JF's are an ethernet specification and not all of the internet ...


3

You can try, but I doubt it will help much. TDS as a protocol was never designed for high troughput. If you want to move data between two SQL server instances you may consider using Service Broker instead, its network stack is much more oriented toward high troughput than the TDS one. This is why Mirroring choose the SSB network stack to communicate with the ...


3

I would go this way: 1) switches 2) storage 3) clients I've had several times in my practice that using iSCSI with 9k jumbos thru a switch with disabled jumbo could cause a slow as hell throughput. So, obviously, switches always go first, you actually don't change anything with this, you just ALLOW clients to use frames more than 1.5k but they of course ...


3

In order to test if jumbo frames are working correctly: Enable SSH into the ESXi host and login to the shell(VmWare KB) Do a ping of a storage IP using the don't-fragment option and using a packet size higher than 1500, ex: vmkping -d -s 7000 storageipaddr If you receive something like: ~ # vmkping -d -s 7000 10.10.10.10 PING 10.10.10.10 (10.10.10.10): ...


3

I'm not aware of any risks, but I'm not sure you'll see a lot of benefit, unless you know some quirks about your environment that you're not describing. My current client has a ~6500-mailbox organization, and a 3-node DAG, with the third node across a metro WAN link, I think 50 Mbit. Replication worked just fine. And that's under Ex2010 / Server 2K8 R2 - DAG ...


2

Yes, everything must support Jumbo Frames - treat it like switching betwen token ring and ethernet. The only difference is that some devices might appear to still work for a short time or intermittently - this can also be a major headache if you don't keep track of which devices you reconfigured on a large network (i.e. 2 weeks later you get a trouble ticket ...


2

I compare it to the flow of water. Upgrade the pipes before turning on the tap. In other words, enable jumbo frames on all the switches first, then the endpoints, which are the NICs and the SAN. I'm not sure in which order you should enable the endpoints. From the EqualLogic Network Performance Guidelines: To take advantage of Jumbo Frames, all ...


2

Make sure that your NICs exist in separate netblocks when doing this. If you use Linux, packets are routed via the first NIC in the system in the netblock, so, even though eth1 has an MTU of 9000, it could end up routing those packets through eth0. We set up a separate VLAN to our storage network and had to set up a separate netblock on eth1 to avoid that ...


2

It would increase your network performance, if everything on your network is configured for it and your switches can handle it. It's mostly used if you're running iSCSI. Good explanation: http://blog.allanglesit.com/Blog/tabid/66/EntryId/55/Enabling-Jumbo-Frames-on-Hyper-V-2008-R2-Virtual-Switches.aspx


2

Don't rely on Windows Update to find drivers. It's very hit and (more often than not) miss. If this is a Dell add-in card, download the drivers from Dell Otherwise you can find the driver on Broadcom's support site.


2

Why do you need jumbo frames in the first place? It is not common on desktop PCs. UPDATE: @Sirex I still think it is uncommon in home environment. He has netgear nic and switch. These are a SOHO stuff. People should not use some technology because it has a good name. They do because of real need. I run high-end blade servers and I do not feel the need for ...


2

As others have said above the answer is currently no. Also consider the MTU of your providers uplink, unless that supports Jumbo frames, then you are out of luck before you start.


2

In the Broadcom Advanced Control Suite 3, select the head of the NIC, go to the configurations tab and look for "Jumbo MTU." P.S. Here's a good manual for BACS3 at Dell.com.


2

Jumbo Frames are usually disabled by default on the NIC so you most likely will have to enable Jumbo Frames on the NIC and make sure that you configure Jumbo Frames to match the rest of your iSCSI network devices. As an aside, I've seen more than a few iSCSI implementations that experienced I/O problems that were originally attributed to Jumbo Frames (with ...


2

is there any negative on just enabling jumbo frames in practice? No, so long as when switching JF's on you immediately confirm that the server can use the appropriate NIC/s then no, no real downside at all.


1

You can certainly enable jumbo frame support, that way if you go out of your way to enable JF on your wired machines you may see a performance boost - it being enabled won't slow down standard frame traffic. Of course it won't work at all over the wifi interface as it's not supported but I see no harm switching it on, even if you don't use it.


1

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 ...


1

That should be quite doable. Server NICs on Windows can have different MTU settings for each interface. Otherwise iSCSI, the usual driver of jumbo frames, wouldn't have the uptake it has had.



Only top voted, non community-wiki answers of a minimum length are eligible