Private VLANs: Isolating Hosts That Share a Subnet

Imagine a hosting segment or a DMZ where twenty servers share one subnet. They all need to reach the gateway, but they have no business talking to each other. The obvious fix is a subnet per server, but that burns address space, multiplies SVIs, and turns a simple rack into a routing project. Private VLANs (PVLANs) solve the same problem the elegant way: they isolate hosts that share a subnet, at Layer 2, without giving each host its own network. This article is part of the PingLabz VLANs and Layer 2 switching cluster and the wider network infrastructure security guide, and every configuration and show command below was captured live on a Cisco IOL-XE switch in CML.

The private VLAN model: primary and secondary

A private VLAN is not one VLAN, it is a small family of them working together. There is one primary VLAN and one or more secondary VLANs associated with it. Every host lives in a secondary VLAN, but they all share the primary VLAN's subnet and gateway. What changes is the rules for who can talk to whom, and that depends on which type of secondary VLAN a port sits in.

Two port roles carry this. A host port belongs to a secondary VLAN and follows that VLAN's isolation rules. A promiscuous port belongs to the primary VLAN and can talk to every secondary, which is exactly what the gateway needs so it can route for all of them. The mental model: isolated ports are strangers on a train (they share the carriage but do not speak), community ports are a table of colleagues (they speak among themselves), and the promiscuous port is the conductor everyone can flag down.

Configuring the private VLAN

PVLANs require the switch to be in VTP transparent mode, because VTP versions 1 and 2 do not propagate private VLAN information and will not let you create them otherwise. After that, you define the primary, define each secondary with its type, and associate the secondaries with the primary:

vtp mode transparent
vlan 500
 private-vlan primary
vlan 501
 private-vlan isolated
vlan 502
 private-vlan community
vlan 500
 private-vlan association 501,502

VLAN 500 is the primary. VLAN 501 is an isolated secondary and VLAN 502 is a community secondary. The final block associates both secondaries with the primary, which is the step that ties the family together. Without the association, you just have three unrelated VLANs.

The association is real and up, which you can confirm with a single command:

SW1#show vlan private-vlan
Primary Secondary Type              Ports
------- --------- ----------------- ------------------------------------------
500     501       isolated
500     502       community

This output is the heart of the feature. VLAN 500 now owns two secondaries: 501 as isolated and 502 as community. Any host port you drop into 501 gets full isolation; any host port in 502 gets community behaviour. The switch enforces the rules; you do not write a single access-list.

Assigning host and promiscuous ports

With the VLANs built, you place ports. A host port needs two things: the mode, and the host-association that says which primary and secondary it belongs to. A promiscuous port needs its mode and a mapping that lists every secondary it should reach:

interface Ethernet0/1
 switchport mode private-vlan host
 switchport private-vlan host-association 500 501       ! HOST1 into the ISOLATED secondary
interface Ethernet0/0
 switchport mode private-vlan promiscuous
 switchport private-vlan mapping 500 501,502            ! the gateway uplink talks to all

Et0/1 is a host port associated with primary 500 and isolated secondary 501, so the host behind it is fully isolated from other isolated members. Et0/0 is the promiscuous uplink to the gateway, mapped to both 501 and 502, so the router can reach every host regardless of which secondary it lives in. That asymmetry is the entire point: hosts cannot reach each other, but the gateway can reach all of them, and they can all reach the gateway.

The port genuinely takes the mode, which you can verify on the interface:

SW1#show interface Ethernet0/1 switchport
Administrative Mode: private-vlan host
Operational Mode: private-vlan host

Administrative and operational mode both read private-vlan host, so the port is not just configured for the role, it is actively operating in it.

The isolation rule, spelled out

Here is the behaviour the model produces, which is the whole reason to deploy PVLANs. Two hosts sitting in the isolated secondary (VLAN 501) share the same subnet and the same default gateway. They are, by every appearance on the host side, neighbours on one network. Yet they cannot reach each other at Layer 2: every frame the switch would normally bridge between two isolated ports is dropped. At the same time, both hosts still reach the promiscuous uplink, so both can route out through the gateway and receive traffic back. You get host-to-host isolation and full gateway reachability at once, inside a single subnet.

Community ports soften this by one degree. Put two servers in community VLAN 502 and they can talk to each other and to the uplink, but not to isolated ports and not to a different community. That is the right tool when a small set of servers legitimately need to cluster (say, two database replicas) while remaining walled off from the rest of the segment.

An honest note on this lab: the private VLAN configuration and association were proven end to end on IOL-XE (the config was accepted, the association shows up, and the host port operates in private-vlan host mode, all captured above). A full host-to-host isolation ping between two isolated members was not run in the capture window, so this article describes the isolation behaviour the platform enforces rather than claiming a packet capture we did not take. The design behaviour is well defined and matches the configuration state shown here.

