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
┌─────────────────────────────────────────────────────────────────────┐ │ PRIMARY VLAN (e.g., VLAN 100) │ │ "The container — defines the IP subnet" │ │ 192.168.100.0/24 │ │ │ │ ┌──────────────────┐ ┌─────────────────┐ ┌────────────────┐ │ │ │ ISOLATED VLAN │ │ COMMUNITY VLAN A│ │COMMUNITY VLAN B│ │ │ │ (e.g., VLAN 101)│ │ (e.g., VLAN 102│ │ (e.g., VLAN 103│ │ │ │ │ │ │ │ │ │ │ │ Ports in this │ │ Ports can talk │ │ Ports can talk│ │ │ │ VLAN CANNOT │ │ to each other │ │ to each other │ │ │ │ talk to any │ │ within the │ │ within the │ │ │ │ other host port │ │ community │ │ community │ │ │ │ — only to the │ │ ONLY. Cannot │ │ ONLY. Cannot │ │ │ │ promiscuous port│ │ talk to │ │ talk to VLAN A│ │ │ │ │ │ isolated or │ │ or isolated │ │ │ │ Fa0/2, Fa0/3 │ │ other community│ │ ports │ │ │ │ │ │ │ │ │ │ │ │ │ │ Fa0/4, Fa0/5 │ │ Fa0/6, Fa0/7 │ │ │ └──────────────────┘ └─────────────────┘ └────────────────┘ │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ PROMISCUOUS PORT (Gi0/1) │ │ │ │ Can communicate with ALL ports in the primary VLAN — │ │ │ │ isolated, community A, community B, and other promiscuous │ │ │ │ Connected to: router/firewall/L3 switch uplink │ │ │ └─────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────┘
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
192.168.100.1/24
┌────────────────┐
│ NetsTuts_R1 │ ← Router / Firewall
│ Gi0/1 (uplink)│ Gateway for all PVLAN hosts
└───────┬────────┘
│ Gi0/1 — PROMISCUOUS port
│ Primary VLAN 100 mapped to
│ secondaries 101, 102, 103
┌─────────┴──────────────────────────────┐
│ NetsTuts_SW1 (Catalyst 3560) │
│ VTP mode: transparent │
│ │
ISOLATED VLAN 101 COMMUNITY A VLAN 102 COMMUNITY B VLAN 103
┌──────────────┐ ┌───────────────────┐ ┌──────────────────┐
│ Fa0/2 │ │ Fa0/4 │ │ Fa0/6 │
│ Server-1 │ │ WebSrv-A1 │ │ AppSrv-B1 │
│ 192.168.100.11│ │ 192.168.100.21 │ │ 192.168.100.31 │
│ │ │ │ │ │
│ Fa0/3 │ │ Fa0/5 │ │ Fa0/7 │
│ Server-2 │ │ WebSrv-A2 │ │ AppSrv-B2 │
│ 192.168.100.12│ │ 192.168.100.22 │ │ 192.168.100.32 │
└──────────────┘ └───────────────────┘ └──────────────────┘
VLAN Plan:
VLAN 100 — Primary VLAN (DMZ subnet 192.168.100.0/24)
VLAN 101 — Isolated secondary (Server-1 and Server-2 cannot reach each other)
VLAN 102 — Community A secondary (WebSrv-A1 and WebSrv-A2 can reach each other)
VLAN 103 — Community B secondary (AppSrv-B1 and AppSrv-B2 can reach each other)
Gi0/1 — Promiscuous uplink to R1 (can reach all host ports)
Communication Rules enforced by PVLAN:
Server-1 ↔ Server-2: BLOCKED (both isolated VLAN 101)
Server-1 → R1: ALLOWED (isolated → promiscuous)
WebSrv-A1 ↔ WebSrv-A2: ALLOWED (same community VLAN 102)
WebSrv-A1 → AppSrv-B1: BLOCKED (different communities)
WebSrv-A1 → Server-1: BLOCKED (community → isolated)
WebSrv-A1 → R1: ALLOWED (community → promiscuous)
AppSrv-B1 ↔ AppSrv-B2: ALLOWED (same community VLAN 103)
R1 → any host: ALLOWED (promiscuous → all)
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).
┌──────────────────────────────────────────────────┐
│ NetsTuts_SW1 (primary switch) │
│ Primary VLAN 100, secondaries 101, 102, 103 │
│ Trunk: Gi0/24 ─────────────────────┐ │
└──────────────────────────────────────┼────────────┘
│ 802.1Q trunk
│ VLANs 100,101,102,103 allowed
┌──────────────────────────────────────┼────────────┐
│ NetsTuts_SW2 (secondary switch) │ │
│ Must have same PVLAN configuration │ │
│ Trunk: Gi0/24 ─────────────────────┘ │
│ Host ports Fa0/10–Fa0/15 on SW2 │
└──────────────────────────────────────────────────┘
! ── 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.