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

All my Macs are 2009-2010 and support Jumbo Frames
I have a Smart Gigabit switch and another unmanaged gigabit switch

My server is setup with aggregate link and is using jumbo frames.

However, I do have a PS3 (wired) and a couple network printers (10/100) on the network.

Am I correct in assuming that I cannot really use jumbo frames everywhere because of the PS3 and network printers that may not support it?

Thanks in advance for the clarification.

Tony

I am not sure of any OS’s that support such an overlay. I don’t think Cisco routers even do, and most hosts have a less robust IP stack than Cisco gear…

From the switches standpoint I don’t think it cares. You are basically just telling it what the max size frame it will allow is before it treats it as an errored frame. As long as your switching path is “jumbo frame clean” up to the frame size you are using you should be good to go.

-Eric

You could just run *everything* in jumbo frame mode (assuming you could get all your devices to support it, printers might suck).

You are correct though, you would need a router for sure if you wanted IP connectivity between the two subnets. Though in many cases, if you just want a jumbo frames subnet for NFS purposes or as a backup subnet, does it really need routed connectivity to the Internet if all the hosts attached to it are dual NIC’ed?

Note that if you have mis-matched frame sizes on a subnet, TCP will still work fine since during the 3 way handshake there is an MSS (max segment size) negotiated that will default to the lower of the two devices in the conversation. UDP on the other hand will work fine till someone tries to send an over-sized frame and then it’s game over.

-Eric