zenking wrote:
Our Win2k8 R2 VMs have the e1000 vnics, which appear to set 9014 MTU without any way to adjust. The vswitches and host nics are set to 9000, but my understanding is that th...
See more...
zenking wrote:
Our Win2k8 R2 VMs have the e1000 vnics, which appear to set 9014 MTU without any way to adjust. The vswitches and host nics are set to 9000, but my understanding is that they allow for the header overhead. The 5424 is stuck at 9000 and does not allow for the overhead. vmkping tests top out at 8972 (since the header is added), so the switch has to be the bottleneck unless I'm wrong about the vswitch supporting the header.
The 9014 is just a bit stupid way of saying 9000.. The MTU is 9000 and the 14 extra is what they think is the layer two overhead (14 bytes at the front of the frame), but they also forgot the 4 byte CRC checksum at the end. Two things however: the 8972 is the expected payload of vmkping and actually show that your network is working fine. For some details of this see: http://rickardnobel.se/troubleshoot-jumbo-frames-with-vmkping Second: it does not matter if one part of the network should really be able to use, say 9200, and some other 9000. As long as your infrastructure (vSwitches and physical switches) also support at least 9000 then it would work fine. The hosts will not blindly send frames at their max size, but actually does a simple form of negotiation in the TCP session handshake. This means that your machines will select the lowest common MTU, and the 9200 in your case will not be needed. See this for some details: http://rickardnobel.se/different-jumbo-frames-settings-on-the-same-vlan