Guidelines for network design of bladecenter

Question

I'm setting up a lab environment consisting of an IBM Bladecenter H (equipped with 4-NICs blade servers and 4 Cisco 3012) and 2 3750 as Aggregate switches. The blade servers will host VMWare and several VMs.

Each blade server is connected to the 4 3012 module. Each 3012 module is dual-homed on the aggregate switches.

So far I just set all these links as trunks, but I'm having some troubles with STP (which I left as default). I haven't found yet (!) documents providing guidelines for simple network design in such case so I have some questions.

• Link between blades and 3012

So far I've set as trunks. This seems the simplest design. I've read others suggest to split between management ports (to ESX hosts) and traffic ports (trunk) but I think allocating a management VLAN within the trunk is fine. Any drawback?

• Link between 3012 and aggregation switches

These are also set to trunk. Should I focus on specific STP configuration?

• Etherchannel

Should I set any of above links as Etherchannel? If yes between blades and 3012, should I set NIC-bonding on the ESX host?

• Aggregation switches

Given that I have a single link to outside network, and this is connected to only one aggregation switch, this acts as single point of failure. I'm wondering if in this case deploying a couple of aggregation switches is unnecessary effort that actually doesn't provide pros, isn't it?

Thanks in advance for any suggestion or advices.

Answer 1

That's how I run most of my VMware systems. The main issue with mixing traffic and management is anything that disrupts that physical interface will also kill your management access. (STP blocking, self-loop err-disable, etc.) The Best Practice(tm) is to keep management on isolated interfaces, and have multiple management interfaces.

The only place etherchannel is really advisable is between switches. Later version of ESXi can do LACP, but I find it's rarely worth the effort.

STP is a matter of finding something that Works For You(tm). That means you understand how to configure, troubleshoot, and manage it. Otherwise, you'll have no (quick) way to deal with it when it malfunctions. Using the default is sometimes good, but quickly falls apart when you have multi-vendor networks.