Walking a frame through the private VLAN

It helps to follow individual frames to see why the isolation is airtight. Say HOST1 (isolated, Et0/1) wants to reach HOST2 (also isolated) in the same secondary. HOST1 sees HOST2 as a local subnet address, ARPs for it, and would normally bridge a frame straight across. But the switch knows both ports are in isolated secondary 501, and the rule for isolated ports is simple: frames may only go to a promiscuous port. There is no promiscuous port in that path, so the frame is dropped in the switch fabric. HOST2 never hears the ARP, let alone the data.

Now say HOST1 wants to reach the gateway. The gateway sits on the promiscuous port Et0/0, which is mapped to secondary 501. Isolated-to-promiscuous is explicitly allowed, so the frame is forwarded, the router routes it, and the reply comes back down the promiscuous port to HOST1. From HOST1 the network feels completely normal: DNS, default route, internet access all work. It simply cannot see its neighbours. That selective forwarding, allow to the uplink and deny to peers, is enforced per frame by the switch with no access-list involved, which is why PVLANs scale to hundreds of ports without a maintenance burden.

Isolated or community: choosing the secondary type

Most secure segments default to isolated, because the safest posture is that no host trusts any other host. Reach for a community secondary only when a specific group of hosts has a legitimate reason to talk directly and you want to keep that conversation off the router. Two clustered database nodes replicating to each other, or a pair of load-balanced app servers exchanging health checks, are good candidates: put them in one community and they see each other, but they still cannot reach the isolated servers or a second community. Everything else stays isolated. A practical design rule: start every port isolated, and promote only the exact ports that prove they need community membership. It is far easier to open a door later than to discover, after a breach, that a community you created two years ago let an attacker walk from one server to five others.

The classic use case: DMZ and hosting isolation

PVLANs shine anywhere many hosts must share a subnet but must not trust each other. The textbook example is a DMZ or a multi-tenant hosting segment. Put every server in an isolated secondary and each one can reach the firewall (the promiscuous uplink) but none can reach its neighbours. If one server is compromised, the attacker's usual next move, pivoting sideways to the servers next to it, is dead on arrival, because the switch simply will not bridge frames between isolated ports. You get that protection without a subnet per server, without a wall of SVIs, and without maintaining a large VACL by hand.

PVLANs and VACLs are complementary, not competing. A VACL, covered in the VLAN ACLs article, gives you surgical, protocol-aware filtering between named hosts. A private VLAN gives you effortless, all-or-nothing isolation across an entire segment. Hardened designs often use both: the PVLAN for broad isolation, a VACL for the handful of specific flows that still need to be permitted.

Gotchas worth knowing

• VTP transparent is mandatory. If the switch is a VTP client or server on v1/v2, you cannot create private VLANs. Set vtp mode transparent first.
• The promiscuous mapping must list every secondary. Forget to map a secondary and the hosts in it lose their gateway, which looks like a total outage for those hosts even though isolation is working perfectly.
• Trunking PVLANs between switches needs care. Extending private VLANs across a trunk requires the secondaries to be carried and associated consistently on both ends, or the isolation breaks at the boundary.
• Isolation is Layer 2, not Layer 3. A router on the promiscuous port can still route traffic back down to any host, so if two isolated hosts are in different subnets reachable via that router, they could reach each other through it. PVLAN isolation stops the bridged path, not a deliberately routed one.

For how private VLANs fit alongside every other switch-hardening control, keep reading the VLANs and Layer 2 switching cluster and the network infrastructure security guide.

Key Takeaways

• Private VLANs isolate hosts that share a subnet, at Layer 2, without a subnet per host. A primary VLAN owns the subnet; secondary VLANs set the isolation rules.
• Isolated secondary members cannot talk to each other, only to the promiscuous uplink. Community secondary members can talk to each other and the uplink, but not to other communities or isolated ports.
• Host ports carry the isolation; the promiscuous port (the gateway uplink) can reach every secondary, which is why hosts always keep their gateway.
• Configuration requires VTP transparent mode, then private-vlan primary/isolated/community and an association. In the lab, show vlan private-vlan confirmed 500/501 isolated and 500/502 community, and the host port operated in private-vlan host mode.
• The classic use is a DMZ or hosting segment: servers reach the gateway but cannot pivot to each other if one is compromised, with no subnet-per-server and no large VACL to maintain.
• PVLANs and VACLs complement each other. Use a private VLAN for broad isolation and a VACL for selective flows. See the full VLANs and Layer 2 switching cluster.