The concepts behind Private VLANs are in fact rather simple, but it is quite easy to get discombobulated in the details. In their simplest form, PVLANs can dissociate ports within a PVLAN as if they were on separate VLANS, but still allow them to communicate with a common default gateway. i.e. these ports share a subnet, but can be prevented from communicating to each other.
In order to accomplish this we split our VLAN into sub-VLANS and classify these into one of three groups depending on how we want to segregate traffic. These groups are as follows.
- Promiscuous / P-port: This port type is allowed to send and receive from any other port on the VLAN. Typically this would be connected to a router.
- Isolated/ I-port: This type of port is only allowed to communicate with promiscuous ports, they are not only isolated from community ports, but other isolated ports. You commonly see these ports connecting to hosts.
- Community / C-port: Can only communicate with other C-ports and P-ports.
In our example we’re using VLAN 100 as our primary VLAN. Our host machines will be setup on VLAN 101 which will be configured as Isolated. Our servers will be configured as Community ports on VLAN 102. Essentially, once established, VLAN 100 will forward frames from P-ports to I and C-ports. VLAN 101 and 102 are considered secondary VLANs.
Our first steps here are to configure the primary and secondary vlans. Each vlan is configured using the VLAN configuration command private-vlan [type]. Once configured, we head back to the primary VLAN and bind the secondary vlans to it using the private-vlan association [vlan list] command.
SW1(config)#vlan 100 SW1(config-vlan)#private-vlan primary SW1(config-vlan)#vlan 101 SW1(config-vlan)#private-vlan community SW1(config-vlan)#vlan 102 SW1(config-vlan)#private-vlan isolated SW1(config-vlan)#vlan 100 SW1(config-vlan)#private-vlan association 101,102
Now, we need to bind our switch ports to their respective PVLANs. Please note that a host port belongs to multiple VLANs at the same time: downstream primary and upstream (isloated/community/promiscuous) secondary.
SW1(config)#interface fa0/10 SW1(config-if)#switchport mode private-vlan host SW1(config-if)#switchport private-vlan host-association 100 101 SW1(config-if)#interface fa0/11 SW1(config-if)#switchport mode private-vlan host SW1(config-if)#switchport private-vlan host-association 100 101 SW1(config-if)#interface fa0/20 SW1(config-if)#switchport mode private-vlan host SW1(config-if)#switchport private-vlan host-association 100 102 SW1(config-if)#interface fa0/21 SW1(config-if)#switchport mode private-vlan host SW1(config-if)#switchport private-vlan host-association 100 102 SW1(config-if)#interface fa0/1 SW1(config-if)#switchport mode private-vlan promiscuous SW1(config-if)#switchport private-vlan mapping 100 add 101,102
And finally our verification.
SW1#sh vlan private-vlan Primary Secondary Type Ports ------- --------- ----------------- --------------------- 100 101 isolated Fa0/10, Fa0/11, Fa0/1 100 102 community Fa0/20, Fa0/21, Fa0/1 SW1#sh vlan private-vlan type Vlan Type ---- ----------------- 100 primary 101 isolated 102 community
You can do trucking with PVLANS, the secondary VLAN numbers would be used to tag the frames, just as with a regular VLAN. Although, you would need to configure matching PVLAN settings on each switch. Using VTP is highly debated as is, adding Private VLANS just adds to the mess.
If you do attempt to use VTP, be aware that VTPv2 is incompatible. VTPv3 has been updated to be compatible with Private VLANs.
If you need to configure an SVI, you should add an interface corresponding to Primary VLAN only. After createing the SVI, you will have to map the secondary VLANs to it. You can exclude some mappings from the SVI interface, in order to limit it’s communications with those secondary VLANs. An example configuration would look something like this.
interface vlan 100 ip address 10.1.0.1 255.255.255.0 private-vlan mapping 101,102
There is one more feature I would like to discuss that happens to be available even on lower-end Cisco switches called protected port . While this feature is rather basic, it is rather effective at isolating ports in the same VLAN. Any ports, within a VLAN, marked as protected are prohibited from sending frames to each other, but are still allowed to send frames to non-protected ports (within the same VLAN). Typically, ports configured as protected are also configured not to block unknown unicast and multicast frames flooding for added security. An example of this configuration is as follows.
interface range FastEthernet 0/30 - 39 switchport mode access switchport protected switchport block unicast switchport block multicast
Network engineer turned management currently servicing the enterprise data center market. I started working on networks in the ’90s and still feel like that was just a few years ago. Jack of all trades, master of none; I love to learn about everything. Feel free to ask me about photography, woodworking, nhra, watches, or even networking! — For feedback, please leave a comment on the article in question, and I’ll respond as soon as I can. For everything else including fan mail or death threats, contact me via twitter.