While we are on the topic of vSphere Distributed Switches why not just cover Private VLANs. Private VLANs is something I've never used in production, thus the reason I'm covering it in this series. Honestly, this lazy Sunday night is the first time I've even touched them and they are very very easy to configure technically so long as you understand the concepts first.
What is a PVLAN?
A Private VLAN is essentially a VLAN within a VLAN! Can somebody say inception!! Basically they allow us to take one VLAN and split it into three different private VLANs each containing restrictions in regards to connectivity to each other. As far as use cases, the most common I can see is in a DMZ type scenario where lots of restrictions and security is in place. The three types are promiscuous, community, and isolated and are explained below.
A Promiscuous VLAN has the same VLAN ID as your main VLAN. Meaning if you wanted to setup some Private VLANs on VLAN 200, the promiscuous vlan would have an ID of 200. VMs attached to the promiscuous VLAN can see all other VMs on other PVLANs, and all other VMs on the PVLAN can see any VMs on the promiscuous VLAN. In the DMZ scenario, Firewalls and network devices are normally placed on the promiscuous VLAN as all VMs normally need to to see them.
VMs that are a member of the Community PVLAN can see each other, as well as see VMs in the promiscuous VLAN. They cannot see any VMs in the Isolated PVLAN. Again, in the DMZ scenario a Community PVLAN could house VMs that need inter connectivity to each other, such as a web and database server.
VMs in an isolated PVLAN are just that; isolated! The only other VMs they would be able to communicate with are those in promiscuous VLAN. They cannot see any VMs that are in the community VLAN, nor can they see any other VMs that might be in the Isolated VLAN. A good spot to put a service that only needs connectivity to the firewall and nothing else.
PVLANs in vSphere
PVLANs can be implemented within vSphere only on a vSphere Distributed Switch. Before we can assign a VM to a PVLAN there is a little leg work that needs to be done on the switch itself in terms of configuring the PVLAN. To do so, right-click your dvSwitch and select 'Edit Settings'. On the Private VLAN tab (shown below) is where you initially setup your PVLAN. As you can see, I've setup my main private VLAN ID as 200, therefore my promiscuous PVLAN is also 200. Then, I have an isolated and community PVLAN configured with and ID of 201 and 202 respectively.
Now our Private VLAN is setup to be consumed. The only thing left to do is create some port groups that contain the Private VLAN. We need the port groups in order to assign VMs on the respective network. Again, right-click your dvSwitch and select 'New Port Group'. Give your port group a name, and set the VLAN type to Private VLAN. Once this happens you will see another box appear where we can select either the Promiscuous, Isolated, or Community entry of our PVLAN. Go ahead and make three port groups, each one being assigned to either 200, 201, or 202.
Now it is as simple as attaching your VMs network adapters to the desired port group. For my testing I created 4 small Linux instances; a firewall, a web server, a database server and a video streaming server. Trying to recreate a DMZ type scenario I assigned the web and database server to the community PVLAN as they needed to communicate with each other. I assigned the video streaming server to an isolated PVLAN as it has no need to communicate with either the web or db server. And I assigned the firewall to the promiscuous PVLAN, as all VMs need to be able to communicate with it in order to gain access to the outside world. After 'much a pinging' I found that everything was working as expected. So try it out for yourself. Try reassigning VMs to different port groups and watch how the ping responses stop. Like I said, these are very easy to setup technically, just understand the implications of what happens when VMs do not belong to the proper PVLAN. Good Luck!