Mental model
Standard VLANs solve one isolation problem: separate broadcast domains, separate IP subnets. If you want 100 isolated networks, you need 100 VLANs + 100 subnets + 100 gateways. Expensive.
Private VLANs solve a different isolation problem: many hosts in the same VLAN (and the same subnet), but isolated from each other at Layer 2. They can all talk to a gateway/firewall, but they can’t talk to each other.
This sounds esoteric until you see the use cases:
- Hotel room Wi-Fi — 200 rooms × 200 guests, all in one big
10.10.0.0/22subnet. Guest A’s laptop should NOT be reachable from Guest B’s laptop (no AirDrop hijinks, no malware spread). All guests reach the internet gateway. - MDU (Multi-Dwelling Unit) broadband — apartment building. Same scenario as hotel but with permanent residents.
- Multi-tenant hosting — many customer servers in one rack/subnet, isolated from each other.
- Manufacturing IoT — many sensors in one subnet, none should talk to another sensor.
- Hospital wards — patient devices isolated for compliance.
Without PVLAN, you’d have to give every guest/tenant their own VLAN (impractical at scale) or rely on host-level firewalls (unreliable). PVLAN is the right tool.
The three port types
| Port type | Can talk to | Cannot talk to |
|---|---|---|
| Promiscuous (P) | Everyone (all isolated + all community + other promiscuous) | — |
| Isolated (I) | Only promiscuous ports | Other isolated, other community |
| Community (C) | Other ports in same community + promiscuous | Other isolated, ports in different communities |
Promiscuous is for the gateway, the firewall, the file server — anything that everyone needs to reach.
Isolated is the strictest. Used for hotel guests, untrusted tenants. An isolated port can’t reach any other isolated port, even another isolated port in the same secondary VLAN.
Community allows a defined group to talk among themselves. Used for a department or a customer that has multiple boxes that need to talk to each other but not to other customers.
Primary and secondary VLANs
PVLAN uses a layered VLAN structure:
- Primary VLAN — the visible VLAN ID. All promiscuous ports live here. Has the L3 SVI (gateway IP).
- Secondary VLANs — sub-VLANs within the primary. Each is either an isolated secondary or a community secondary.
Primary VLAN 100
10.10.0.0/24
Gateway 10.10.0.1
│
┌──────────────┼──────────────────┐
│ │ │
┌────┴──────┐ ┌────┴──────┐ ┌─────┴──────┐
│ Isolated │ │ Community │ │ Community │
│ Secondary │ │ Secondary │ │ Secondary │
│ VLAN 101 │ │ VLAN 102 │ │ VLAN 103 │
│ Guests │ │ Customer A│ │ Customer B │
└───────────┘ └───────────┘ └────────────┘
To the upstream router, this is all VLAN 100, subnet 10.10.0.0/24. The secondary VLANs are how the switch enforces isolation internally.
Configuration — Cisco IOS
! 1. Create the secondary VLANs first
SW1(config)# vlan 101
SW1(config-vlan)# private-vlan isolated
SW1(config)# vlan 102
SW1(config-vlan)# private-vlan community
SW1(config)# vlan 103
SW1(config-vlan)# private-vlan community
! 2. Create the primary VLAN and associate
SW1(config)# vlan 100
SW1(config-vlan)# private-vlan primary
SW1(config-vlan)# private-vlan association 101,102,103
! 3. SVI on primary VLAN (gateway)
SW1(config)# interface Vlan100
SW1(config-if)# ip address 10.10.0.1 255.255.255.0
SW1(config-if)# private-vlan mapping 101,102,103
! 4. Promiscuous port (e.g., uplink to firewall)
SW1(config)# interface Gi1/0/24
SW1(config-if)# switchport mode private-vlan promiscuous
SW1(config-if)# switchport private-vlan mapping 100 101,102,103
! 5. Isolated port (e.g., guest port)
SW1(config)# interface Gi1/0/1
SW1(config-if)# switchport mode private-vlan host
SW1(config-if)# switchport private-vlan host-association 100 101
! 6. Community port (e.g., Customer A)
SW1(config)# interface Gi1/0/5
SW1(config-if)# switchport mode private-vlan host
SW1(config-if)# switchport private-vlan host-association 100 102
The promiscuous port “maps” the primary VLAN to all secondaries it should reach. The host ports “associate” with one primary + one secondary pair.
How frames flow
Isolated host → another isolated host (same secondary 101)
- Host A sends a frame to Host B’s MAC.
- Switch checks: source port is isolated (sec 101), destination port is also isolated.
- Block. Frame dropped.
Even though they’re in the same IP subnet, the switch refuses to forward between two isolated ports.
Isolated host → gateway (promiscuous)
- Host A sends to gateway MAC.
- Source isolated, destination promiscuous → forward.
- Gateway can route the packet onward (to internet, to other subnets, etc.).
Community host A → community host B (same secondary 102)
- Same community → forward. They talk freely.
Community host A (sec 102) → community host C (sec 103)
- Different secondaries (different communities) → block.
What PVLAN doesn’t do
- Doesn’t replace ACLs. PVLAN isolates at Layer 2 — but if traffic reaches the gateway and the gateway routes it back into the same primary VLAN, it can land in another isolated port. Combine PVLAN with a PACL (private VLAN ACL) on the gateway interface to drop intra-primary traffic.
- Doesn’t span all switches by default. Trunks need PVLAN-aware mode. Cross-switch deployments are complicated; most deployments are single-switch or stacked-switch.
- Doesn’t work on all platforms equally. Catalyst supports it well. Some access switches don’t support PVLAN at all. Check the data sheet.
Verification
SW1# show vlan private-vlan
Primary Secondary Type Ports
------- --------- ------------- -------------------
100 101 isolated Gi1/0/1, Gi1/0/2
100 102 community Gi1/0/5, Gi1/0/6
100 103 community Gi1/0/10
100 Gi1/0/24 (promiscuous)
SW1# show interfaces Gi1/0/1 switchport
Name: Gi1/0/1
Switchport: Enabled
Administrative Mode: private-vlan host
Operational Mode: private-vlan host
Administrative private-vlan host-association: 100 (PRIMARY) 101 (ISOLATED)
Functional test: from an isolated host, ping another isolated host’s IP — should fail. Ping the gateway — should succeed.
Alternative tools — when not to use PVLAN
| Need | Tool |
|---|---|
| Per-port isolation, many hosts, one subnet | PVLAN |
| Per-port isolation, want a separate broadcast domain per host | Per-host VLAN (works at small scale) |
| Mac-based access policy | Port security, dot1x |
| Identity-based segmentation | 802.1X + dynamic VLAN (or SGT — see Cisco ISE) |
| WAN-segmented multi-tenancy | MPLS L3VPN with VRFs |
| Cloud-style fine-grained micro-segmentation | NSX / ACI / Calico / similar |
PVLAN’s sweet spot is “many endpoints, same subnet, must be isolated, on the same switch / stack.”
Common mistakes
-
Forgetting the promiscuous mapping. Promiscuous port needs the
switchport private-vlan mappingline listing the secondaries it talks to. Without it, isolated/community hosts can’t reach the gateway. -
No PACL on the gateway interface. The router/firewall sees an isolated host’s packet, routes it back into the same primary VLAN. Now isolated hosts can reach each other via the gateway. Add a PACL:
permit ip from 10.10.0.0/24 to 0.0.0.0/0; deny ip from 10.10.0.0/24 to 10.10.0.0/24. -
Trying to span PVLAN across non-aware trunks. Trunk between switches must understand PVLAN. Cisco’s
private-vlan trunkmodes are tricky; many deployments avoid spanning at all. -
Using PVLAN when you actually need separate subnets. If the customers need different DHCP scopes, different IP ranges, different routing policies — they need separate VLANs. PVLAN is for the “same subnet but isolated” case.
-
Confusing isolated with community. Isolated = “alone with the gateway.” Community = “with my group + gateway.” Choose deliberately.
-
Mixing PVLAN with PortFast. PortFast is fine, but BPDU Guard can err-disable a PVLAN host port if STP misbehaves. Test carefully.
-
Not auditing what happens if traffic loops back via L3. Layer 2 isolation can be bypassed by Layer 3 — the gateway can route between two of its own interfaces. PACL or appropriate firewall rules must catch this.
Real-world hotel example
A hotel has 200 rooms. The previous design: 200 VLANs (one per room), 200 /29 subnets — exhausting the IPv4 space and ten different VLAN trunks to configure.
New design with PVLAN:
- Primary VLAN 200 —
10.50.0.0/22, gateway10.50.0.1. - Isolated secondary VLAN 201 — every guest port.
- Promiscuous port on the gateway uplink.
Every room jack is an isolated host in VLAN 201. Guests get DHCP from the gateway, browse the internet through the gateway. Two guests in the same hotel cannot reach each other. Total config = a handful of lines, not 200 VLANs.
For staff who need to access an in-room thermostat over the network, put their devices in a community secondary that includes the thermostats.
Lab to try tonight
- One switch, one gateway router.
- Create primary VLAN 100, secondary isolated 101, community 102.
- SVI on the router/gateway:
10.10.0.1/24. Promiscuous port = uplink. - Two host ports: Host A in isolated 101, Host B in isolated 101.
- Verify: Host A ↔ Host B ping fails. Host A → gateway works. Host B → gateway works.
- Move Host B to community 102. Add Host C also to community 102. Verify Host B ↔ Host C works. But Host A ↔ Host B still fails.
- Now configure a PACL on the gateway to also block intra-subnet routing. Verify Host A can no longer reach Host B even via the gateway.
- Bonus: enable port security on each host port. Bind to the host’s MAC. Now if a guest swaps an unauthorized device, the port shuts down.
Cheat strip
| Concept | Plain English |
|---|---|
| Private VLAN | L2 isolation inside one subnet — many hosts, no inter-host traffic |
| Primary VLAN | The visible VLAN ID. Holds promiscuous ports + SVI gateway |
| Secondary VLAN — Isolated | Each port alone; talks only to promiscuous |
| Secondary VLAN — Community | Group can talk to itself + promiscuous |
| Promiscuous port | Talks to everyone. Used for gateway / shared services |
| Host port | Either isolated or community. Where the endpoint plugs in |
private-vlan association | Primary VLAN lists its secondaries |
private-vlan mapping | Promiscuous port + SVI map to which secondaries they serve |
| PACL | Apply on SVI to prevent Layer-3 leakage between isolated ports |
| Use cases | Hotels, MDU, hosting, IoT, hospitals — same subnet, must not see each other |
| Trunking | Spanning PVLAN across switches needs PVLAN-aware trunks. Often avoided |