Due to the non-decreasing interest to the post about Private VLANs, I decided to make another one, more detailed – including a diagram and verification techniques.
To begin with, look at the concept of VLAN as a broadcast domain. What Private VLANs (PVANs) do, is they split the domain into multiple isolated broadcast subdomains. It’s a nesting concept – subVLANs inside a VLAN. Next, as we know, Ethernet VLANs are not allowed to communicate directly with each other - they require a L3 device to forward packets between broadcast domains. The same concept applies to PVLANS - since the subdomains are isolated at level 2, they need to communicate using an upper level (L3/packet forwarding) entity - such as router. However, there is difference here. Regular VLANs usually correspond to a single IP subnet. When we split VLAN using PVLANs, hosts in different PVLANs still belong to the same IP subnet, but now they need to use a router (L3 device) to talk to each other (for example, by using local Proxy ARP). In turn, router may either permit or forbid communications between sub-VLANs using access-lists. Why would anyone need Private VLANs? Commonly, this kind of configurations arise in “shared” environments, say ISP co-location, where it’s beneficial to put multiple customers into the same IP subnet, yet provide a good level of isolation between them.
For our sample configuration, we take VLAN 1000 and divide it into three PVLANs - sub-VLAN 1012 (R1 and R2), sub-VLAN 1034 (R3 and R4) and sub-VLAN 1055 (router R5 only). Router R6 will be used as layer 3 device, which resolves the layer 3 communication issue. Look at the diagram above for reference. Now we call the regular VLAN 1000 “Primary” and then classify the ports, assigned to this VLAN, based on their types:
Promiscuous (“P”): Usually connects to a router - a type of a port which is allowed to send and receive frames from any other port on the VLAN
Isolated (“I”): This type of port is only allowed to communicate with “P”-ports - they are “stub”. This type of ports usually connects to hosts
Community (“C”): Community ports are allowed to talk to their buddies, sharing the same group (of course they can talk to “P”-ports)
In order to implement sub-VLAN behavior, we need to define how packets are forwarded between different port types. First comes the Primary VLAN - (VLAN 1000 in our example). This type of VLANs is used to forward frames downstream from “P”-ports to all other port types (“I” and “C” ports). In essence, Primary VLAN entails all port in domain, but is only used to transport frames from a router to hosts (from “P” to “I” and “C”). Next come “Secondary” VLANs - they correspond to “Isolated” and “Community” ports. Those VLANs are used to transport frames in the opposite direction (upstream) - from “I” and “C” ports to “P” ports.
Isolated VLAN: forwards frames from I ports to P ports. Since Isolated ports do not exchange frames with each other, we can use just ONE isolated VLAN to connect all I-Port to the P-port.
Community VLANs: Transport frames between community ports (C-ports) within to the same group (community) and forward frames upstream to the P-ports of the primary VLAN.
Here is a simplified overview of how Private VLANs work:
The Primary VLAN delivers frames downstream: from the router (promisc port) to all mapped hosts; The Isolated VLAN transports frames from the stub hosts upstream to the router; And the Community VLANs allow bi-directional frame exchange withing a single group, in addition to forwarding frames upstream towards “P”-port (or ports). The original Ethernet MAC address learning and forwarding procedure remain the same, as well as broadcast/multicast flooding within respective primary/secondary VLANs. Naturally, private VLANs could be trunked - the secondary VLAN numbers are used to tag frames, just as with regular VLANs, and the primary VLAN traffic is trunked as well. However, you need to configure Private VLAN specific settings (bindings, mappings) on every participating swtich, for it’s not possible to use VTP to dissiminate that information. This due to the fact that VTPv2 has no TLVs to carry private VLANs information, and besides, private VLANs are not intended to be floodes across the whole management domain. Not to mention that using VTP in enterprise networks is usually not a good idea :).
Let’s move to the configuration part, based on the diagram above. What we have is primary VLAN 1000, Isolated VLAN 1005 (R5) Community VLAN 1012 (R1, R2) and Community VLAN 1034 (R3, R4).
Step 1:
First, disable VTP, i.e. enable VTP transparent mode. After disabling VTP, create Primary and Secondary VLANs and bind them into PVLAN domain:
SW1: vtp mode transparent ! ! Creating primary VLAN, which is shared among secondary’s ! vlan 1000 private-vlan primary ! ! Community VLAN for R1 and R2: allows a “subVLAN” within a Primary VLAN ! vlan 1012 private-vlan community ! ! Community VLAN for R3 and R4 ! vlan 1034 private-vlan community ! ! Isolated VLAN: Connects all stub hosts to router. ! Remember - only one isolated vlan per primary VLAN. ! In our case, isolates R5 only. ! vlan 1055 private-vlan isolated ! ! Associating the primary with secondary’s ! vlan 1000 private-vlan association 1012,1034,1055
This step is needed is to group PVLANs into a shared domain and establish a formal association (for syntax checking and VLAN type verifications). Repeat the same operations on SW2, since VTP has been disabled.
Step 2:
Configure host ports and bind them to the respective isolated PVLANs. Note that a host port belongs to different VLANs at the same time: downstream primary and upstream secondary. Also, enable trunking between switches, to allow private VLANs traffic to pass between switches.
SW1: ! ! Community port (links R1 to R2 and “P”-ports) ! interface FastEthernet0/1 description == R1 switchport private-vlan host-association 1000 1012 switchport mode private-vlan host spanning-tree portfast ! ! Community port (links R3 to R4 and “P”-ports) ! interface FastEthernet0/3 description == R3 switchport private-vlan host-association 1000 1034 switchport mode private-vlan host spanning-tree portfast ! ! Isolated port (uses isolated VLAN to talk to “P”-ports) ! interface FastEthernet0/5 description == R5 switchport private-vlan host-association 1000 1055 switchport mode private-vlan host spanning-tree portfast ! ! Trunk port ! interface FastEthernet 0/13 switchport trunk encapsulation dot1q switchport mode trunk SW2: interface FastEthernet0/2 description == R2 switchport private-vlan host-association 1000 1012 switchport mode private-vlan host spanning-tree portfast ! interface FastEthernet0/4 description == R4 switchport private-vlan host-association 1000 1034 switchport mode private-vlan host spanning-tree portfast ! ! Trunk port ! interface FastEthernet 0/13 switchport trunk encapsulation dot1q switchport mode trunk Next, Verify the configuration on SW1: Rack1SW1#show vlan id 1012 VLAN Name Status Ports —- ——————————– ——— ——————————- 1012 VLAN1012 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1012 enet 101012 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1012 community Fa0/1 Rack1SW1#show vlan id 1034 VLAN Name Status Ports —- ——————————– ——— ——————————- 1034 VLAN1034 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1034 enet 101034 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1034 community Fa0/3 Rack1SW1#show vlan id 1055 VLAN Name Status Ports —- ——————————– ——— ——————————- 1055 VLAN1055 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1055 enet 101055 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1055 isolated Fa0/5 Rack1SW1#show interfaces fastEthernet 0/13 trunk Port Mode Encapsulation Status Native vlan Fa0/13 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/13 1-4094 Port Vlans allowed and active in management domain Fa0/13 1,1000,1012,1034,1055 Port Vlans in spanning tree forwarding state and not pruned Fa0/13 1,1000,1012,1034,1055 Verify on SW2: Rack1SW2#show vlan id 1000 VLAN Name Status Ports —- ——————————– ——— ——————————- 1000 VLAN1000 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1000 enet 101000 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1012 community Fa0/2, Fa0/6 1000 1034 community Fa0/4, Fa0/6 1000 1055 isolated Fa0/6 Rack1SW2#show vlan id 1012 VLAN Name Status Ports —- ——————————– ——— ——————————- 1012 VLAN1012 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1012 enet 101012 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1012 community Fa0/2, Fa0/6 Rack1SW2#show vlan id 1034 VLAN Name Status Ports —- ——————————– ——— ——————————- 1034 VLAN1034 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1034 enet 101034 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1034 community Fa0/4, Fa0/6 Rack1SW2#show vlan id 1055 VLAN Name Status Ports —- ——————————– ——— ——————————- 1055 VLAN1055 active Fa0/13 VLAN Type SAID MTU Parent RingNo BridgeNo Stp BrdgMode Trans1 Trans2 —- —– ———- —– —— —— ——– —- ——– —— —— 1055 enet 101055 1500 - - - - - 0 0 Remote SPAN VLAN —————- Disabled Primary Secondary Type Ports ——- ——— —————– —————————————— 1000 1055 isolated Fa0/6 Rack1SW2#show interface fastEthernet 0/13 trunk Port Mode Encapsulation Status Native vlan Fa0/13 desirable 802.1q trunking 1 Port Vlans allowed on trunk Fa0/13 1-4094 Port Vlans allowed and active in management domain Fa0/13 1,1000,1012,1034,1055 Port Vlans in spanning tree forwarding state and not pruned Fa0/13 1,1000,1012,1034,1055
Step 3:
Create a promiscuous port and configure downstream mappings. Here we add secondary VLANs for which traffic is received by this particular “P”-port. Primary VLAN is used to send traffic downstream to all “C” and “I” ports per their associations.
SW2: ! ! Promiscuous port, mapped to all secondary VLANs ! interface FastEthernet0/6 description == R6 switchport private-vlan mapping 1000 1012,1034,1055 switchport mode private-vlan promiscuous spanning-tree portfast Verify the promiscuous port configuration: Rack1SW2#show int fa 0/6 switch | beg private Administrative Mode: private-vlan promiscuous Operational Mode: private-vlan promiscuous Administrative Trunking Encapsulation: negotiate Operational Trunking Encapsulation: native Negotiation of Trunking: Off Access Mode VLAN: 1 (default) Trunking Native Mode VLAN: 1 (default) Administrative Native VLAN tagging: enabled Voice VLAN: none Administrative private-vlan host-association: none Administrative private-vlan mapping: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055) Administrative private-vlan trunk native VLAN: none Administrative private-vlan trunk Native VLAN tagging: enabled Administrative private-vlan trunk encapsulation: dot1q Administrative private-vlan trunk normal VLANs: none Administrative private-vlan trunk private VLANs: none Operational private-vlan: 1000 (VLAN1000) 1012 (VLAN1012) 1034 (VLAN1034) 1055 (VLAN1055)
If you need to configure an SVI on a switch to communicate with private VLAN members, you should add an interface corresponding to Primary VLAN only. Obviously that’s because all secondary VLANs are “subordinates” of primary. After an SVI has been created, you have to map the required secondary VLANs to the SVI (just like with a promiscuous port) in order to make communications possible. You may exclude some mappings from SVI interface, and limit it to communicating only with certain secondary VLANs.
SW1: ! ! SW1 SVI is mapped to all secondary VLANs ! interface Vlan 1000 ip address 10.0.0.7 255.255.255.0 private-vlan mapping 1012,1034,1055 SW2: ! ! SW2 SVI is mapped to 1012/1034 only, so it’s cant communicate with R5 ! interface Vlan1000 ip address 10.0.0.8 255.255.255.0 private-vlan mapping 1012,1034
Now to verify the configuration, configure R1-R6 interfaces in subnet “10.0.0.0/24” and ping broadcast addresses.
Rack1R1#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.2, 4 ms Reply to request 0 from 10.0.0.6, 4 ms Reply to request 0 from 10.0.0.8, 4 ms Rack1R3#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.4, 4 ms Reply to request 0 from 10.0.0.6, 4 ms Reply to request 0 from 10.0.0.8, 4 ms Rack1R5#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.7, 1 ms Reply to request 0 from 10.0.0.6, 1 ms Rack1R6#ping 10.0.0.255 repeat 1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds: Reply to request 0 from 10.0.0.1, 4 ms Reply to request 0 from 10.0.0.7, 4 ms Reply to request 0 from 10.0.0.2, 4 ms Reply to request 0 from 10.0.0.5, 4 ms Reply to request 0 from 10.0.0.3, 4 ms Reply to request 0 from 10.0.0.4, 4 ms Reply to request 0 from 10.0.0.8, 4 ms
Lastly, there is another feature, called protected port or “Private VLAN edge”. The feature is pretty basic and is available even on low-end Cisco switches. It allows isolating ports in the same VLAN. Specifically, all ports in a VLAN, marked as protected are prohibited from sending frames to each other (but still allowed to send frames to other (non-protected) ports within the same VLAN). Usually, ports configured as protected are also configured not to receive unknown unicast (frame with destination MAC address not in switch’s MAC table) and multicast frames flooding for added security.
Example:
interface range FastEthernet 0/1 - 2 switchport mode access switchport protected switchport block unicast switchport block multicast



