Every network engineer eventually runs into a scenario where regular VLANs just aren’t granular enough. Maybe it’s a hosting environment where tenant servers sit on the same subnet but must never talk to each other. Maybe it’s a hotel or dorm network where every guest port needs to reach the gateway but nothing else. That’s exactly the gap Private VLANs were built to fill, and once you understand the port types, the configuration itself is refreshingly straightforward.
This article covers PVLAN theory, port roles, full CLI configuration, verification, and the operational pitfalls that trip people up the first time they deploy this feature.
What Problem Do Private VLANs Solve?
Normally, a VLAN is one broadcast domain — every port in it can Layer 2 communicate with every other port in it. That’s a problem when you want IP address conservation (keeping hosts on the same subnet) but still need strict isolation between certain devices. Instead of burning a separate subnet and VLAN per isolated host, PVLANs let you subdivide a single “primary” VLAN into secondary VLANs with different communication rules, all while sharing one IP subnet and one default gateway.
Typical use cases:
- Shared hosting environments where customer servers must not see each other
- Guest Wi-Fi networks where clients shouldn’t communicate laterally
- DMZ segments where servers should only talk to a firewall/router, not each other
- Compliance environments (PCI-DSS) requiring strict host isolation
PVLAN Port Types and VLAN Roles
There are three port designations in a PVLAN:
- Promiscuous (P) port — can communicate with everything in the primary VLAN and all its secondary VLANs. Typically where the router/firewall/default gateway connects.
- Isolated (I) port — can only talk to promiscuous ports. Isolated ports cannot talk to each other, even within the same isolated VLAN.
- Community (C) port — can talk to other ports in the same community VLAN, plus promiscuous ports, but not to ports in other communities or isolated ports.
And two VLAN types:
- Primary VLAN — carries traffic from the promiscuous port down to secondary VLANs
- Secondary VLAN — either an isolated VLAN (exactly one per primary) or one or more community VLANs
Topology for This Guide
We’ll configure:
- Primary VLAN: 100
- Isolated secondary VLAN: 101
- Community secondary VLAN: 102
- Promiscuous port: Gi0/1 (uplink to router/firewall)
- Isolated ports: Gi0/2, Gi0/3 (two servers that must never talk to each other)
- Community ports: Gi0/4, Gi0/5 (two servers allowed to talk to each other, but not to the isolated hosts)
This is done on a Catalyst switch (works on Catalyst 9300/9400 IOS-XE and legacy Catalyst 3560/3750 IOS with PVLAN support).
Step 1: Enable VTP Transparent Mode
PVLANs require VTP transparent mode, since VTP versions 1/2 don’t propagate PVLAN configuration (VTP version 3 does, but transparent mode is still the most common and safest choice):
Switch(config)# vtp mode transparent
Step 2: Create the VLANs
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan primary
Switch(config-vlan)# exit
Switch(config)# vlan 101
Switch(config-vlan)# private-vlan isolated
Switch(config-vlan)# exit
Switch(config)# vlan 102
Switch(config-vlan)# private-vlan community
Switch(config-vlan)# exit
Step 3: Associate Secondary VLANs to the Primary
Switch(config)# vlan 100
Switch(config-vlan)# private-vlan association 101,102
Switch(config-vlan)# exit
Step 4: Configure the Promiscuous Port
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# switchport mode private-vlan promiscuous
Switch(config-if)# switchport private-vlan mapping 100 101,102
The mapping command tells the promiscuous port which secondary VLANs are reachable through it.
Step 5: Configure Isolated Ports
Switch(config)# interface range GigabitEthernet0/2 - 3
Switch(config-if-range)# switchport mode private-vlan host
Switch(config-if-range)# switchport private-vlan host-association 100 101
Step 6: Configure Community Ports
Switch(config)# interface range GigabitEthernet0/4 - 5
Switch(config-if-range)# switchport mode private-vlan host
Switch(config-if-range)# switchport private-vlan host-association 100 102
Step 7: Verification
Check the PVLAN mapping table:
Switch# show vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
100 101 isolated Gi0/1, Gi0/2, Gi0/3
100 102 community Gi0/1, Gi0/4, Gi0/5
Check individual port state:
Switch# show interfaces GigabitEthernet0/2 switchport
Name: Gi0/2
Switchport: Enabled
Administrative Mode: private-vlan host
Operational Mode: private-vlan host
Private VLAN host-association: 100 (VLAN0100) 101 (VLAN0101)
Test connectivity behavior:
- Gi0/2 (isolated) to Gi0/3 (isolated) → should fail
- Gi0/4 (community) to Gi0/5 (community) → should succeed
- Gi0/2 (isolated) to Gi0/1 (promiscuous/gateway) → should succeed
- Gi0/4 (community) to Gi0/2 (isolated) → should fail
Extending PVLANs Across a Trunk (Multi-Switch Deployment)
If your isolated/community hosts span multiple switches, the secondary VLANs must be carried across a trunk between switches, and the trunk port must explicitly allow the primary and secondary VLANs:
Switch(config)# interface GigabitEthernet0/24
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk allowed vlan 100,101,102
On the downstream switch, repeat the isolated/community port configuration identically, since PVLAN port roles are configured per-switch, per-port.
Real-World Enterprise Scenario: Multi-Tenant Hosting Rack
Consider a colocation provider hosting fifty customer servers in a single rack, all needing internet access via one firewall but with zero customer-to-customer visibility. Instead of provisioning fifty VLANs and fifty subnets (which burns IP space and complicates routing), the provider assigns:
- One primary VLAN and subnet for the whole rack
- Every customer server as an isolated port
- The firewall/router interface as the single promiscuous port
This gives every tenant a routable IP in the same subnet while guaranteeing Layer 2 isolation identical to what a dedicated VLAN-per-tenant design would provide — but with far less operational overhead and IP address consumption.
Security Best Practices
- Always pair PVLANs with port security on isolated/community ports to prevent MAC spoofing
- Use DHCP snooping and dynamic ARP inspection (DAI) alongside PVLANs for full Layer 2 hardening
- Disable unused ports and place them in an unused/black-hole VLAN
- Document your PVLAN mapping table — it’s easy to forget which secondary VLAN belongs to which tenant six months later
- Avoid VTP versions that don’t propagate PVLAN info unless you fully understand VTPv3 domain behavior
Common Configuration Mistakes
- Forgetting to set VTP to transparent mode (PVLAN config silently fails or behaves inconsistently in VTPv1/2)
- Not associating the secondary VLANs to the primary VLAN before mapping ports
- Omitting the promiscuous port mapping, leaving hosts unable to reach the gateway
- Assuming isolated ports on different switches can talk to each other via SVI routing — they still can’t, since PVLAN restrictions are enforced at Layer 2 regardless of trunk paths
- Forgetting to allow the secondary VLANs across inter-switch trunks
Troubleshooting Checklist
show vlan private-vlan— confirm primary/secondary association and port membershipshow interfaces <port> switchport— confirm each port’s PVLAN roleshow mac address-table vlan <secondary-vlan>— confirm hosts are learned correctly- Ping tests in both directions between isolated/community/promiscuous ports
- Check trunk
allowed vlanlists for missing secondary VLANs on multi-switch topologies
Performance Notes
PVLANs are enforced entirely in switch hardware ASICs on modern Catalyst platforms, so there’s no meaningful performance penalty compared to standard VLANs. The only “cost” is added administrative complexity in tracking primary/secondary associations, which is why clear naming conventions and documentation matter more here than in flat VLAN designs.
FAQs
Can isolated ports communicate with each other through the promiscuous port? No. Promiscuous ports forward traffic to isolated/community ports, but isolated-to-isolated traffic is blocked regardless of path.
Do PVLANs work with an SVI for inter-VLAN routing? Yes, but only the primary VLAN typically has an active SVI. Secondary VLANs inherit routing through the primary via PVLAN mapping on the promiscuous side.
Can community VLANs talk to isolated VLANs? No, they’re mutually isolated by design; only the promiscuous port bridges all of them.
Is PVLAN support universal across all Cisco switches? No — check your platform’s feature support matrix, as PVLAN capability and command syntax vary between the Catalyst 2960/3560/3750/9000 series.
Summary
Private VLANs give you fine-grained Layer 2 isolation without the overhead of extra subnets — perfect for hosting environments, guest networks, and PCI-scoped segments. The key is understanding the three port roles (promiscuous, isolated, community) and configuring VTP transparent mode, VLAN associations, and port mappings correctly. Once set up, verify thoroughly with connectivity tests in every direction, since a single missed mapping can silently break gateway reachability for an entire secondary VLAN.
References
- Cisco: Private VLANs Configuration Guide
- Cisco Catalyst 9000 Series Switches Software Configuration Guide