I forget what the setting is off the top of my head.

Good luck!

Here is a show command off a blade enclosure chassis that is similar in design to the 3750′s:

DVA01-SW1#show system mtu

System MTU size is 1500 bytes
System Jumbo MTU size is 9000 bytes
System Alternate MTU size is 1500 bytes
Routing MTU size is 1500 bytes
DVA01-SW1#


You can see I am capable of 9000 byte MTU’s.

-Eric

at our workplace we have just installed a second 3750g in a stack configuration and would like to investigate and test jumbo frames in a our server environment which consists of Windows, Linux, vCenter and our SAN running Storage Server 2003.
Our 3750g’s are both running ip ip services image version 12.2 (55) SE4
We have a vlan 50 and have tried the mtu 9000 and it is not being accepted, we suspect this doesnt work as jumbo frames cannot be enabled on a per vlan basis?

any help much appreciated!

traceroute -F target pktsize

I only just found this out myself…

Cheers

Richard

I strongly advice You to use the max setting for the switch when setting the jumboframe size.. often that is 9216. that way You can be sure that jumboframes from servers and simmilar do not get blocked/rejected.. gives a huge perf.drop.
example try running 9000 size on the switch,, run jumboframes and iscsi from vmware and the jumbofremse from the servers will be ca 9007-9008size,, these will then not get trough the switch…. sometimes setting a switch to frame size 9000 actually is 9000and something, and all is well.
sometimes on another switch 9000 will be 9000 exact, and You will have pain…

Note though with multi-homed servers in a bunch of VLAN’s traffic might not go in/out the interface you are planning on. If you have the Solaris 9 host in some primary subnet, plus also in this special 1500 byte backup VLAN and you are targeting your backup server in the 9000 byte backup VLAN, the Solaris 9 host will send traffic out whichever interface has the default gateway assigned to it (i.e. the primary interface) rather than the intended backup interface, for any traffic that is not destined for a directly connected subnet. Adding some custom route into the routing table can perhaps help you fix this.

Also, I should point out to you that bonding 4x 1 gig interfaces to the backup server may not work out as intended as generally the hashing algorithms in use on either end of the bonded links will only allow a single flow to transit one of the four links (so the four interfaces do no good unless you have a bunch of different packet flows simultaneously and even then it is random which interface they hash to and not based on load).

Good luck!

-Eric

I have a backup server with an aggregated link (4x 1Gb) to a Backup VLAN on the Cisco 3750. The Windows hosts will support MTU 9000 as will the Solaris 10 kit, without wanting to make physical changes to the Solaris 9 servers I still need access to the Backup VLAN to perform backup/restore operations. Can I create another VLAN on the 3750 and allow routing between the two VLANs to achieve this? I suspect not.. so how could this be architected?

Thanks

You could create two separate networks (one jumbo frame enabled, and one not), but they would need separate IP subnets and then you may need routing between them depending on what you are trying to do.

-Eric

That is, will the router negotiate the frame size for the slower devices connected to it?

Unless you have a really compelling reason to use jumbo frames in a situation like that, I would recommend sticking to 1500 byte mtu. It is unclear to me exactly how much uplift the larger frame size provides with todays multi-core processors and TCP/IP offload engines in the network cards. I feel they are best relegated to dedicated backup networks and storage (iSCSI) networks.

-Eric