The situation
RouteLearn Hosting has several customer servers on one switch. Two customers each have a pair of servers that must talk to each other. Two independent customers each have one server that must not talk directly to its neighbours. Every server needs the gateway.
An ordinary VLAN would let all of these hosts reach each other at Layer 2. A Private VLAN (PVLAN) restricts that communication while they keep sharing one IP subnet.
How a PVLAN is organised
A PVLAN is a primary VLAN associated with secondary VLANs:
| VLAN | Type | Role in the example |
|---|---|---|
| 100 | Primary | Ties the customer groups to the shared gateway path |
| 101 | Community | Customer Alpha's two servers |
| 102 | Community | Customer Beta's two servers |
| 103 | Isolated | Independent customers' servers |
These are associations, not nested VLAN tags. A primary VLAN can have one isolated secondary and any number of community secondaries.
| Port role | Direct Layer 2 communication allowed with |
|---|---|
| Promiscuous | All associated community and isolated hosts |
| Community | Hosts in the same community, and associated promiscuous ports |
| Isolated | Associated promiscuous ports only |
"Promiscuous" here is a PVLAN port role, not packet-capture mode.
The hosting network
All addresses use mask 255.255.255.0, and every server's gateway is 192.168.10.1.
| Device | Switch port | IP address | Role |
|---|---|---|---|
| Gateway R1 | Gi1/0/1 | 192.168.10.1 | Promiscuous |
| Alpha A1 | Gi1/0/2 | 192.168.10.11 | Community 101 |
| Alpha A2 | Gi1/0/3 | 192.168.10.12 | Community 101 |
| Beta B1 | Gi1/0/4 | 192.168.10.21 | Community 102 |
| Beta B2 | Gi1/0/5 | 192.168.10.22 | Community 102 |
| Independent C1 | Gi1/0/6 | 192.168.10.31 | Isolated 103 |
| Independent C2 | Gi1/0/7 | 192.168.10.32 | Isolated 103 |
R1 connects with an ordinary untagged Ethernet link to the switch's promiscuous port. It doesn't need to understand the secondary VLAN structure at all.
Follow three conversations
- 1. A1 → A2: works. A1 sees A2 as local and ARPs for its MAC. Both are in community 101, so the switch forwards it.
- 2. A1 → B1: blocked. Same /24, but different communities. The switch won't forward the ARP or the traffic to B1.
- 3. C1 → C2: blocked. Both are in isolated VLAN 103, yet isolated ports can't reach each other, for broadcasts like ARP or for unicast.
- 4. C1 → R1: works. Every host can reach its associated promiscuous port, so C1 and C2 both reach the gateway.
Why: IP addressing says the destination is local, but the switch only forwards between port roles that the table above allows. Without that Layer 2 path, even ARP can't complete.
What PVLANs do, and what still needs policy
PVLANs restrict local Layer 2 forwarding. They don't encrypt traffic or inspect applications. If the gateway offers a routed path between hosts, its own policy (ACLs, firewall rules) must enforce the restrictions you need. Internet access needs suitable routing, and where applicable firewall rules and NAT; this lab tests local forwarding only.
Configuration lab
Objective: allow communication within each community and toward the gateway; block direct communication between communities and between isolated hosts.
⚠️ These configurations are based on Cisco documentation and haven't been run in a lab here. Use a Catalyst switch and software image that supports PVLANs, start from a fresh lab configuration, and adjust interface names to your equipment.
Step 1: create the VLAN relationships
configure terminal
vtp mode transparent
vlan 101
name ALPHA
private-vlan community
exit
vlan 102
name BETA
private-vlan community
exit
vlan 103
name INDEPENDENT
private-vlan isolated
exit
vlan 100
name HOSTING_PRIMARY
private-vlan primary
private-vlan association 101-103
exitVTP transparent mode keeps the VLAN configuration local (VTP versions 1 and 2 can't carry PVLANs).
Step 2: the gateway connection
interface GigabitEthernet1/0/1
switchport
switchport mode private-vlan promiscuous
switchport private-vlan mapping 100 101-103
no shutdown
exitThe promiscuous port is mapped to all three secondary VLANs.
Step 3: every host connection
interface range GigabitEthernet1/0/2 - 3
switchport
switchport mode private-vlan host
switchport private-vlan host-association 100 101
no shutdown
exit
interface range GigabitEthernet1/0/4 - 5
switchport
switchport mode private-vlan host
switchport private-vlan host-association 100 102
no shutdown
exit
interface range GigabitEthernet1/0/6 - 7
switchport
switchport mode private-vlan host
switchport private-vlan host-association 100 103
no shutdown
exit
end
copy running-config startup-configStep 4: R1
configure terminal
interface GigabitEthernet0/0
ip address 192.168.10.1 255.255.255.0
no shutdown
exit
end
copy running-config startup-configR1 Gi0/0 connects to SW1 Gi1/0/1. Configure the servers by hand from the addressing table, and allow ICMP on them for the ping tests.
Step 5: verify the configuration
show vlan private-vlan
show interfaces GigabitEthernet1/0/1 switchport
show interfaces GigabitEthernet1/0/2 switchport
show interfaces GigabitEthernet1/0/6 switchport
show interfaces statusThe output should confirm these expected values (not captured output from a lab):
| Item | Expected |
|---|---|
| VLAN 100 | Primary |
| VLAN 101, 102 | Community, associated with 100 |
| VLAN 103 | Isolated, associated with 100 |
| Gi1/0/1 | Promiscuous; maps 100 to 101–103 |
| Gi1/0/2–3 | Host association 100/101 |
| Gi1/0/4–5 | Host association 100/102 |
| Gi1/0/6–7 | Host association 100/103 |
Step 6: prove the forwarding behaviour
| Test (both directions where it applies) | Expected |
|---|---|
Every server → 192.168.10.1 | Works |
| A1 ↔ A2 | Works |
| B1 ↔ B2 | Works |
| A1 ↔ B1 | Blocked |
| C1 ↔ C2 | Blocked |
| C1 ↔ A1 | Blocked |
A failed ping on its own doesn't prove isolation. First confirm the same endpoint can reach the gateway and that its firewall allows the test. The lab succeeds when the permitted paths work and the restricted paths stay blocked.
Troubleshooting
| Symptom | Investigate first |
|---|---|
| No host can reach the gateway | Gateway link, its IP settings, the promiscuous role and its mappings |
| One community can't reach the gateway | That VLAN's association, the host assignment, and whether the promiscuous port maps it |
| Same-community hosts can't talk | Endpoint settings, local firewalls and host associations |
| Different communities talk directly | Wrong port roles, ordinary access ports, or another forwarding path |
| Works on one switch, fails across two | PVLAN support, consistent associations on both switches, trunk configuration |
If a secondary VLAN is left out of the promiscuous port's mapping, that group can't reach the gateway in either direction; add it with switchport private-vlan mapping add. Across switches, a standard trunk must carry the primary and the secondary VLANs, with the same associations configured on each switch. Specialised PVLAN trunk modes need their own platform-specific design.
Practice with explained answers
Why can two isolated hosts share a subnet but fail to communicate directly?
Does putting a server in a community VLAN isolate it from every other server?
The first ping between two permitted hosts fails, then the next ones work. Is the configuration wrong?
- Promiscuous reaches every associated host.
- Community reaches its own community and promiscuous ports.
- Isolated reaches promiscuous ports only, even within the same isolated VLAN.
- One primary, at most one isolated, any number of communities, one shared subnet.
- PVLANs control local forwarding; routing policy still controls what the gateway allows.