Private VLANs (PVLANs) are a Cisco Layer 2 isolation technology that subdivides a single VLAN into a primary VLAN and one or more secondary VLANs, letting you enforce port-level isolation inside a single broadcast domain and a single IP subnet. PVLANs use three secondary VLAN types (community, isolated, promiscuous) and two host-side port modes (host vs. promiscuous), which is how multi-tenant data centers, hotels, hospitals, and DMZs separate clients without exploding their VLAN database.
If you have ever worked on a guest WiFi or hotel network running on a single flat VLAN, you already know the problem. Every room, every conference space, every public area shares one broadcast domain. From a network admin's perspective, this is "simple". From a security perspective, it is a slow-moving disaster waiting for the right curious guest to start mapping the subnet from their laptop.
The fix is not "give every room its own VLAN". That would mean managing thousands of VLANs across hundreds of switches, which is operationally insane. The fix is Private VLANs, putting every guest port in an isolated secondary VLAN that shares one primary VLAN and one gateway, but that cannot reach peer ports. One configuration change per switch, applied consistently, and every guest device is isolated at Layer 2 from every other guest device while still reaching the internet through the same default gateway.
That is the elegance of PVLANs: Layer 2 isolation without VLAN proliferation. They are underused in environments where they would genuinely help (DMZs, multi-tenant networks, guest WiFi, IoT segments) because they have a reputation for being fiddly to configure. And they are, a little, until you have configured them once in a lab and the syntax clicks.
Regular VLANs separate broadcast domains. Private VLANs go one further: they enforce isolation between hosts that share the same VLAN and the same IP subnet. Reading the PVLAN configuration guide is one thing; watching the isolation matrix actually behave (or fail) is another.
EVE-NG solves half the problem by letting you build enterprise-grade switching topologies in software. CloudMyLab solves the other half by hosting those labs so you do not have to listen to your laptop fans scream through every isolation test.
CloudmyLab is EVE-NG's official and only cloud partner.
Here is how to validate Private VLAN behavior using a ready-made network topology from EVE-NG's Lab Library, hosted where it belongs: in the cloud.
Lab 1-6 from EVE-NG's Switching series walks you through the full Private VLAN model: a primary VLAN, secondary isolated VLAN, secondary community VLAN, and the three port behaviors that live within them. You will configure each, test the isolation rules, and confirm that traffic only flows where you intend.
Here is what you are actually testing:
The lab specifically forces you to test isolation by attempting communication that should be blocked. You will ping from one isolated port to another isolated port and confirm it fails. You will ping from an isolated port to the gateway and confirm it works. You will ping from one community port to another in the same community and confirm it works, then ping to a different community and confirm it fails. Each test takes ten seconds and proves something specific about the isolation behavior, which is exactly the kind of evidence you want before signing off on a security-critical design.
Before you configure anything, here is how the three secondary VLAN behaviors compare on the dimensions that decide where each one belongs in your design:
| PVLAN type | Talks to peers in same secondary? | Talks to other secondaries? | Talks to promiscuous (gateway)? | Typical use case |
|---|---|---|---|---|
| Isolated secondary | No | No | Yes | Hotel rooms, guest WiFi, IoT, DMZ servers |
| Community secondary | Yes (same community only) | No | Yes | Per-tenant app + DB pair, clinical workgroup |
| Promiscuous (primary) | Yes (everyone) | Yes (all secondaries) | N/A | Default gateway, router, firewall, shared services |
If you are designing a multi-tenant data center, a hotel network, or a DMZ, this table is the entire mental model. CloudMyLab's hosted EVE-NG gives teams a pre-built distribution/access topology to validate the isolation matrix before touching production, no hardware required.
The Lab 1-6 topology continues the distribution/access design from earlier labs but adds multiple end hosts (PCs or Linux containers) so you can actually test the isolation matrix end to end. It is still from EVE-NG's Lab Library, so you are not building it from scratch.
Core components:
Key PVLAN configuration elements:
Topology adapted from the EVE-NG Lab Library.
This topology mirrors the real production scenarios where PVLANs actually solve problems: hotel networks, multi-tenant data centers, hospital networks (patient devices isolated from each other but sharing management infrastructure), and DMZ environments where servers should not talk to each other except through controlled paths.
Take this sequentially. Configure the VLAN structure first, then ports, then trunks, then test. Building it step by step makes the syntax dramatically clearer than trying to grasp it all at once from a configuration guide. If you are using CloudMyLab's hosted EVE-NG, the topology is pre-loaded and the full lab typically runs in 60-90 minutes.
One platform note before you start: Private VLANs require a switch image that explicitly supports them. On Catalyst hardware that means most modern Layer 3 switches; on virtual gear, IOSvL2 supports the basics. PVLAN-aware VTP propagation needs VTP version 3, which matters if you plan to push the PVLAN database between switches instead of configuring each one manually.
On every switch that will participate in PVLAN, configure the primary and secondary VLANs. The order matters less than the consistency, every switch needs the same VLAN definitions and the same primary-secondary associations.
vlan 101 private-vlan isolated exit vlan 102 private-vlan community exit vlan 100 private-vlan primary private-vlan association 101,102 exit
The private-vlan association command is what ties the secondaries to their primary. Forgetting it is the most common single configuration error: the VLANs exist, but they do not function as PVLANs because they are not associated with each other.
Verify with show vlan private-vlan. You should see Primary 100 with Secondary 101 (isolated) and Secondary 102 (community) listed underneath it.
Pick the port that connects to your gateway (typically a router, firewall, or the switch's own SVI handling Layer 3). Configure it as promiscuous:
interface gi0/1 switchport mode private-vlan promiscuous switchport private-vlan mapping 100 101,102 exit
The mapping line tells the port to relay traffic between the primary VLAN and the listed secondary VLANs. Without this mapping, the promiscuous port does not know which secondaries it is mediating for, and traffic from isolated and community ports will not reach the gateway.
These are your end-host ports: guest WiFi rooms, DMZ servers, isolated IoT devices.
interface gi0/2 switchport mode private-vlan host switchport private-vlan host-association 100 101 exit
The host-association line ties this port to primary VLAN 100 and secondary VLAN 101 (isolated). Repeat for every isolated port. They will all be unable to communicate with each other while still reaching anything connected to the promiscuous port.
Same pattern, different secondary VLAN:
interface gi0/3 switchport mode private-vlan host switchport private-vlan host-association 100 102 exit
Now configure another port (gi0/4) the same way: same primary, same community VLAN 102. These two ports will communicate with each other (both in community 102) and with the promiscuous port (gateway), but not with any port in VLAN 101 (isolated) or any other community VLAN.
This is where most production deployments break. If your topology spans multiple switches (which Lab 1-6 does), the inter-switch trunks need to carry the secondary VLAN information correctly. Standard dot1q trunks do not preserve the primary-secondary relationship, you need to allow the relevant VLANs explicitly and, on some platforms, configure the trunk in dedicated PVLAN trunk mode.
interface gi0/24 switchport mode trunk switchport trunk allowed vlan 100,101,102 exit
Some IOSvL2 versions also accept the explicit switchport mode private-vlan trunk configuration, which is required when you need to carry both regular VLANs and PVLAN traffic on the same link. Test both and observe which is required for your image version, production gear varies, and knowing the difference matters when you are configuring real switches.
This is the validation that proves the configuration actually does what you think it does. Ping from each port type to each other port type and document what should and should not work:
| From | To | Expected |
|---|---|---|
| Isolated | Isolated (different ports, same secondary) | FAIL |
| Isolated | Community (any community) | FAIL |
| Isolated | Promiscuous (gateway) | SUCCEED |
| Community A | Community A (same community) | SUCCEED |
| Community A | Community B (different community) | FAIL |
| Community | Promiscuous | SUCCEED |
If any of these results do not match expectations, you have found something to debug, and that is the entire point of running the lab before production.
Snapshot the working state in EVE-NG. This becomes your golden reference for production deployments. PVLAN configurations are unforgiving, copy-paste from a known-good reference is much safer than retyping syntax during a maintenance window when you are already tired.
Running PVLAN labs locally is technically possible but practically painful. PVLAN testing requires multiple end hosts to validate the isolation matrix, plus a multi-switch topology to demonstrate PVLAN trunk behavior properly. That is four IOSvL2 instances plus several end hosts, enough to push most laptops into thermal throttling territory before you have finished the first ping test.
CloudMyLab's hosted EVE-NG removes those constraints. (See Lab 1-1 STP & RSTP on EVE-NG for the full breakdown of hosted benefits: zero local setup, multi-user sessions, repeatable snapshots.)
For PVLANs specifically, hosted environments matter because:
Snapshot-and-revert workflow. PVLAN syntax is notoriously easy to get subtly wrong. Configure a working state, snapshot, change one thing (forget the association, mismatched mapping, wrong host-association), watch what breaks, revert, try the next variation. By the end of the session you will recognize every common PVLAN failure on sight.
End hosts ready to go. The isolation matrix testing requires actual hosts to ping from and to. Building those locally adds setup overhead before you start the actual learning. Hosted environments come with this provisioned and ready.
Multi-user testing. Have one person reconfigure ports while another runs ping tests from the host side. Collaborative testing mirrors how production validation actually works in mature operations teams, where the person making the change is not always the person verifying it.
PVLANs are not for every network. If you are running 5 VLANs on a small flat office, you do not need them. But once you start designing for multi-tenancy, guest segmentation, or DMZ-style isolation, PVLANs are often the cleanest answer.
Want to validate your Private VLAN design before deploying it in a production multi-tenant or DMZ environment, where a missed private-vlan association can quietly leave guest devices reachable from each other?
We will provision Lab 1-6 from EVE-NG's Lab Library with your specific primary and secondary VLAN structure. You will see exactly how the isolation matrix behaves, test PVLAN trunks across multiple switches, and confirm that promiscuous, isolated, and community ports do what they advertise. Most importantly, you will catch configuration errors in the lab instead of during the maintenance window.
No hardware required. No local resource constraints. Just working PVLAN behavior you can verify, document, and use as a reference when you deploy the real thing.
A Private VLAN (PVLAN) is a Cisco Layer 2 isolation technology that subdivides a single VLAN into a primary VLAN and one or more secondary VLANs. Hosts share one IP subnet and one default gateway, but PVLAN rules at the switch decide which ports can reach which other ports. PVLANs are commonly used in multi-tenant data centers, hotels, hospitals, and DMZs to isolate clients without creating one VLAN per client.
Isolated ports cannot communicate with any other host port, only the promiscuous (gateway) port. Community ports communicate with other ports in the same community VLAN and with the promiscuous port, but not with other communities or isolated ports. Promiscuous ports communicate with every host in every secondary VLAN and are typically where the router, firewall, or default gateway connects.
A regular VLAN is one broadcast domain where every port can reach every other port. A Private VLAN keeps a single broadcast domain and a single IP subnet but layers port-level isolation on top, so hosts inside the same VLAN cannot necessarily reach each other. PVLANs avoid the operational pain of provisioning one VLAN and one subnet per isolated client.
Use PVLANs whenever you need Layer 2 isolation between hosts that otherwise share infrastructure: guest WiFi, hotel rooms, hospital patient devices, DMZ servers, multi-tenant data center customers, and IoT segments. They are also a strong defense-in-depth control against lateral movement, since attackers cannot reach peer hosts even if the host firewall is misconfigured.
Yes, but only if the inter-switch links are configured as PVLAN trunks. Standard dot1q trunks do not preserve the secondary VLAN information correctly, which means isolated and community ports on different switches will not behave as expected. On many Cisco platforms, you must use switchport mode private-vlan trunk on the link, or at minimum allow the primary and all secondary VLANs explicitly on a regular trunk.
The primary VLAN is the container that holds the IP subnet and is the only VLAN visible to the Layer 3 gateway. Secondary VLANs (isolated or community) live inside the primary and define the isolation behavior between hosts. One primary maps to many secondaries; a secondary belongs to exactly one primary. Routing happens on the primary; isolation happens on the secondaries.
No. PVLAN support depends on the platform and IOS image. Most modern Catalyst Layer 3 switches support PVLANs; some access-only and small-business switches do not. On virtual gear, Cisco IOSvL2 supports the core PVLAN features used in Lab 1-6. Always check the data sheet or feature navigator for the specific model and image before designing a PVLAN deployment.
PVLAN-aware VTP propagation requires VTP version 3. VTPv1 and VTPv2 do not understand the primary/secondary VLAN concept and will either ignore PVLAN configuration or strip it during propagation. If you want to push your PVLAN database between switches automatically, run VTP version 3; otherwise, configure PVLANs manually on every participating switch.