Understanding vSphere Private VLANs For Fun and Profit
Right on the heels of my session on the Networking section (Objective 2) of the vBrownBag studies series, this post will go over Private VLANs. For those that are going “What is a vBrownBag?” please do your self a huge favor and check it out – this is a superb series run by Cody Bunch and Damian Karlson that has been literally going on for years. It is a great educational platform with a number of rockstar speakers.
I have no clue how many turtles you can fit on a rock. 
While I’m not writing this as some sort of greater VCAP-DCA study guide, I do think it ties in nicely to a number of VMTN forum questions that I’ve seen and my latest splurge of networking related posts. Also, it gives me a great excuse to do some mini-infographic work, which I really enjoy.
Note: One thing I do want to emphasis is that the Private VLAN concept is not limited to vSphere. It’s a networking technique that has been employed on switches for quite some time. However, it is available within vSphere as an added feature when using a vSphere Distributed Switch.
What Makes A VLAN “Private”
The gist is that you have a logical encapsulation of VLANs within a VLAN. Raise your hand if that made you think of the Xzibit “Yo dawg…” meme.
The infographic below details this a bit more. The blue Promiscuous VLAN is a Primary Private VLAN. It is an externally facing VLAN that is accessible to the external network, and needs to be an available VLAN that can be used by your network.
The Promiscuous VLAN acts as a gateway into the next tier of VLANs called Secondary Private VLANs. These are only reachable through the Promiscuous VLAN. As you may have already guessed, it’s quite common to put a router or multilayer switching virtual machine / appliance in the Promiscuous VLAN so that it can appropriately route traffic into the Secondary Private VLANs. It is also possible to simply have a multi homed virtual machine that uses a vNIC in a Secondary Private VLAN to reach other virtual machines.
Secondary Private VLANs
The Secondary Private VLANs are further broken up into two types: Community and Isolated.
A Community Secondary Private VLAN is one that can talk amongst itself, but can not directly contact any other Secondary Private VLANs. In the diagram above, the white bus connecting the 4 VM cubes denote that each VM can talk to each other, or to the Promiscuous VLAN.
The Isolated Secondary Private VLAN is unique – you can only have one per Private VLAN. VMs inside the Isolated VLAN can not even talk to each other; they can only communicate directly with the Promiscuous Primary VLAN.
Here is a screenshot of the Private VLAN setup on a vDS. I’ve highlighted each VLAN type with a colored box to match the infographic.
Physical Switch Compatibility Required
When you use a Private VLAN with VMs on multiple hosts, you must be aware that your physical switches must also support Private VLANs. Otherwise, the traffic may not be able to reach the other hosts, as the traffic will have to leave one host to reach another and may be discarded at the physical switching layer.
Fortunately, support for PVLANs is rather common.
Thoughts
While I don’t see PVLANs in production that often, I have been assured that folks are using them. Realistically, I can see a some use cases for them where you need to fence off applications (perhaps pre-production?) or wish to have it serve as a method of security to logically segment your virtual machines. This, of course, assumes you trust VLANs as a method of security, which is something I see debated off and on, but mostly tend to trust for my own uses.
Nice Post. Quick, question; what is the limitation of Secondary PVLANs per Primary PVLAN? In otherwords, could I have 8000 “communities” under a single PVLAN thereby surpassing the VLAN limitation of 4096?
You’re still limited on Secondary PVLANs. The VLAN ID range is 2 to 1001 and 1006 to 4094.
Thanks Chris; I was hoping to explore using PVLANs as a way to manage IP scope in a data-center with ~10K unique clients all requiring 10-50 10.x.x.x internal IPs sharing a single set of resources (GW, DNS, etc) but isolated from one another… the search continues.
Hi.
I might be wrong (and late), but you probably could explore using VXLAN, which, I think, might be the best way to solve this.
But you need VXLAN aware physical switches.
Thanks Chris. Is it necessary for the Primary VLAN to be dedicated to that role or can it be an existing VLAN in the common external network. Also, once the VLANs are defined in vSphere and the upstream switches, how can vShield Edge be configured to act as the gateway and provide DHCP to the secondary network?
I’ve not seen a requirement that the Primary VLAN be dedicated. I’ve not seen an implementation that uses both PVLANs and vShield Edge – in my mind they both fill similar roles of partitioning off network segments.
Why not just create multiple routing instances vrf and dump your VLANs into that. You can develope a services vrf (DNS, DHCP…etc) and have your firewall allow your other vrf(s) access to your vrf(s). I’ve done it its really simple and work great.
Entirely up to you, whichever works best for your environment. It may be the case that the PVLAN option is all that is available to the VMware admin / engineer, and is also a tested concept by VMware.
Hi Chris,
Wonderful post, which a lot of things clear. Although 1 doubt still remains.
Are the vLAN Ids, configured on Community Secondary Private VLAN, valid vlan Id on the physical switch they finally connect to? Meaning, they are still taken out from the 4096 vlan Ids available to the physical switch or they do not have any validity per se into the physical network and are only known by their primary promiscuous vlan Id?
All secondary VLAN IDs are only in use within the Private VLAN. They are not taken out of the pool of available VLANs on the physical switch.