1. I wouldn’t be concerned about it. vSwitches can’t be linked to each other except by a VM.

2. No. There is no STP support on a vSwitch. I presume this is because you can’t link vSwitches together, so there’s no need to worry about a bridging loop.

I’m not sure what “chaos” may result in a Cisco world; I have many customers who are doing just exactly what you describe without any issues whatsoever. You won’t be able to do link aggregation/EtherChannel unless your switch supports cross-switch EtherChannel, but otherwise it should work just fine.

Thanks for reading!

My thought was to have a Vswitch with two NICs (or more), each connected to redundant Cisco switches. The Cisco switches have an interconnect as well, creating a physical loop.

My concern is that I might create a bridging loop between the three switches, since the Vswitch does not support Spanning Tree Protocol.

From what I can find, VMWare says that STP isn’t necessary only because Vswitches don’t bridge to each other. They don’t seem to address the chaos that can ensue in a Cisco world.

1) Are my concerns substantiated?

2) If so, is there a way to enable STP on a Vswitch?

I believe that if you are going to use 802.3ad on the physical switches, you’ll be required to use “Route based on ip hash” on the vSwitches in order for connectivity to work. Keep in mind that this will only help improve the distribution of traffic across the links, not necessarily improve the throughput of any single point-to-point connection.

Good luck!

I have the luxury of time, so I can actually test a few configurations to see which works best before placing the system into production in Sept.

Looking forward to your test results - and thanks again for the response!

Good question! Your timing is impeccable; I’m just wrapping up some network configuration testing in my lab and will be publishing results within the next few days.

In any case, here we go…you won’t be able to use “Route based on IP hash” on your vSwitch because that requires a single physical switch (refer to the link in comment #29). So, for physical switch redundancy, we either have to a) go with two vSwitches, each with two uplinks; or b) use standard NIC bonding in ESX without any physical switch configuration. Option A has problems because you can’t really replicate the same port group configuration on both vSwitches; Option B has problems because depending upon the type of traffic, ESX doesn’t do a very good job of utilizing all the uplinks on the vSwitch. This leaves you in a difficult position.

However, unless you have multiple iSCSI targets, Option B will provide you the best balance of performance and redundancy, so that’s the route I’d take.

Good luck!