Private VLANs or PVLANs provide layer 2 isolation between
ports/devices in the same broadcast domain. There are three types of
private VLAN ports (or in vSphere, portgroups). The three types are:
Promiscuous— A promiscuous port can communicate with all devices, including the isolated and community ports within the private VLAN.
Isolated— A device in a port group set as Isolated can communicate with devices set as Promiscuous, but not with other isolated devices or community devices. It basically blocks all traffic to isolated ports except traffic from promiscuous ports. Traffic from isolated port is forwarded only to promiscuous ports.
Community— Community ports can communicate with other devices in the same community and with devices in the promiscuous VLAN. They cannot communicate with devices in other community VLANs or with Isolated ports/devices.
Private VLANs are a feature of the dvSwitch. To create a PVLAN, in the vSphere console browse to the Networking screen then select your dvSwitch. Right click, and edit settings. In the settings window, select the Private VLAN tab:
In the screen shot above, I have already created a Primary private VLAN, which is VLAN 100. To add one, click where it says ‘Enter a private VLAN ID here’ and type the VLAN id.
Once you have created your primary VLAN, you need to configure the secondary VLANs. You can see that the Primary VLAN is automatically set as promiscuous.
For my secondary VLANs I have VLAN 101 as Isolated and VLAN 102 as Community. That is enough to test out the functionality but more community VLANs may be added if required.
Now that the PVLAN is configured on the dvSwitch, we need to create portgroups for each of the VLANs we have used:
And that is it for the configuration. Virtual machines placed in those port groups will obey the rules stated at the beginning of this post. There are a few things to bear in mind when using/configuring PVLANs on dvSwitches:
Another use case could be with a virtual desktop infrastructure. Commonly, virtual desktops are all part of the same VLAN(s). But do two virtual desktops need to communicate with each other directly? Why not put the VDI desktops in an isolated VLAN?
The same concept could be applied to backup networks. It’s fairly common for VMs to be backed up as though they were physical machines, with an agent installed in the Guest OS. Often, there is a dedicated portgroup/vswitch to which a ‘backup’ vNic is added to for each virtual machine. This results in VMs being able to communicate with one another, over the backup network, when ordinarily vlan separation and firewalls may be preventing this from occurring over their ‘production’ networks. Why not prevent the VMs from communicating directly over the backup network by creating a new PVLAN for backups, with the backup servers in the promiscuous VLAN and the virtual machines in the isolated VLAN.
Promiscuous— A promiscuous port can communicate with all devices, including the isolated and community ports within the private VLAN.
Isolated— A device in a port group set as Isolated can communicate with devices set as Promiscuous, but not with other isolated devices or community devices. It basically blocks all traffic to isolated ports except traffic from promiscuous ports. Traffic from isolated port is forwarded only to promiscuous ports.
Community— Community ports can communicate with other devices in the same community and with devices in the promiscuous VLAN. They cannot communicate with devices in other community VLANs or with Isolated ports/devices.
Private VLANs are a feature of the dvSwitch. To create a PVLAN, in the vSphere console browse to the Networking screen then select your dvSwitch. Right click, and edit settings. In the settings window, select the Private VLAN tab:
In the screen shot above, I have already created a Primary private VLAN, which is VLAN 100. To add one, click where it says ‘Enter a private VLAN ID here’ and type the VLAN id.
Once you have created your primary VLAN, you need to configure the secondary VLANs. You can see that the Primary VLAN is automatically set as promiscuous.
For my secondary VLANs I have VLAN 101 as Isolated and VLAN 102 as Community. That is enough to test out the functionality but more community VLANs may be added if required.
Now that the PVLAN is configured on the dvSwitch, we need to create portgroups for each of the VLANs we have used:
And that is it for the configuration. Virtual machines placed in those port groups will obey the rules stated at the beginning of this post. There are a few things to bear in mind when using/configuring PVLANs on dvSwitches:
- License type must be Enterprise Plus
- Only available when using a distributed switch
- The VLANs must already be configured and trunked appropriately to the ESXi hosts as required
- The PVLAN configuration must also be configured on the physical networking equipment
Use Cases for PVLANs
There are a number of use cases for PVLANs, although they do not seem to be widely adopted as yet, at least when it comes to vSphere. One suitable use case could be a DMZ, where you have common devices (in the promiscuous VLAN) such as routers and firewalls, isolated devices, and community devices such as a web farm. Separating the DMZ network in this way could help improve security without the need for lots of firewall rules and subnets.Another use case could be with a virtual desktop infrastructure. Commonly, virtual desktops are all part of the same VLAN(s). But do two virtual desktops need to communicate with each other directly? Why not put the VDI desktops in an isolated VLAN?
The same concept could be applied to backup networks. It’s fairly common for VMs to be backed up as though they were physical machines, with an agent installed in the Guest OS. Often, there is a dedicated portgroup/vswitch to which a ‘backup’ vNic is added to for each virtual machine. This results in VMs being able to communicate with one another, over the backup network, when ordinarily vlan separation and firewalls may be preventing this from occurring over their ‘production’ networks. Why not prevent the VMs from communicating directly over the backup network by creating a new PVLAN for backups, with the backup servers in the promiscuous VLAN and the virtual machines in the isolated VLAN.
Comments
Post a Comment