Private VLANs (PVLANs) provide a powerful way to improve network segmentation and security without creating a large number of traditional VLANs. They allow traffic isolation within a single logical VLAN, which is especially useful in multi-tenant environments, DMZs, and enterprise application tiers.
 |
| PVLAN explained - Promiscuous, Community, Isolated |
Let's dive deeper.
What is a Private VLAN?
A Private VLAN (PVLAN) consists of:
- One Primary PVLAN
- One or more Secondary PVLANs
All communication rules are enforced inside the Primary PVLAN. Secondary PVLANs cannot exist on their own and are always associated with exactly one Primary PVLAN.
Primary PVLAN
The Primary Private VLAN acts as the parent VLAN. It represents the original VLAN that is subdivided into smaller logical groups called Secondary PVLANs.
Key characteristics:
- Main VLAN visible to upstream networking devices
- All Secondary PVLANs belong exclusively to this Primary PVLAN
- Traffic behavior is defined by the type of Secondary PVLAN assigned to a port
Secondary PVLANs
Secondary Private VLANs exist only within a Primary PVLAN. Each Secondary PVLAN:
- Has its own unique VLAN ID
- Defines how virtual machines connected to it can communicate
There are three types of Secondary PVLANs, each designed for a specific isolation model.
Types of Secondary PVLANs
There are three types of secondary PVLANs
- Promiscuous
- Isolated
- Community
The differences between them are discussed in next sections.
Promiscuous PVLAN
Ports assigned to a Promiscuous Secondary PVLAN can communicate with all VMs in any Secondary PVLAN within the same Primary PVLAN.
Typical use cases:
- Default gateways
- Firewalls
- Load balancers
- Shared infrastructure services
Isolated PVLAN
Ports in an Isolated Secondary PVLAN are highly restricted.
- Can communicate only with Promiscuous PVLANs
- Cannot communicate with:
- Other isolated ports
- Community PVLANs
This model is ideal for untrusted workloads or strict tenant isolation scenarios.
Community PVLAN
A Community Secondary PVLAN allows limited peer-to-peer communication.
- Can communicate with:
- VMs in the same Community PVLAN
- Promiscuous PVLANs
- Cannot communicate with:
- Other Community PVLANs
- Isolated PVLANs
This is useful when small groups of related workloads need to communicate while remaining isolated from others.
How Many VLANs Does a PVLAN Consume?
Although a PVLAN may look like a single VLAN from a logical perspective, it actually consumes multiple VLAN IDs in the Layer-2 domain.
Rule:
Total VLANs consumed = 1 Primary PVLAN + all Secondary PVLANs
Each Primary and Secondary PVLAN is a real VLAN ID that must exist end-to-end:
- On the vSphere switch (vSwitch or Distributed Switch)
- On physical switch trunk ports
- Across the entire L2 domain
Example
- Primary PVLAN: VLAN 300
- Secondary PVLANs:
- Promiscuous: VLAN 300
- Isolated: VLAN 301
- Community A: VLAN 302
- Community B: VLAN 303
Total VLANs consumed: 4
Even though upstream devices typically interact only with the Primary PVLAN, all secondary VLAN IDs must still be allowed and carried through the network.
Core PVLAN Concepts on Physical Switches
Let’s walk through exactly how this looks and works on physical switches, using our concrete VLAN numbering above. I’ll stay vendor-neutral and focus on behavior, not syntax.
All of above VLAN IDs (300, 301, 202, 303) must exist everywhere PVLANs are used (ESXi, physical switches, trunks).
PVLAN Association on the Physical Switch
The physical switch must be told that VLAN 300 is the Primary VLAN, and that the other VLANs (301, 302, 303) are Secondary VLANs associated with it.
This mapping defines the traffic policy, not routing.
Promiscuous Ports (Gateways, ESXi Uplinks)
What connects here
- Various type of Gateways
- Routers
- Firewalls
- Load balancers
- ESXi host uplinks (recommended design)
How the switch treats the port
- Port is in promiscuous mode
- Port is mapped to:
- Primary VLAN 300
- All secondary VLANs 301, 302, 303
Traffic behavior
- Can send and receive traffic to/from all secondary VLANs
- Acts as the communication hub
Mental model
- This port can see everything inside Primary VLAN 300.
Isolated Ports (VLAN 301)
What connects here
- VMs or hosts that must be fully isolated from each other
How the switch treats the port
- Port is in promiscuous mode
- Port is mapped to:
- Primary VLAN 300
- Secondary VLAN 301
Traffic behavior
- VLAN used on the wire: 301
- Can communicate only with promiscuous ports
- Cannot talk to:
- Other isolated ports
- Community A or B
Example of allowed ✅ and denied ❌ communications
- VM-A (301) → Gateway (300) ✅
- VM-A (301) → VM-B (301) ❌
- VM-A (301) → VM-C (302) ❌
Community Ports (VLAN 302 and 303)
How the switch treats the port
- Port is in promiscuous mode
- Port is mapped to:
- Primary VLAN 300
- Secondary VLAN 302 or 303 (depends into which community port should belong to)
Traffic behavior
- Community A – VLAN 302
- Members can communicate with each other
- Can communicate with promiscuous ports
- Cannot communicate with VLAN 301 or VLAN 303
- Community B – VLAN 303
- Members can communicate with each other
- Can communicate with promiscuous ports
- Cannot communicate with VLAN 301 or VLAN 302
Example of allowed ✅ and denied ❌ communications
- VM-A (302) → VM-B (302) ✅
- VM-A (302) → Gateway (300) ✅
- VM-A (302) → VM-C (303) ❌
- VM-A (302) → VM-D (301) ❌
Trunk Ports (Between Switches / to ESXi)
All VLAN IDs (300, 301, 302, 303) must be allowed on trunks.
Important:
- Trunks do not bypass PVLAN rules
- Isolation is still enforced locally by each switch
Gateway (Router / Firewall) View
From the gateway’s perspective:
- Interface is configured for VLAN 300
- Router does not need to know about VLANs 301, 302, 303
- The switch handles all VLAN translation internally
This is why PVLANs scale well in enterprise designs.
Core PVLAN Concepts on VMware Virtual Switches
In this section is a clean, practical guide to configuring Private VLANs on VMware virtual networking, specifically using a vSphere Distributed Switch (VDS / DVS). PVLANs are supported only on a Distributed Switch, not on a Standard vSwitch.
Before you can define PVLAN portgroups, PVLANs must be configured on Virtual Distributed Switch (VDS) level as depicted on screenshot below.
 |
