One of my readers sent me this question:
I'm researching NFV/SDN and wonder if the software L2 switches support spanning tree.
VMware vSwitch (and distributed switch) are famous for their lack of spanning tree support and other shortcuts. They pretend they’re not really switches but multiple hosts that just happen to have more than one MAC address on their uplinks.
Open vSwitch and Hyper-V virtual switch support STP, but one has to wonder whether that’s good or bad. It’s much easier to connect an ESXi host to the network than a host using one of the other virtual switches – properly configured ESXi utilizes all uplinks with no involvement from the physical switches, whereas the virtual switches that don’t pretend to be hosts usually require LACP (potentially combined with MLAG) unless you want to lose one (or more) of the uplinks to STP blocking.
In any case, if you have to rely on STP running on your virtual switches, you’re doing something wrong (here’s a great example of a totally broken approach).
Properly implemented OVS-based solutions use a control plane (like NSX controller) that programs the OVS forwarding entries instead of STP.
Even if a virtual switch doesn’t need STP to get its job done, it’s still crucial that it recognizes BPDU frames coming from a VM and blocks that VM (because an ID10T obviously configured bridging on that VM). VMware sadly still hasn’t got the memo.
In a follow-up question, the same reader asked:
How does CPU switching handles broadcast storms?
This one is simple: by wasting CPU cycles...
Want to know more?
Literally all aspects of ESXi/vSphere networking, including the new features introduced in vSphere 6.x, are covered in the vSphere 6 Networking Deep Dive webinar.