Very useful info.
Thanks.
Excellent work.
The amazing part is that it is FREE for all people without asking any thing…..
I think soon this blog will have everything.
Where is my printer? I need to print this blog Damm…..
Amit Chopra
Great writeup Petr. I was thinking about doing a writeup while studying Private VLANs also because there is not much information on them. But I guess now I can chill and just read your post over and over again
[...] Private VLANs [...]
[...] Read more Leave a Reply [...]
[...] Internetwork Expert Blog- Petr revisits a very popular post about private VLANs: [...]
When enabling SVI on a switch to communicate with private VLAN members, should the “ip routing” command necessary or no?
[...] Private VLANs Revisited [...]
[...] Private VLANs revisited [...]
My Lab Exam coming soon.. I need that materials. Very good and clear. Thanks much.
People should not be alarmed when they see multicast and broadcast traffic on their isolated or community PVLAN ports from other PVLANs based on the same primary.
VTPv3 does carry the PVLAN associations (and VLAN database information for VLAN IDs > 1024 and MST vlan/instance mappings), but of course that’s kind of pointless since no one should be deploying new CatOS switches these days.
To Alexander
Thanks for the excellent point about VTPv3! Even though VTPv3 adds truly “opaque” information distirbution, I didnt mention the new version in the post since it’s not widely deployed/used and probably would not be
Even if ported to IOS, VTP concept in general is incompatible with modern enterprise network design trend, which avoids large L2 domains.
However, Im looking forward to see the emerging Ethernet OAM and further development of EVCs and Metro Ethernet technologis in general. This is where “truly opaque” information distribution protocol may become useful.
[...] is looking for some real information on private vlans, please check out the Cisco Documentation or Internetworkexpert’s blog on private vlans No Comments so far Leave a comment RSS feed for comments on this post. TrackBack URI [...]
[...] Anywho, if anyone is looking for some real information on private vlans, please check out the Cisco Documentation or Internetworkexpert’s blog on private vlans [...]