Segmented and securing network traffic is an essential part of traffic flows in and out of the virtual environment. Traditionally VLANs have been used as a means of separating broadcast domains and securing traffic from one group/type of traffic from another. With traditional VLANs, you are limited to roughly 4096 VLANs that are usable. While many may not reach this limit, large enterprises or hosting providers typically do. Also, within a VLAN, hosts can typically communicate with one another. However, what if you do not want hosts to be able to communicate with one another within a VLAN? With Private VLANs or PVLANs you are able to subdivide the VLAN into sub-VLANs if you will that can further control your traffic, allowing much higher limits to the number of VLANs as well as further control over how hosts within each VLAN can communicate with one another. Within the context of VMware and distributed switches, we can create Private VLANs to allow this same type of more granular traffic control within the virtual infrastructure. Let’s look at how to configure VMware distributed switch private VLANs.
What are Private VLANs and Secondary VLANs?
As mentioned the Private VLAN configuration allows for higher VLAN limits as well as tighter security for hosts that are communicating within a VLAN. You may not want the hosts within a VLAN to communicate with one another, perhaps in a DMZ environment. You may not want any host to be able to communicate within a DMZ VLAN but only be able to communicate with a device upstream. Also, hotels with kiosks are another traditional use case for private VLANs in that they may want all kiosks to be able to communicate to the Internet but not with each other. By having the kiosks in a Private VLAN this can be achieved. Private VLANs contain secondary VLANs. These include the following:
- Community VLANs – Hosts in these types of secondary VLANs can communicate with other hosts within the same community VLAN but not to hosts in other community VLANs. They can also communicate with the promiscuous VLAN.
- Isolated VLANs – Hosts in these types of secondary VLANs can not communicate with one another or any other secondary VLAN. They can communicate with hosts in the promiscuous VLAN.
Configure VMware Distributed Switch Private VLANs
Adding the PVLANs to a Distributed Switch is straightforward. You can do this either in the HTML5 client as well as the flash client. To add a PVLAN, right-click on the distributed switch and select settings and then edit private VLAN.
Adding PVLANs to a VMware Distributed Switch
By clicking the “+” signs you can add the Primary VLAN ID as well as the Secondary VLANs and types.
Add the primary PVLAN and the secondary VLAN and type
If you attempt to add a primary VLAN that is already added to another vSwitch, you will see an error similar to below.
Error received when VLAN already exists on another vSwitch
In the flash web client, you will see the further details that the VLAN has already been added.
Flash client error when the VLAN exists on another vSwitch
Changing the VLAN type is accomplished with a combo box where you can change the secondary VLAN to either Isolated or Community.
Setting the secondary VLAN type
A look at the same screen in the HTML5 client.
HTML5 web client secondary VLAN configuration
Behavior of pings Community vs Isolated
To give just a quick overview of testing in a lab environment, I created two distributed port groups. One distributed port group has the promiscuous private VLAN assigned, and the other distributed port group has an isolated private VLAN port group assigned. The names are pretty self explanatory for example purposes. I setup two VMs connected to the “DPG-PVLAN-iso” port group and one VM connected to the “DPG-PVLAN-prom” port group. I setup two VMs connected to the isolated private VLAN port group to test pings between the two VMs on the same private isolated VLAN.
PVLAN distributed port groups
Below, the pings start out before both VMs were assigned to the isolated private VLAN. After sticking both VMs in the isolated PVLAN, pings start failing.
Ping behavior when community changes to isolated
Below, I placed two command windows side by side to demonstrate the behavior. The pings on the left are from a VM on the isolated PVLAN to the VM that is connected to the promiscuous PVLAN. The pings on the right are between the two VMs on the same isolated PVLAN. As we can see, the behavior is as expected since the VMs should not be able to “see” each other but still be able to send traffic outside the isolated VLAN.
Pings to promiscuous VLAN and to a host on same isolated VLAN
Thoughts
There are numerous use cases for private VLANs or PVLANs. As we mentioned earlier, the number of usable VLANs are increased since we are able to create sub-VLANs. Private VLANs are however like plain VLANs in that there is underlying configuration required in the physical network infrastructure to properly carry traffic and make ports “promiscuous” and aware of the double encapsulation that is taking place underneath. Each switch vendor is different and vendor documentation would need to be consulted for the specific hardware this is being configured with. On the VMware side of things, the steps to configure VMware Distributed Switch Private VLANs is fairly simple and only requires a few steps. It is an easy way to create a network where all hosts are isolated from one another on the same VLAN or where hosts on one VLAN cannot talk to another VLAN and can certainly bolster security. A more modern approach however, can be accomplished with a product such as VMware’s NSX network virtualization platform, where microsegmentation can be accomplished without the reconfiguration of the underlying physical network infrastructure and can be based on any number of virtual infrastructure metadata.
0 Comments