| PVLAN configuration on DVS level |
When DVS is configured to allow PVLANs, you can create particular portgroups.
 |
| Promiscuous portgroup - VLAN 300 |
 |
| Isolated portgroup - VLAN 301 |
 |
| Community portgroup - VLAN 302 |
 |
| Community portgroup - VLAN 303 |
After this configuration and in case physical switches are configured as we described earlier, you can start placing VMs into particular DVS portgroups.
Important Design Implications
- PVLANs typically do not reduce VLAN ID consumption
- However, there is one use case when you can actually reduce number of VLANs. It is the use case with Isolated PVLAN Type in provider-like environments where two VLAN IDs are enough for device (typically tenant's routers) isolation.
- One VLAN is Promiscuous - SHARED (PROVIDER) ROUTER
- Second VLAN is Isolated - TENANT DEVICES (CAN BE TENANT ROUTERS)
- They reduce VLAN sprawl, not the number of VLANs
- All PVLAN VLAN IDs must be allowed on trunk ports
- PVLANs enforce isolation at the switch level, not via routing
Final Summary
There are three PVLAN Types allowing different communications listed in table below.
Private VLANs in VMware vSphere ESXi provide strong intra-VLAN isolation while keeping the overall network design scalable and manageable as long as you remember that each PVLAN still consumes real VLAN IDs.
No comments:
Post a Comment