Jumbo Frames and Voice

Benjamin Waldon · ‎09-09-2009

We are in the process of implementing an iSCSI SAN and the SAN vendor is recommending that the switches be configured to allow Jumbo Frames (9000 bytes).

My question is whether or not we should be concerned with that. We are running (Cisco Call Manager) voice services over these switches. My concern is that the enabled jumbo frames could create issues for the voice traffic. Granted, we have the QoS configured. And the iSCSI traffic is going to be on a seperate VLAN.

Right now the two switches (that that iSCSI traffic will run on and voice traffic do run on) are connected with a single 1gigabit link. We are planning to make other switchports available and make an etherchannel. But, my concern is that the jumbo frame is going to choke out the link and have negative affects on the voice.

I suppose one solution might be to run redundant links and use per-vlan spanning tree. This would essentially give the iscsi traffic a dedicated link unless there was hardware failure. However, I believe the max mtu size is set globally and would affect all vlans. So, jumbo frames on non-iscsi vlans would still present the same (hypothetical?) risk to the voice vlan.

Any suggestions, comments, feedback, etc would be much appreciated.

mattwilsonuk · ‎09-09-2009

From my undestanding, enabling jumbo frames on your switches just allow the switches to accept them, this doesnt mean you switch will have issues when recieving them. You will however need to enable jumbo frames on ALL layer 2 links so that the processing of the jumbo frames takes place as far away from your core as poss, This is because the endpoints which receive this data will not be able to receive the jumbo frames.

AS long as you have your priority queue set up correctly, shoudlnt be a problem.

trlayton · ‎09-15-2009

If your SAN vendor is recomending you configure the network for 9000 bytes then they are missing a piece of information and guiding you a little in accurately.

An ethernet frame Jumbo or Not is comprised of payload, header and crc. If you are running 802.1q VLAN trunking then that frame has payload, header, tag and CRC.

When someone refers to 9000 byte jumbo frames, they are typically talking about the payload. When you set the MTU on a Windows, Unix, Storage array or any endpoint. Your are being asked to define the payload. The actual frame that is transmitted from that endpoint (if it is not using 802.1q) is 9018 bytes (That would be 14 byte header, 4 byte CRC, 9000 byte payload). If it is using 802.1q then it is 14 byte header, 4 byte tag, 4 byte CRC and 9000 byte payload. That's 9022. This is why Cisco switches support more than 9000 byte MTUs. If you specify the interface as MTU 9000 then the endpoints will be forced to send ICMP type 3 code 4 messages to negotiate the payload size down to accomodate signalling.

So, rules to live by with jumbo frames.

Standardize your endpoints payload size within a VLAN, THESE are the things which TRANSMIT Jumbo Frames.

Maximize the MTU size of things which TRANSPORT Jumbo Frames. These are the router interfaces on the VLANs you have jumbo frames enabled. They are the switches at which you are connecting your jumbo frame enabled servers to.

If you are using a linecard or switch that only supports a 9018 byte MTU then you better not do any VLAN tagging or if you do, you should subtract 4 bytes from your payload to accomodate the TAG.

The math is pretty simple if you think of it this way.

Benjamin Waldon · ‎09-17-2009

This is really helpful - Thanks