Hands-On Lab: Configuring Private VLANs (PVLANs)

This hands-on lab configures a full Private VLAN structure with a primary VLAN and both isolated and community secondary VLANs, demonstrating fine-grained Layer 2 isolation within a single IP subnet beyond what the simple protected-port feature from an earlier lab can achieve.

Private VLAN ConfigurationIsolated and Community VLANsPromiscuous Port

~4 min read · Updated Sep 23, 2026

Lab Objective

Configure a primary VLAN with one isolated secondary VLAN and one community secondary VLAN, assign hosts to each, configure a promiscuous port for the shared gateway, and verify the distinct communication rules each VLAN type enforces.

Lab Purpose

The protected port feature covered in an earlier lab provides simple binary isolation on a single switch. Private VLANs extend this into a genuine multi-tier isolation model spanning potentially multiple switches, distinguishing between hosts that can never talk to each other (isolated) and hosts that can talk within their own small group (community) — all while sharing a single IP subnet and default gateway.

Lab Topology

Switch1
  Primary VLAN 100 (192.168.100.0/24)
  Isolated VLAN 101
  Community VLAN 102

  Gi1/0/1 ---- HostA (isolated VLAN 101)
  Gi1/0/2 ---- HostB (isolated VLAN 101)
  Gi1/0/3 ---- HostC (community VLAN 102)
  Gi1/0/4 ---- HostD (community VLAN 102)
  Gi1/0/24 ---- Router (promiscuous port, primary VLAN)

Task 1: Create the Primary and Secondary VLANs

Create VLAN 100 as primary, VLAN 101 as isolated, and VLAN 102 as community.

Task 2: Associate the Secondary VLANs with the Primary

Link both secondary VLANs to the primary VLAN.

Task 3: Configure Host Ports

Configure Gi1/0/1 and Gi1/0/2 as host ports in the isolated VLAN, and Gi1/0/3 and Gi1/0/4 as host ports in the community VLAN.

Task 4: Configure the Promiscuous Port

Configure Gi1/0/24 as a promiscuous port mapping to both secondary VLANs.

Task 5: Verify Isolated VLAN Behavior

Confirm HostA and HostB, both in the isolated VLAN, cannot communicate with each other.

Task 6: Verify Community VLAN Behavior

Confirm HostC and HostD, both in the community VLAN, can communicate with each other.

Task 7: Verify All Hosts Reach the Promiscuous Port

Confirm every host can reach the router through the promiscuous port.

Solution and Verification

Switch1(config)# vlan 100
Switch1(config-vlan)# private-vlan primary
Switch1(config-vlan)# exit
Switch1(config)# vlan 101
Switch1(config-vlan)# private-vlan isolated
Switch1(config-vlan)# exit
Switch1(config)# vlan 102
Switch1(config-vlan)# private-vlan community

Switch1(config)# vlan 100
Switch1(config-vlan)# private-vlan association 101,102

Switch1(config)# interface gigabitethernet1/0/1
Switch1(config-if)# switchport mode private-vlan host
Switch1(config-if)# switchport private-vlan host-association 100 101
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/2
Switch1(config-if)# switchport mode private-vlan host
Switch1(config-if)# switchport private-vlan host-association 100 101

Switch1(config)# interface gigabitethernet1/0/3
Switch1(config-if)# switchport mode private-vlan host
Switch1(config-if)# switchport private-vlan host-association 100 102
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/4
Switch1(config-if)# switchport mode private-vlan host
Switch1(config-if)# switchport private-vlan host-association 100 102

Switch1(config)# interface gigabitethernet1/0/24
Switch1(config-if)# switchport mode private-vlan promiscuous
Switch1(config-if)# switchport private-vlan mapping 100 101,102

-- The promiscuous port maps to BOTH secondary
-- VLANs, since the shared gateway needs to
-- reach hosts in every secondary VLAN
-- associated with the primary

HostA> ping 192.168.100.12

Request timed out.
Success rate is 0 percent (0/5)
-- HostA (isolated) cannot reach HostB
-- (also isolated), even though both share
-- VLAN 101 -- isolated VLAN hosts can
-- NEVER talk to each other, only to
-- promiscuous ports

HostC> ping 192.168.100.14

Reply from 192.168.100.14: bytes=32 time=1ms
-- HostC and HostD, both in the community
-- VLAN 102, CAN communicate with each
-- other -- this is the defining difference
-- between community and isolated secondary
-- VLANs

HostA> ping 192.168.100.1
Reply from 192.168.100.1: bytes=32 time=1ms

HostC> ping 192.168.100.1
Reply from 192.168.100.1: bytes=32 time=1ms
-- Every host, regardless of secondary VLAN
-- type, reaches the router through the
-- promiscuous port normally

Key Takeaway

The isolated versus community distinction is the core PVLAN concept: isolated VLAN hosts can only ever talk to promiscuous ports, never to each other under any circumstances, while community VLAN hosts form their own mini broadcast domain able to talk within their group while still being isolated from hosts in other secondary VLANs — both secondary types share the same primary VLAN's IP subnet and default gateway, reached exclusively through the promiscuous port.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring iBGP and the Full-Mesh Requirement

This hands-on lab configures iBGP among three routers within a single autonomous system, demonstrating the full-mesh peering requirement by deliberately omitting one peering relationship and observing the resulting route propagation failure.

Continue

Hands-On Lab: Configuring eBGP Between Two Autonomous Systems (CCNP Depth)

This hands-on lab configures eBGP between two routers in different autonomous systems with a full verification workflow, examining the BGP table, AS-path attribute, and confirming routes are correctly installed with eBGP's default administrative distance.

Continue

Hands-On Lab: Configuring Policy-Based Routing (PBR)

This hands-on lab configures Policy-Based Routing on a router to send traffic from a specific source subnet out a different path than the normal routing table would select, overriding the destination-based forwarding decision that every previous routing lab in this series relied on.

Continue

Hands-On Lab: Configuring Route Leaking Between VRFs

This hands-on lab configures selective route leaking between two VRFs using route targets and a shared services VRF, allowing specific routes to cross the otherwise strict isolation boundary established in the previous VRF-Lite lab.

Continue

Hands-On Lab: Configuring VRF-Lite

This hands-on lab configures VRF-Lite on a router to maintain two completely separate routing tables for two different customer networks sharing the same physical router, verifying each VRF's traffic remains isolated despite using overlapping IP address space.

Continue

Hands-On Lab: Configuring Layer 3 EtherChannel

This hands-on lab configures a routed EtherChannel between two Layer 3 switches, bundling two physical links into a single logical routed interface rather than a switched trunk, and verifies OSPF forms a single neighbor relationship across the bundle rather than one per physical link.

Continue