BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
Many administrators who supervise a vSphere platform will find themselves also learning a bit of virtual networking to get the ESXi hosts running properly. Inevitably, the decision to use a vSphere Standard Switch or a vSphere Distributed Switch will come up.
In the book Networking for VMware Administrators, authors Steve Pantol and Chris Wahl explain the basics of networking to assist VMware administrators with building and fixing their own virtualized networks. One chapter in the book is devoted to the vSphere Standard Switch. In that chapter, the authors explain how to use a vSphere Standard Switch (vSS) for traffic shaping, and discuss its properties, security and hierarchy options.
SearchVMware talked with Steve Pantol about his virtual networking experiences with vSphere Distributed Switches (vDSes) and what changes may lie ahead for VMware administrators.
Is there a scenario where a vSphere Standard Switch would be preferred over a distributed switch?
Steve Pantol: I wouldn't say 'preferred,' exactly, but the big one is licensing. If you're not an enterprise plus customer, you're stuck with the standard switch. Outside of that constraint, there's a school of thought that holds that you should use standard switches on your management cluster so vCenter isn't on a distributed switch that it's managing. The thought there is if the vCenter serving as the control plane for the vDS goes down, interesting things could happen that might prevent vCenter from coming back online properly. Duncan Epping has a fairly thorough rebuttal of this concern on his blog.
Have you ever had to resolve a situation where the maximum port limit in vSphere was reached? If so, how did you manage it?
Pantol: No, I've never had the pleasure. There's a VMware KB that talks about how to override the built-in port maximum, though. I'd venture that if you're hitting the built-in limit, you're probably approaching other configuration maximums, too. [In that instance] it might be time to split your environment into multiple vCenters.
What is the most common issue you've seen with vSphere Standard Switch security?
Pantol: I don't know that I've ever run into an environment where the default security policies have been changed. The standard switch defaults to rejecting promiscuous mode and accepting MAC address changes and forged transmits. Every health check script will ding you on that. VMware's usual recommendation is to disable all three globally, and only enable those features on specific port groups that might need them. Microsoft network load balancing in unicast mode is the major use case I've seen there.
There have been a few notable data breaches in the news recently. What are some steps vSphere administrators can take to secure their system from intruders?
Pantol: The hardening guides are the best place to start. They include scripts for easy implementation of recommended practices.
Is there ever a reason to delete a vSphere Standard Switch? If yes, are there any steps an administrator should be aware of when recreating a vSS?
Pantol: When you do a migration from a vSS to a vDS, you'll be left with a lonely, empty vSS that can be put out of its misery if you're so inclined. I can't think of any specific things you should watch out for if you find yourself needed to create a new vSS later on down the line. If your management network is on the vDS, and it gets disconnected somehow and won't reconnect, you can restore the management interface to a temporary vSS. If you didn't already have a vSS created, this'll be created as vSwitch0. If you have existing vSSes, it'll be created as vSwitch(n+1).
What do you think is the next step for the vSS? What do you think could be changed or improved?
Pantol: I think the vSS/vDS distinction is similar to the C#/Web client distinction. I don't think we'll see much, if anything, new done with the vSS. New features and enhancements will go to the vDS exclusively.
What impact do you think NSX will have on vSphere network switches?
Pantol: NSX-v logical switches are built on -- and require -- the vDS, so it's not like NSX replaces the traditional virtual switching constructs. It just adds capabilities to them.