Private VLANs (PVLAN) — Isolated, Community & Promiscuous Port Configuration
Standard VLANs solve one problem cleanly: isolate traffic between different network segments. But they create a secondary problem that service providers, data centre operators, and security architects run into constantly — within a single VLAN, every device can talk to every other device freely at Layer 2. In a hotel network, guest rooms should not reach each other. In a hosting provider's DMZ, Customer A's web server should never be able to ARP-flood or ARP-spoof Customer B's web server, even if both share the same IP subnet and VLAN for routing simplicity. In a university network, student lab machines in the same subnet should be isolated from each other to prevent lateral movement if one is compromised.
Private VLANs (PVLANs) solve this by creating a two-tier VLAN structure within a single primary VLAN. The primary VLAN is the outer container — it defines the IP subnet and is what the router sees. Inside the primary VLAN, secondary VLANs carve the ports into isolated groups with different communication rules. An isolated secondary VLAN allows no port-to-port communication except through a designated gateway (promiscuous port). A community secondary VLAN allows communication between members of the same community but blocks communication to other communities and isolated ports. A promiscuous port — typically the uplink to a router or firewall — can talk to everything.
All of this happens within a single IP subnet, which is the key architectural advantage: the router upstream sees one /24 and handles routing normally. The switch enforces the intra-VLAN segmentation policy transparently below the IP layer. For related Layer 2 security hardening see DHCP Snooping and Storm Control. For the standard VLAN trunk foundation that PVLANs build on see Trunk Port Configuration and Troubleshooting Layer 2 — VLAN & Trunk Issues.
1. Core Concepts — PVLAN Architecture & Port Types
PVLAN VLAN Hierarchy
PVLAN Communication Matrix
| Source Port Type | → Isolated Port | → Community Port (same) | → Community Port (different) | → Promiscuous Port |
|---|---|---|---|---|
| Isolated Port | ✗ Blocked | ✗ Blocked | ✗ Blocked | ✓ Allowed |
| Community Port (A) | ✗ Blocked | ✓ Allowed | ✗ Blocked | ✓ Allowed |
| Community Port (B) | ✗ Blocked | ✗ Blocked | ✓ Allowed | ✓ Allowed |
| Promiscuous Port | ✓ Allowed | ✓ Allowed | ✓ Allowed | ✓ Allowed |
PVLAN VLAN and Port Type Reference
| Type | IOS VLAN Command | Port Mode | Port Command | Typical Use |
|---|---|---|---|---|
| Primary VLAN | private-vlan primary |
Promiscuous | switchport mode private-vlan promiscuous |
The container VLAN. Uplink to router/firewall. One per PVLAN domain. |
| Isolated Secondary VLAN | private-vlan isolated |
Host (isolated) | switchport mode private-vlan host |
Maximum isolation. Hosts only communicate with promiscuous port. Hotel rooms, individual VMs. |
| Community Secondary VLAN | private-vlan community |
Host (community) | switchport mode private-vlan host |
Group isolation. Members of same community can communicate. Application tiers, tenant groups. |
| Primary VLAN (SVI) | N/A — VLAN type | SVI (Layer 3) | private-vlan mapping |
Layer 3 SVI on primary VLAN mapped to all secondaries for inter-VLAN routing through one IP gateway. |
VTP and PVLANs: Private VLANs require VTP to
be in transparent mode or off mode
on all switches participating in the PVLAN domain. VTP versions
1 and 2 do not propagate PVLAN information — if VTP is in
server or client mode, the switch will accept PVLAN VLAN
configuration locally but VTP may delete the secondary VLANs
when synchronising with the VTP server. Always set
vtp mode transparent before configuring PVLANs.
VTP version 3 does support PVLAN propagation but is less
commonly deployed.
2. Lab Topology — DMZ with Service Provider Segmentation
3. Step 1 — Set VTP Mode and Create PVLANs
VTP transparent mode must be set first — before any PVLAN configuration. On a Catalyst switch in VTP server or client mode, the switch may overwrite locally configured secondary VLANs with the VTP domain's VLAN database, which does not contain the PVLAN entries.
Set VTP Transparent Mode
! ── Verify current VTP mode ────────────────────────────────────── NetsTuts_SW1#show vtp status VTP Version capable : 1 to 3 VTP version running : 2 VTP Domain Name : NetsTuts VTP Pruning Mode : Disabled VTP Traps Generation : Disabled Device ID : 0c1a.2b3c.4d5e Configuration last modified by 0.0.0.0 at 0-0-00 00:00:00 Local updater ID is 0.0.0.0 on interface Vl1 (lowest numbered VLAN interface found) Feature VLAN: ----------- VTP Operating Mode : Server ← must change this Maximum VLANs supported locally : 1005 Number of existing VLANs : 8 Configuration Revision : 3 ! ── Change VTP to transparent mode ────────────────────────────── NetsTuts_SW1(config)#vtp mode transparent Setting device to VTP Transparent mode for VLANS. ! ── Verify change ──────────────────────────────────────────────── NetsTuts_SW1#show vtp status | include Operating Mode VTP Operating Mode : Transparent ← confirmed
Create the Primary VLAN
! ── Create primary VLAN 100 ────────────────────────────────────── NetsTuts_SW1(config)#vlan 100 NetsTuts_SW1(config-vlan)#name DMZ-PRIMARY NetsTuts_SW1(config-vlan)#private-vlan primary NetsTuts_SW1(config-vlan)#exit
The
private-vlan primary command designates
VLAN 100 as the primary VLAN — the outer container of the
PVLAN domain. Every host in the PVLAN domain belongs to
VLAN 100 from the router's perspective. The router
(or Layer 3 SVI) is configured on VLAN 100 and provides
the default gateway for all hosts regardless of which
secondary VLAN they are in.
Create the Isolated Secondary VLAN
! ── Create isolated secondary VLAN 101 ─────────────────────────── NetsTuts_SW1(config)#vlan 101 NetsTuts_SW1(config-vlan)#name DMZ-ISOLATED NetsTuts_SW1(config-vlan)#private-vlan isolated NetsTuts_SW1(config-vlan)#exit
An isolated secondary VLAN is the most restrictive type.
Ports in an isolated VLAN can only communicate with
promiscuous ports — they cannot communicate with any other
host port, including other ports in the same isolated VLAN.
This makes isolated VLANs ideal for environments where hosts
should never have direct Layer 2 connectivity to each other —
only to the gateway. A single primary VLAN can have only
one isolated secondary VLAN (but multiple
community VLANs).
Create the Community Secondary VLANs
! ── Create community secondary VLAN 102 (Group A — web tier) ───── NetsTuts_SW1(config)#vlan 102 NetsTuts_SW1(config-vlan)#name DMZ-COMMUNITY-A NetsTuts_SW1(config-vlan)#private-vlan community NetsTuts_SW1(config-vlan)#exit ! ── Create community secondary VLAN 103 (Group B — app tier) ───── NetsTuts_SW1(config)#vlan 103 NetsTuts_SW1(config-vlan)#name DMZ-COMMUNITY-B NetsTuts_SW1(config-vlan)#private-vlan community NetsTuts_SW1(config-vlan)#exit
Community VLANs allow intra-group communication. Ports
within VLAN 102 can freely exchange Layer 2 frames with
each other — but are blocked from reaching ports in
VLAN 103 or the isolated VLAN 101. A primary VLAN can
have multiple community secondary VLANs, each representing
a distinct group of communicating peers. Use cases:
multiple tenants in a hosting environment (each tenant
gets their own community VLAN), application tiers that
need intra-tier communication but not cross-tier (web
servers communicate amongst themselves, app servers
communicate amongst themselves, but web cannot directly
reach app without going through the promiscuous gateway).
Associate Secondary VLANs to the Primary VLAN
! ── Associate all secondary VLANs to the primary VLAN ──────────── ! ── This is done under the PRIMARY VLAN configuration ───────────── NetsTuts_SW1(config)#vlan 100 NetsTuts_SW1(config-vlan)#private-vlan association 101,102,103 NetsTuts_SW1(config-vlan)#exit
The
private-vlan association command links the
secondary VLANs to the primary VLAN. This is the binding
that tells the switch: "VLANs 101, 102, and 103 are all
part of the PVLAN domain whose primary is VLAN 100."
Without this association, the secondary VLANs exist as
standalone VLANs and the PVLAN communication rules are
not enforced. The association is always configured under
the primary VLAN — not under the secondary VLANs.
Verify VLAN Configuration
NetsTuts_SW1#show vlan private-vlan Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 100 101 isolated 100 102 community 100 103 community ! ── All three secondary VLANs associated to primary 100 ────────── ! ── No ports assigned yet — port configuration is next ─────────── ! ── Also check with show vlan brief ───────────────────────────── NetsTuts_SW1#show vlan brief VLAN Name Status Ports ---- -------------------------------- --------- ------------------------------- 1 default active ... 100 DMZ-PRIMARY active 101 DMZ-ISOLATED active 102 DMZ-COMMUNITY-A active 103 DMZ-COMMUNITY-B active
4. Step 2 — Configure the Promiscuous Port (Router Uplink)
The promiscuous port is the gateway to the outside world for all PVLAN hosts. It is connected to the router, firewall, or Layer 3 switch that provides routing for the 192.168.100.0/24 subnet. The promiscuous port must be mapped to the primary VLAN and all secondary VLANs so it can receive traffic from — and send traffic to — every host port in the PVLAN domain.
! ── Configure Gi0/1 as the promiscuous port ────────────────────── NetsTuts_SW1(config)#interface GigabitEthernet0/1 NetsTuts_SW1(config-if)#description Uplink-to-R1-Promiscuous NetsTuts_SW1(config-if)#switchport mode private-vlan promiscuous NetsTuts_SW1(config-if)#switchport private-vlan mapping 100 101,102,103 ! ── Format: mapping [primary-vlan] [secondary-vlans] ───────────── NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit
The
switchport private-vlan mapping command on
the promiscuous port specifies: "this port belongs to primary
VLAN 100, and can receive traffic tagged with secondary VLANs
101, 102, and 103." When a host in isolated VLAN 101 sends a
frame to the router, the frame enters the switch on VLAN 101
but leaves the promiscuous port tagged as VLAN 100 (the
primary). The router only ever sees VLAN 100 — it has no
knowledge of the secondary VLAN structure. This translation
from secondary to primary on egress from the promiscuous port
is a key PVLAN behaviour: the upstream router only needs one
SVI or subinterface, not one per secondary VLAN.
Verify Promiscuous Port Configuration
NetsTuts_SW1#show interfaces GigabitEthernet0/1 switchport
Name: Gi0/1
Switchport: Enabled
Administrative Mode: private-vlan promiscuous ← ✓ promiscuous mode
Operational Mode: private-vlan promiscuous
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off
Access Mode VLAN: 1 (default)
Trunking Native Mode VLAN: 1 (default)
Administrative private-vlan host-association: none
Administrative private-vlan mapping: 100 (DMZ-PRIMARY) 101 (DMZ-ISOLATED)
102 (DMZ-COMMUNITY-A) 103 (DMZ-COMMUNITY-B)
← ✓ all secondaries mapped
Operational private-vlan: 100 (DMZ-PRIMARY) 101 (DMZ-ISOLATED)
102 (DMZ-COMMUNITY-A) 103 (DMZ-COMMUNITY-B)
5. Step 3 — Configure Host Ports (Isolated and Community)
Host ports are assigned to a specific secondary VLAN and its
parent primary VLAN using the
switchport private-vlan host-association command.
All host ports use switchport mode private-vlan host
regardless of whether they are isolated or community — the
secondary VLAN type (isolated vs community) determines the
communication behaviour, not the port mode command.
Configure Isolated Host Ports (VLAN 101)
! ── Fa0/2 — Server-1 (Isolated) ───────────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/2 NetsTuts_SW1(config-if)#description Server-1-ISOLATED NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 101 ! ── Format: host-association [primary-vlan] [secondary-vlan] ───── NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit ! ── Fa0/3 — Server-2 (Isolated) ───────────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/3 NetsTuts_SW1(config-if)#description Server-2-ISOLATED NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 101 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit
Both Fa0/2 and Fa0/3 are associated with primary VLAN 100
and secondary VLAN 101 (isolated). Even though both ports
are in the same secondary VLAN (101), they cannot
communicate with each other — isolated VLAN rules
block all host-to-host traffic, including traffic between
two ports in the same isolated secondary VLAN. Server-1
cannot ping Server-2 and Server-2 cannot ping Server-1,
even though both are in 192.168.100.0/24. Both can only
reach the router at 192.168.100.1 (the promiscuous port).
Configure Community A Host Ports (VLAN 102)
! ── Fa0/4 — WebSrv-A1 (Community A) ───────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/4 NetsTuts_SW1(config-if)#description WebSrv-A1-COMMUNITY-A NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 102 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit ! ── Fa0/5 — WebSrv-A2 (Community A) ───────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/5 NetsTuts_SW1(config-if)#description WebSrv-A2-COMMUNITY-A NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 102 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit
Configure Community B Host Ports (VLAN 103)
! ── Fa0/6 — AppSrv-B1 (Community B) ───────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/6 NetsTuts_SW1(config-if)#description AppSrv-B1-COMMUNITY-B NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 103 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit ! ── Fa0/7 — AppSrv-B2 (Community B) ───────────────────────────── NetsTuts_SW1(config)#interface FastEthernet0/7 NetsTuts_SW1(config-if)#description AppSrv-B2-COMMUNITY-B NetsTuts_SW1(config-if)#switchport mode private-vlan host NetsTuts_SW1(config-if)#switchport private-vlan host-association 100 103 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit
Community ports in VLAN 102 (WebSrv-A1 and WebSrv-A2) can
exchange Layer 2 frames directly — the switch forwards
traffic between Fa0/4 and Fa0/5 without sending it to the
router. Community ports in VLAN 103 (AppSrv-B1 and AppSrv-B2)
can similarly communicate directly. Cross-community traffic
(e.g., WebSrv-A1 trying to reach AppSrv-B1) is blocked at
Layer 2 — even though both are in the same IP subnet
(192.168.100.0/24) and could theoretically ARP for each
other. The ARP request would be blocked by the PVLAN rules
before reaching the other community's ports.
Verify All Host Port Configurations
! ── Verify an isolated port ─────────────────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/2 switchport
Name: Fa0/2
Switchport: Enabled
Administrative Mode: private-vlan host ← ✓ host mode
Operational Mode: private-vlan host
Administrative private-vlan host-association: 100 (DMZ-PRIMARY)
101 (DMZ-ISOLATED) ← ✓
Operational private-vlan: 100 (DMZ-PRIMARY) 101 (DMZ-ISOLATED)
Administrative private-vlan mapping: none
Trunking VLANs Enabled: ALL
Voice VLAN: none
! ── Verify a community port ─────────────────────────────────────
NetsTuts_SW1#show interfaces FastEthernet0/4 switchport
Name: Fa0/4
Administrative Mode: private-vlan host
Administrative private-vlan host-association: 100 (DMZ-PRIMARY)
102 (DMZ-COMMUNITY-A) ← ✓
Operational private-vlan: 100 (DMZ-PRIMARY) 102 (DMZ-COMMUNITY-A)
6. Step 4 — Configure Layer 3 SVI on the Primary VLAN
If the PVLAN domain is on a Layer 3 switch (such as a Catalyst 3560, 3750, or 9300) rather than a separate router, the default gateway can be a Switched Virtual Interface (SVI) on the primary VLAN. The SVI must be mapped to all secondary VLANs so that traffic from host ports in any secondary VLAN is routed correctly. See Inter-VLAN Routing — Layer 3 Switch for SVI routing fundamentals.
Option A — SVI on L3 Switch (Catalyst 3560/3750/9300)
! ── Enable IP routing ──────────────────────────────────────────── NetsTuts_SW1(config)#ip routing ! ── Create SVI on the PRIMARY VLAN ─────────────────────────────── NetsTuts_SW1(config)#interface vlan 100 NetsTuts_SW1(config-if)#description DMZ-Gateway-PVLAN NetsTuts_SW1(config-if)#ip address 192.168.100.1 255.255.255.0 ! ── Map the secondary VLANs to this SVI ───────────────────────── ! ── This is the L3 equivalent of the promiscuous port mapping ──── NetsTuts_SW1(config-if)#private-vlan mapping 101,102,103 NetsTuts_SW1(config-if)#no shutdown NetsTuts_SW1(config-if)#exit ! ── Do NOT create SVIs for secondary VLANs 101, 102, 103 ───────── ! ── Only the primary VLAN 100 needs a routed SVI ─────────────────
The
private-vlan mapping command on an SVI tells
the Layer 3 switch: "traffic arriving from secondary VLANs
101, 102, and 103 should be routed as if it arrived on this
SVI (VLAN 100)." Without this mapping, the switch would have
no Layer 3 interface for secondary VLAN traffic and hosts
could not reach the default gateway. A single IP address
(192.168.100.1) serves as the gateway for all hosts in
the PVLAN domain regardless of their secondary VLAN. This
elegance — one IP gateway for potentially hundreds of isolated
host ports — is one of PVLAN's most operationally attractive
features in hosting and multi-tenant environments.
Option B — Router Subinterfaces (Router-on-a-Stick)
! ── On R1 — configure a single subinterface on the PRIMARY VLAN ── ! ── The router does NOT need subinterfaces for secondary VLANs ─── NetsTuts_R1(config)#interface GigabitEthernet0/1 NetsTuts_R1(config-if)#no shutdown NetsTuts_R1(config-if)#exit NetsTuts_R1(config)#interface GigabitEthernet0/1.100 NetsTuts_R1(config-subif)#description DMZ-PVLAN-Gateway NetsTuts_R1(config-subif)#encapsulation dot1Q 100 NetsTuts_R1(config-subif)#ip address 192.168.100.1 255.255.255.0 NetsTuts_R1(config-subif)#exit ! ── Verify: R1 sees only VLAN 100 — secondary VLANs are hidden ── NetsTuts_R1#show ip interface brief | include Gi0/1 GigabitEthernet0/1.100 192.168.100.1 YES manual up up ! ── No subinterfaces for 101, 102, 103 — the switch translates ─── ! ── secondary→primary on egress from promiscuous port ────────────
7. PVLAN Across Multiple Switches — Trunk Configuration
When PVLAN hosts span multiple switches connected by trunk links, both the primary and secondary VLANs must be allowed on the trunk. The trunk itself is a regular 802.1Q trunk — the secondary VLAN tags are preserved across the trunk link. Both switches must have the same PVLAN configuration (primary/secondary associations).
! ── On both switches — configure the trunk ─────────────────────── NetsTuts_SW1(config)#interface GigabitEthernet0/24 NetsTuts_SW1(config-if)#description Trunk-to-SW2 NetsTuts_SW1(config-if)#switchport trunk encapsulation dot1q NetsTuts_SW1(config-if)#switchport mode trunk NetsTuts_SW1(config-if)#switchport trunk allowed vlan 100,101,102,103 NetsTuts_SW1(config-if)#exit ! ── On SW2 — replicate PVLAN VLAN config and trunk ─────────────── NetsTuts_SW2(config)#vtp mode transparent NetsTuts_SW2(config)#vlan 100 NetsTuts_SW2(config-vlan)#private-vlan primary NetsTuts_SW2(config-vlan)#private-vlan association 101,102,103 NetsTuts_SW2(config-vlan)#exit NetsTuts_SW2(config)#vlan 101 NetsTuts_SW2(config-vlan)#private-vlan isolated NetsTuts_SW2(config-vlan)#exit NetsTuts_SW2(config)#vlan 102 NetsTuts_SW2(config-vlan)#private-vlan community NetsTuts_SW2(config-vlan)#exit NetsTuts_SW2(config)#vlan 103 NetsTuts_SW2(config-vlan)#private-vlan community NetsTuts_SW2(config-vlan)#exit NetsTuts_SW2(config)#interface GigabitEthernet0/24 NetsTuts_SW2(config-if)#switchport trunk encapsulation dot1q NetsTuts_SW2(config-if)#switchport mode trunk NetsTuts_SW2(config-if)#switchport trunk allowed vlan 100,101,102,103 NetsTuts_SW2(config-if)#exit ! ── Host ports on SW2 — same configuration as SW1 ──────────────── NetsTuts_SW2(config)#interface FastEthernet0/10 NetsTuts_SW2(config-if)#switchport mode private-vlan host NetsTuts_SW2(config-if)#switchport private-vlan host-association 100 102 NetsTuts_SW2(config-if)#exit
A key point for multi-switch PVLAN: the trunk carries
secondary VLAN tags natively — a frame from a community
VLAN 102 host on SW2 travels across the trunk tagged as
VLAN 102, arrives on SW1 still tagged as VLAN 102, and
SW1 applies the PVLAN forwarding rules before sending it
to the destination. This means the PVLAN configuration
must be identical on all switches in the domain — both
the VLAN type declarations and the primary-to-secondary
associations. If SW2 is missing the PVLAN association or
has a VLAN typed differently, inter-switch PVLAN traffic
will behave unpredictably.
8. Step 5 — Full Verification & Traffic Testing
show vlan private-vlan — Master PVLAN Status
NetsTuts_SW1#show vlan private-vlan Primary Secondary Type Ports ------- --------- ----------------- ------------------------------------------ 100 101 isolated Fa0/2, Fa0/3 100 102 community Fa0/4, Fa0/5 100 103 community Fa0/6, Fa0/7 ! ── This is the key verification command ───────────────────────── ! ── Shows primary VLAN, secondary VLAN type, and member ports ──── ! ── All ports should appear under their correct secondary VLAN ───
show vlan private-vlan type — VLAN Types
NetsTuts_SW1#show vlan private-vlan type Vlan Type ---- ----------------- 100 primary 101 isolated 102 community 103 community
show interfaces switchport — Port-Level Verification
! ── Verify promiscuous port ────────────────────────────────────── NetsTuts_SW1#show interfaces GigabitEthernet0/1 switchport Administrative Mode: private-vlan promiscuous ← ✓ Administrative private-vlan mapping: 100 (DMZ-PRIMARY) 101 (DMZ-ISOLATED) 102 (DMZ-COMMUNITY-A) 103 (DMZ-COMMUNITY-B) ← ✓ all mapped ! ── Verify isolated host port ──────────────────────────────────── NetsTuts_SW1#show interfaces FastEthernet0/2 switchport Administrative Mode: private-vlan host ← ✓ Administrative private-vlan host-association: 100 (DMZ-PRIMARY) 101 (DMZ-ISOLATED) ← ✓ ! ── Verify community host port ─────────────────────────────────── NetsTuts_SW1#show interfaces FastEthernet0/4 switchport Administrative Mode: private-vlan host ← ✓ Administrative private-vlan host-association: 100 (DMZ-PRIMARY) 102 (DMZ-COMMUNITY-A) ← ✓ ! ── Verify Layer 3 SVI ────────────────────────────────────────── NetsTuts_SW1#show interfaces vlan 100 Vlan100 is up, line protocol is up Hardware is EtherSVI, address is 0c1a.2b3c.0064 Internet address is 192.168.100.1/24 ... NetsTuts_SW1#show running-config interface vlan 100 interface Vlan100 description DMZ-Gateway-PVLAN ip address 192.168.100.1 255.255.255.0 private-vlan mapping 101,102,103 ← ✓ secondaries mapped to SVI
Traffic Verification — Expected Results
! ═══════════════════════════════════════════════════════════════ ! TEST 1: Isolated → Isolated (MUST fail) ! ═══════════════════════════════════════════════════════════════ ! From Server-1 (192.168.100.11, Fa0/2): Server-1$ ping 192.168.100.12 ← Server-2 on Fa0/3 (also isolated) PING 192.168.100.12: 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 ! ✓ EXPECTED RESULT: BLOCKED — isolated ports cannot reach each other ! ═══════════════════════════════════════════════════════════════ ! TEST 2: Isolated → Gateway (MUST succeed) ! ═══════════════════════════════════════════════════════════════ Server-1$ ping 192.168.100.1 ← Router/SVI gateway PING 192.168.100.1: 56 data bytes 64 bytes from 192.168.100.1: icmp_seq=0 ttl=255 time=1.2 ms 64 bytes from 192.168.100.1: icmp_seq=1 ttl=255 time=0.9 ms ! ✓ EXPECTED RESULT: ALLOWED — isolated → promiscuous always works ! ═══════════════════════════════════════════════════════════════ ! TEST 3: Same community → same community (MUST succeed) ! ═══════════════════════════════════════════════════════════════ ! From WebSrv-A1 (192.168.100.21, Fa0/4): WebSrv-A1$ ping 192.168.100.22 ← WebSrv-A2 on Fa0/5 (same community) 64 bytes from 192.168.100.22: icmp_seq=0 ttl=64 time=0.5 ms 64 bytes from 192.168.100.22: icmp_seq=1 ttl=64 time=0.4 ms ! ✓ EXPECTED RESULT: ALLOWED — same community communicates freely ! ═══════════════════════════════════════════════════════════════ ! TEST 4: Community A → Community B (MUST fail) ! ═══════════════════════════════════════════════════════════════ WebSrv-A1$ ping 192.168.100.31 ← AppSrv-B1 on Fa0/6 (different community) Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 ! ✓ EXPECTED RESULT: BLOCKED — different communities cannot reach each other ! ═══════════════════════════════════════════════════════════════ ! TEST 5: Community → Isolated (MUST fail) ! ═══════════════════════════════════════════════════════════════ WebSrv-A1$ ping 192.168.100.11 ← Server-1 on Fa0/2 (isolated) Request timeout for icmp_seq 0 ! ✓ EXPECTED RESULT: BLOCKED — community cannot reach isolated ! ═══════════════════════════════════════════════════════════════ ! TEST 6: Gateway → all hosts (MUST succeed) ! ═══════════════════════════════════════════════════════════════ NetsTuts_SW1#ping 192.168.100.11 ← Server-1 isolated !!!!! ← ✓ promiscuous SVI reaches all host types NetsTuts_SW1#ping 192.168.100.21 ← WebSrv-A1 community A !!!!! ← ✓ NetsTuts_SW1#ping 192.168.100.31 ← AppSrv-B1 community B !!!!! ← ✓
MAC Address Table — PVLAN Entries
! ── MAC table shows secondary VLAN as the VLAN for host ports ────
NetsTuts_SW1#show mac address-table vlan 101
Mac Address Table
-------------------------------------------
Vlan Mac Address Type Ports
---- ----------- -------- -----
101 aabb.cc00.0011 DYNAMIC Fa0/2 ← Server-1 in isolated VLAN 101
101 aabb.cc00.0012 DYNAMIC Fa0/3 ← Server-2 in isolated VLAN 101
NetsTuts_SW1#show mac address-table vlan 100
100 aabb.cc00.0001 DYNAMIC Gi0/1 ← Router MAC in primary VLAN 100
! ── Promiscuous port entries appear in primary VLAN (100) ────────
! ── Host port entries appear in their secondary VLAN ─────────────
The MAC address table reveals the two-tier PVLAN structure
clearly: host port MAC addresses are learned in the secondary
VLAN (101, 102, or 103), while the promiscuous port's MAC
is learned in the primary VLAN (100). This is why a frame
from Server-1 (VLAN 101) destined for the router is forwarded
correctly — the switch looks up the router's MAC in VLAN 100
(the primary), finds it on Gi0/1, and sends the frame there.
The reverse path (router to Server-1) works because the
promiscuous port mapping tells the switch that VLAN 101 traffic
can reach Fa0/2.
9. Complete Configuration Reference & Key Points
Full Running Configuration — NetsTuts_SW1
! ════════════ COMPLETE PVLAN CONFIGURATION ═══════════════════════ vtp mode transparent vlan 100 name DMZ-PRIMARY private-vlan primary private-vlan association 101,102,103 ! vlan 101 name DMZ-ISOLATED private-vlan isolated ! vlan 102 name DMZ-COMMUNITY-A private-vlan community ! vlan 103 name DMZ-COMMUNITY-B private-vlan community ! interface GigabitEthernet0/1 description Uplink-to-R1-Promiscuous switchport mode private-vlan promiscuous switchport private-vlan mapping 100 101,102,103 ! interface FastEthernet0/2 description Server-1-ISOLATED switchport mode private-vlan host switchport private-vlan host-association 100 101 ! interface FastEthernet0/3 description Server-2-ISOLATED switchport mode private-vlan host switchport private-vlan host-association 100 101 ! interface FastEthernet0/4 description WebSrv-A1-COMMUNITY-A switchport mode private-vlan host switchport private-vlan host-association 100 102 ! interface FastEthernet0/5 description WebSrv-A2-COMMUNITY-A switchport mode private-vlan host switchport private-vlan host-association 100 102 ! interface FastEthernet0/6 description AppSrv-B1-COMMUNITY-B switchport mode private-vlan host switchport private-vlan host-association 100 103 ! interface FastEthernet0/7 description AppSrv-B2-COMMUNITY-B switchport mode private-vlan host switchport private-vlan host-association 100 103 ! interface Vlan100 description DMZ-Gateway-PVLAN ip address 192.168.100.1 255.255.255.0 private-vlan mapping 101,102,103 ! ip routing
PVLAN Command Reference
| Command | Mode | Purpose |
|---|---|---|
vtp mode transparent |
Global config | Required before PVLAN configuration — prevents VTP from overwriting secondary VLANs |
private-vlan primary |
VLAN config | Designates a VLAN as the primary VLAN — the outer container of the PVLAN domain |
private-vlan isolated |
VLAN config | Designates a VLAN as an isolated secondary — maximum isolation, only communicates with promiscuous ports |
private-vlan community |
VLAN config | Designates a VLAN as a community secondary — members of the same community can communicate with each other and promiscuous ports |
private-vlan association [sec-vlans] |
VLAN config (primary) | Associates secondary VLANs to the primary VLAN — configured under the primary VLAN |
switchport mode private-vlan promiscuous |
Interface config | Sets the port as a promiscuous port — can communicate with all PVLAN port types |
switchport mode private-vlan host |
Interface config | Sets the port as a host port — used for both isolated and community ports |
switchport private-vlan mapping [pri] [sec] |
Interface config (promiscuous) | Maps the promiscuous port to primary and secondary VLANs — specifies which secondary VLANs the promiscuous port can reach |
switchport private-vlan host-association [pri] [sec] |
Interface config (host) | Associates a host port with a primary and secondary VLAN — the secondary VLAN type determines isolation behaviour |
private-vlan mapping [sec-vlans] |
Interface config (SVI) | Maps secondary VLANs to an SVI on the primary VLAN — enables the SVI to route traffic from all secondary VLANs using one IP gateway |
show vlan private-vlan |
Privileged exec | Displays primary/secondary VLAN relationships and which ports belong to each secondary VLAN — primary verification command |
show vlan private-vlan type |
Privileged exec | Shows the PVLAN type (primary, isolated, community) assigned to each VLAN |
show interfaces [int] switchport |
Privileged exec | Shows PVLAN mode and mappings for a specific interface — use to verify promiscuous mappings and host associations |
Key Points & Exam Tips
- VTP must be transparent before configuring PVLANs. This is the most commonly missed prerequisite. VTP server/client mode does not propagate PVLAN configuration and may overwrite it. Set
vtp mode transparentfirst — always. - One primary VLAN, one isolated secondary, multiple community secondaries. A PVLAN domain has exactly one primary VLAN. It can have at most one isolated secondary VLAN (because all isolated ports share the same secondary VLAN — they are all equally isolated from each other). It can have multiple community secondary VLANs — one per group.
- The router only sees the primary VLAN. Traffic from any secondary VLAN is translated to the primary VLAN when it exits the promiscuous port. This is why only one subinterface or SVI is needed on the router — the Layer 2 segmentation is invisible above the switch.
- Both isolated and community host ports use the same port mode:
switchport mode private-vlan host. The isolation behaviour is determined by the secondary VLAN type (isolated vs community), not by the port mode command. The difference between isolated and community is entirely in the VLAN configuration, not the port configuration. - Isolated ports cannot communicate with each other even in the same isolated VLAN. This surprises many engineers. Two ports both in VLAN 101 (isolated) cannot exchange frames — isolated means isolated from all other host ports, period. They can only reach the promiscuous port.
- The
private-vlan mappingcommand is needed in two places: on the promiscuous port (switchport private-vlan mapping) and on the SVI if Layer 3 switching is used (private-vlan mappingunder the VLAN interface). Missing the SVI mapping means hosts cannot reach the default gateway even though the promiscuous port is correctly configured. - Community VLAN cross-communication goes through the promiscuous port. A host in community A wanting to reach a host in community B cannot do so directly at Layer 2. The traffic must go community A → promiscuous (router) → promiscuous → community B. This is routed traffic at Layer 3, not bridged — it increments the TTL hop count.
- PVLANs are supported on Catalyst 3560, 3750, 4500, 6500, and 9000 series but NOT on Catalyst 2960 in most software versions (2960 supports port isolation via Protected Ports — a simpler but less flexible mechanism). Always check platform compatibility.
- PVLAN vs Protected Ports: Protected ports (
switchport protected) provide a simpler form of port isolation — protected ports cannot communicate with other protected ports on the same switch, but they can communicate with unprotected ports. Protected port isolation does not extend across trunk links to other switches. PVLANs provide richer policy (isolated vs community) and work across trunks. For per-device MAC-based access control, also see Port Security & Sticky MAC.
Related Labs: Private VLANs work alongside
other Layer 2 security features. Add
DHCP Snooping
to prevent rogue DHCP servers within the PVLAN domain.
Use Storm
Control to protect promiscuous ports from broadcast
storms originating in isolated or community VLANs. For the
standard VLAN and trunking foundations that PVLANs build
on see
Trunk Port
Configuration and for debugging VLAN issues see
Troubleshooting
Layer 2 — VLAN & Trunk Issues. In
multi-tenant environments, combine PVLANs with
VRF-Lite to
provide complete Layer 2 and Layer 3 tenant isolation.
For monitoring PVLAN traffic without breaking the isolation
model, see SPAN & RSPAN Port Mirroring.
TEST WHAT YOU LEARNED
A switch is configured with primary VLAN 200, isolated secondary VLAN 201, and community secondary VLAN 202. Host A is in VLAN 201 (isolated), Host B is also in VLAN 201 (isolated), and Host C is in VLAN 202 (community). Can Host A ping Host B directly? Can Host A ping Host C directly?
Correct answer is B. The defining characteristic of an isolated secondary VLAN is that its ports cannot communicate with any other host port — full stop. The isolation is absolute: an isolated port cannot send frames to other isolated ports (even in the same isolated VLAN), to community ports, or to any port except a promiscuous port. The fact that Host A and Host B are in the same isolated VLAN (201) does not change this — "isolated" means each port is isolated from all others. This is in contrast to a community port, which can communicate with other ports in the same community VLAN. The only communication path available to Host A is via the promiscuous port (router/gateway). If Host A needs to communicate with Host B, it must send the packet to the default gateway, which routes it back to Host B as a Layer 3 routed packet — entering the promiscuous port and exiting to Host B's port. This is an intentional design: the gateway can implement access control policies, logging, and inspection on all intra-subnet traffic.
Why must VTP be set to transparent mode before configuring Private VLANs, and what happens if PVLANs are configured while the switch is in VTP server or client mode?
Correct answer is D. VTP (VLAN Trunking Protocol) was designed to propagate standard VLAN information across a switched network. VTP versions 1 and 2 only understand standard VLANs (1-1005) and their basic attributes (name, state, MTU). PVLAN attributes — the type designations (primary, isolated, community) and the primary-to-secondary associations — are not part of the VTP v1/v2 TLV (Type-Length-Value) structures. When a switch in VTP server or client mode receives a VTP advertisement, it updates its local VLAN database to match. If the VTP server's database has VLAN 101 as a plain VLAN (not an isolated secondary), or doesn't have VLAN 101 at all, the VTP synchronisation will either reclassify the VLAN (removing the isolated designation) or delete it. Either way, the PVLAN domain breaks. The safest operational practice is always to set switches that will have PVLAN configuration to transparent mode. VTP version 3 (supported on Catalyst 4500 IOS-XE, 6500, and 9000 in newer code) does carry PVLAN information in its advertisements, but VTP v3 deployment requires explicit configuration and is not the default.
An engineer configures a promiscuous port with switchport private-vlan mapping 100 101,102 but forgets to include VLAN 103 in the mapping. Community VLAN 103 hosts have switchport private-vlan host-association 100 103 configured correctly. What happens to traffic from VLAN 103 hosts?
Correct answer is A. The promiscuous port mapping explicitly defines which secondary VLANs the promiscuous port can communicate with. If VLAN 103 is not in the mapping (
switchport private-vlan mapping 100 101,102), the switch will not forward VLAN 103 frames out the promiscuous port — frames from VLAN 103 hosts destined for the router are simply dropped at the switch. However, intra-community communication within VLAN 103 is controlled by the secondary VLAN type — community ports in VLAN 103 can still reach each other directly because that traffic stays within the switch and never needs to go through the promiscuous port. The result is a partially broken VLAN 103: AppSrv-B1 can ping AppSrv-B2 (same community), but neither can reach the default gateway at 192.168.100.1. This is a common configuration mistake and can be diagnosed by checking show interfaces GigabitEthernet0/1 switchport and verifying the mapping includes all secondary VLANs. The fix is: switchport private-vlan mapping 100 101,102,103 (or add 103 syntax on some platforms).What is the difference between Private VLANs (PVLAN) and Protected Ports (switchport protected) in terms of functionality and scope?
Correct answer is C. Protected Ports and Private VLANs both solve the intra-VLAN isolation problem, but at different levels of sophistication. Protected Ports: configured with
switchport protected on individual ports; all protected ports on the same switch cannot send frames to each other (regardless of VLAN); unprotected ports can communicate freely with all ports; the feature is entirely local to one switch — a protected port on switch A and a protected port on switch B are completely unaware of each other and can communicate normally via a trunk. This makes Protected Ports unsuitable for multi-switch deployments where isolation must be maintained end-to-end. PVLANs: support the isolated (maximum isolation) and community (group isolation) models; the isolation policy is enforced based on secondary VLAN membership, which is propagated across 802.1Q trunk links; multiple switches can all enforce the same PVLAN policy because the secondary VLAN tags carry the policy information. PVLANs also support the promiscuous/host port architecture with one gateway IP for all isolated hosts — Protected Ports have no equivalent of this. The practical guidance: use Protected Ports for simple single-switch isolation on 2960 platforms; use PVLANs for complex multi-switch topologies and service provider/data-centre environments where structured group isolation is needed.A Catalyst 3560 is configured as a Layer 3 switch with a PVLAN domain. The engineer creates an SVI for VLAN 100 (primary) but does NOT run private-vlan mapping 101,102,103 on the SVI. What is the result?
Correct answer is D. The
private-vlan mapping command on the SVI is the Layer 3 equivalent of the switchport private-vlan mapping on a promiscuous access port. When a host in isolated VLAN 101 sends a packet destined for 192.168.100.1 (the default gateway), the frame arrives at the L3 switch tagged as VLAN 101. The Layer 3 switch must determine which SVI to process this for. If there is no SVI for VLAN 101 (which there shouldn't be — secondary VLANs don't get SVIs in a PVLAN deployment) and no mapping associating VLAN 101 with the VLAN 100 SVI, the packet has nowhere to go and is dropped. The private-vlan mapping 101,102,103 command under interface vlan 100 creates this association — it tells the routing engine: "frames arriving from VLANs 101, 102, and 103 should be processed by the VLAN 100 SVI." After this is configured, the L3 switch accepts the packet, processes it against the VLAN 100 interface's IP address (192.168.100.1), and routes it appropriately. This is a commonly missed step: engineers correctly configure the Layer 2 PVLAN (VLANs, host-association, promiscuous port mapping) but forget the SVI mapping, then spend time troubleshooting why hosts can't reach the gateway.In a PVLAN topology, when a host in isolated VLAN 101 sends a frame to the router (promiscuous port), which VLAN tag does the frame carry as it exits the promiscuous port toward the router?
Correct answer is B. This secondary-to-primary VLAN translation on the promiscuous port is one of the most architecturally significant aspects of PVLAN. When a host port sends a frame, it is tagged with the secondary VLAN (101, 102, or 103). As the switch forwards this frame out the promiscuous port, it rewrites the VLAN tag from the secondary VLAN to the primary VLAN (100). The upstream router receives a frame tagged as VLAN 100 — it sees a normal frame from the 192.168.100.0/24 subnet with no indication that it came from an isolated or community port. The reverse direction (router → host) also involves a translation: the router sends a frame tagged VLAN 100; the switch receives it on the promiscuous port, looks up the destination MAC in the PVLAN forwarding table, identifies which secondary VLAN the destination host is in, and rewrites the tag to that secondary VLAN before forwarding to the host port. This bidirectional tag translation is what allows the entire PVLAN architecture to be transparent to the router — one subinterface serves potentially hundreds of isolated host ports in different secondary VLANs, all appearing to the router as a single flat /24 subnet.
Can a primary VLAN have more than one isolated secondary VLAN? Can it have more than one community secondary VLAN? Explain the architectural reasons for each answer.
Correct answer is C. The PVLAN specification (RFC 5517 and IEEE 802.1Q private VLAN) constrains a primary VLAN to a single isolated secondary VLAN because isolated ports all exhibit the same behaviour — no port-to-port communication, only promiscuous port communication. Since there is no meaningful difference between "isolated VLAN 101" and "isolated VLAN 104" ports (both have zero peer communication), creating multiple isolated VLANs would consume VLAN ID space without providing any additional functionality. All isolated hosts in the entire PVLAN domain share one isolated VLAN. Community VLANs serve a fundamentally different purpose — each community VLAN defines a distinct group whose members can communicate with each other but not with other groups. The groups must be different VLANs because the secondary VLAN ID is the mechanism by which the switch determines intra-community forwarding. VLAN 102 frames can reach other VLAN 102 ports; VLAN 103 frames can reach other VLAN 103 ports; VLAN 102 frames cannot reach VLAN 103 ports. Without separate VLAN IDs, the switch cannot distinguish community A members from community B members. In practice, you can have dozens of community VLANs under a single primary VLAN — for example, a hosting provider might create one community VLAN per tenant (Tenant1=VLAN102, Tenant2=VLAN103, Tenant3=VLAN104, etc.) all under a single primary VLAN 100.
After configuring PVLANs, show vlan private-vlan shows the correct primary/secondary associations but no ports are listed under any secondary VLAN. show interfaces Fa0/2 switchport shows "Administrative Mode: static access, Access Mode VLAN: 1." What went wrong and how do you fix it?
Correct answer is A. The symptom — "Administrative Mode: static access, Access Mode VLAN: 1" — is the default switchport state. This means the interface was never configured with PVLAN-specific commands. The PVLAN VLAN configuration (creating VLANs, setting types, setting associations) is only half of the configuration. The port configuration is the other half and must be done separately on each interface. The port needs two commands: (1)
switchport mode private-vlan host — changes the port from standard access mode to PVLAN host mode; (2) switchport private-vlan host-association 100 101 — tells the port which primary and secondary VLAN it belongs to. Only after both commands are entered will the port appear in the show vlan private-vlan output under the correct secondary VLAN. A common diagnostic approach: use show vlan private-vlan to check if ports appear under the secondary VLANs, and then show interfaces [int] switchport to check the per-port PVLAN configuration. If the VLAN table shows the correct structure but no ports are listed, the port-level configuration is missing or incomplete.A service provider uses PVLANs in a hosting environment with 50 customer web servers, each needing full isolation from other customers, all sharing the same /24 subnet for management simplicity. Which PVLAN design is most appropriate, and why?
Correct answer is D. When the requirement is "each host isolated from all others," the isolated secondary VLAN is the correct and most efficient tool. The key insight is that an isolated VLAN provides uniform isolation for all its member ports with minimal configuration. For 50 servers, you configure one isolated VLAN (e.g., VLAN 201), then assign all 50 server ports to that VLAN with host-association. Done. No server can reach any other server. Option A (50 community VLANs) is technically correct but wasteful: community VLANs are designed for when members of a group need to communicate with each other. If there is no intra-group communication requirement, a community VLAN provides no benefit over an isolated VLAN. Creating 50 community VLANs with one port each is essentially the same as an isolated VLAN but consumes 50x the VLAN IDs and requires 50x the configuration. In a data centre with hundreds of isolated customers, VLAN ID conservation matters — PVLAN allows you to serve all isolated customers from a single VLAN ID (the isolated secondary VLAN), leaving the VLAN ID space for other purposes. The only scenario where Option A would be correct is if some customers have multiple servers that need to communicate with each other (intra-customer communication permitted, inter-customer communication blocked) — then each multi-server customer gets their own community VLAN, and single-server customers or customers requiring full isolation go into the isolated VLAN.
A network engineer needs to add a new community VLAN (VLAN 104) to an existing PVLAN domain that already has primary VLAN 100 with secondaries 101, 102, 103. What is the complete sequence of steps required?
Correct answer is C. Adding a new secondary VLAN to an existing PVLAN domain requires updates in four places, not just one. Each update has a specific reason: (1) Creating VLAN 104 as a community VLAN establishes its existence and type in the VLAN database. (2) Updating the primary VLAN association (
private-vlan association add 104) links the new secondary to the primary — without this, VLAN 104 exists as a standalone VLAN, not as a PVLAN secondary. The add keyword appends to the existing list (101,102,103) rather than replacing it — using private-vlan association 101,102,103,104 without add also works but requires listing all existing secondaries. (3) Updating the promiscuous port mapping (switchport private-vlan mapping 100 add 104) — without this, VLAN 104 hosts cannot reach the gateway. Again, add preserves existing mappings. (4) Updating the SVI mapping if Layer 3 routing is on the switch — without this, the L3 switch cannot route traffic from VLAN 104 hosts. (5) Finally, the host port configurations place actual ports into the new community VLAN. Missing any of these steps results in partially broken connectivity for VLAN 104 members — they might have intra-community communication but no gateway access, or they might have gateway access but no PVLAN enforcement. The systematic approach in option C ensures all four layers of the PVLAN configuration are consistently updated.Related Topics & Step-by-Step Tutorials
Related concepts and next steps:
- VLANs – Concepts & Overview — standard VLAN concepts
- Port Security – Concepts & Overview — port security — complementary isolation technique
- VLAN Creation and Management
- Assigning VLANs to Switch Ports (Cisco IOS)
- Port Security & Sticky MAC Configuration