The concept of a VLAN is one of the very first concepts any network engineer is required to learn. Private VLANs, however, are a much less understood topic. Though the private VLAN feature is more complex than a simple VLAN, it is like any other feature – as long as you know how it works and why it works, it is not that difficult.
A VLAN allows a network administrator to create a grouping of ports across multiple devices that share the same broadcast domain. Hosts that are not in the same broadcast domain cannot talk with each other at layer 2. This concept of segregating and limiting communication is an important one to grasp if you want private VLANs to make any sense. The reason for this is the private VLAN feature just extends the concept of segregating hosts beyond what you are able to do with traditional VLANs.
To give a high-level overview of private VLANs, we can look into a fairly common business requirement that might require you to use the private VLAN feature. Let’s say you have a bunch of machines sitting on a shop floor in a manufacturing facility. All of these machines are currently in the same broadcast domain – and all of those machines have IPs in the same 10.1.2.0/24 subnet. These machines are absolutely critical to your business’ ability to make a given product. What would happen if one of those machines picked up a virus from the Internet, which is unfortunately easy to do. It is a potential that this virus could almost instantly spread to all machines on that same broadcast domain and cause massive problems. In theory, as long as you have secured intersubnet communication correctly, this virus should be limited to hosts on the same broadcast domain. But can you extend protection beyond that, so the virus would be confined to only the compromised host? Well, yes – there are ways to do that. You could put every single host in their own broadcast domain with their own subnet and use ACLs or some other stateful filtering mechanism to control communication between the hosts. But this approach would be severely limited in its ability to scale, and would require huge amounts of time to administer and control. The private VLAN feature provides a much more elegant solution. Basically, private VLANs allow you to restrict communication between hosts in the same broadcast domain in a way that is manageable and reasonably scalable. As we explore the various terms, port types, etc., in the following sections, just remember what the private VLAN feature is attempting to do – that is to control communication between hosts in the same broadcast domain.
Before we proceed further, we need to break down a couple suppositions a lot of people have when learning about the private VLAN feature that creates a lot of confusion. First off, there is no single private VLAN. When you say private VLANs, you are really referring to a set of VLANs. This set of VLANs interacts with one another to make up a private VLAN domain. Keep repeating this to yourself, as it is very, very important. Private VLANs is a feature on a switch, not a single VLAN. The name really is sort of misleading here, as you would think it refers to a single VLAN.
Each VLAN inside of a private VLAN domain can be either a primary VLAN or a secondary VLAN. Each private VLAN domain can have only a single primary VLAN. However, you can have multiple secondary VLANs in a private VLAN domain. There are multiple types of secondary VLANs.
Every secondary VLAN is able to communicate with the primary VLAN. What the private VLAN feature restricts is how communication occurs inside of and between the secondary VLANs of a private VLAN domain. What communication can occur depends on the type of secondary VLAN it is. There are two types of secondary VLANs – isolated and community. Hosts in secondary VLANs designated as isolated cannot talk to other hosts in the same isolated secondary VLAN. On the other hand, hosts in secondary VLANs designated as community can communicate with other hosts in the same secondary community VLAN within the private VLAN domain. A single private VLAN domain can have multiple community VLANs. Hosts in one secondary community VLAN cannot communicate with hosts in a different secondary community VLAN. You are only allowed to have a single isolated VLAN. And in reality, this makes sense because there aren’t many scenarios where you would want more than one of those anyway. Hosts in isolated VLANs are as isolated as they are going to get – putting them in different isolated VLANs isn’t going to further limit or control who they can communicate with.
If you are thinking that we are using the term private VLAN domain a lot in this article – we are! Remember, there is not a single private VLAN. There are a group of VLANs associated together that form the private VLAN domain.
Figure 1 (From Cisco Site)
The primary VLAN within a private VLAN domain can communicate with hosts both in isolated and community VLANs. The primary VLAN is usually the VLAN that provides connectivity to the upstream network. You can think of the primary VLAN as the point of entry and exit to and from the private VLAN domain. Anybody can walk into and out of a private VLAN building, but once you’re inside, you have to follow the rules of the house as to what rooms you are allowed to go into (i.e. secondary VLANs) and who you are allowed to communicate with within each room type.
So now that we understand about the types of VLANs within a private VLAN domain and the attributes each type has, we can look at what the port types are within a private VLAN domain. It is important to understand that every port that is a member of a VLAN in a private VLAN domain will be one of three types – promiscuous, isolated, or community. Each VLAN type that makes up a private VLAN domain (isolated, community, and primary) has a port type that is generally associated with it. Ports that are in a primary VLAN are promiscuous ports. Ports that are in a secondary VLAN are community ports. Ports that are part of an isolated VLAN are isolated ports.
In the configuration, the VLANs that make up a private VLAN domain are associated with one another at the VLAN level, port level, and SVI level. We will look more at exactly how and where this is done when we configure private VLANs later on.
A private VLAN domain is not limited to a single switch. You can span a private VLAN domain across multiple switches. You just have to ensure that the VLANs making up the private VLAN domain are designated correctly, and that all your associations are correct on each switch. Keep in mind that this article focuses on the Cisco implementation of the private VLAN feature, so you may have trouble getting it to work when a non-Cisco switch is in the path.
Figure 2 (From Cisco Site)
Now that we understand the basic overview of private VLANs, we can look at some of the caveats they have. Unfortunately, there always seems to be a lot of those. First, let’s look at how private VLANs relate to VTP. VTP, in case you do not know already, refers to Virtual Trunking Protocol. To put it simply, VTP allows you to create a VLAN on one switch, and have that VLAN be automatically created on all switches that are in the same VTP domain. This works great for normal VLANs, but becomes a bit more complicated when the VLANs you are creating are the “special” VLANs that make up a private VLAN domain. Most of the articles floating around relating to private VLANs will tell you to set your VTP mode to transparent before configuring private VLANs – since VTP does not support private VLANs. VTP transparent mode is really just disabling VTP. This was 100 percent correct until recently. Most Cisco code versions now support VTP version 3 (aka VTPv3). VTPv3 now supports the private VLAN feature– meaning when you create a VLAN in a private VLAN domain, that VLAN’s special private VLAN attributes are also disseminated to other switches in that VTPv3 domain.
Another thing to keep in mind is the private VLAN feature was designed to control communication at layer 2 between hosts in the same broadcast domain. It has no inherent ability to control traffic at layer 3. In other words, just because a host is in an isolated secondary VLAN in one private VLAN domain does not mean that host has any restrictions as to which host it can communicate with in a different broadcast domain. If that is what you need to accomplish, you will need to use some other mechanism, such as a firewall or access list.
One other critical thing to remember is that in addition to the private VLAN feature changing how hosts communicate via unicast; it also modifies how they communicate for broadcasts and multicasts. Broadcasts or multicasts from isolated ports are only propagated out of promiscuous ports and trunk ports. The broadcast or multicast from one isolated port is not sent to another isolated port. The same broadcast or multicast from a community port is flooded to all other community ports in the same secondary community VLAN. Broadcasts or multicasts coming from ports in a primary VLAN within the private VLAN domain are flooded to all ports in all secondary VLANs.
Now that we understand the workings of a basic private VLAN domain, we can start to look at how to configure it. The better you understand how private VLANs work and the theory behind them, the easier it will be to configure them. Rather than trying to memorize the steps, you should focus on understanding the components of the private VLAN feature. For the purposes of this configuration example, we will assume you are not running VTP version 3 either because your devices don’t support it, or because you don’t wish to use VTP at all.
So first, disable VTP on all switches you wish to be in a private VLAN domain by setting them to VTP transparent mode. Next, you create the VLANs that make up the private VLAN domain. We will assume there are 4 VLANs – one primary, two secondary, and one isolated.
Then, you associate the primary VLAN with all of the secondary VLANs.
This needs to be done on each switch in the private VLAN domain separately. If you just create the VLANs as “normal” VLANs on one switch, the private VLAN feature will not work as expected. Also, you are required to trunk the VLANs making up the private VLAN domain to wherever they need to go just as you would need to for normal VLANs.
Now, you configure your host ports. You place a port in a given secondary VLAN by setting the host-association on that port, and then specifying the switchport mode on that port as being private-VLAN host. The first VLAN in the host-association command is the primary VLAN in the private VLAN domain, and the second VLAN in the command is the secondary VLAN (community or isolated) you wish that host to be a part of. Note that regardless of what type of secondary VLAN is used on an end-host port, you still set the switchport mode to be private-VLAN host.
Next, you create your promiscuous port. This is done by setting the switchport private VLAN mode to be promiscuous and creating the mapping. The mapping identifies the primary VLAN and then all the secondary VLANs that the port is allowed to talk to.
Finally, you configure a SVI for the primary VLAN. Do not do this for secondary VLANs. Remember, even though there are multiple VLANs in the private VLAN domain, all of them share a single common broadcast domain.
When all this is done, you can verify your configurations with several helpful show commands. One very helpful command is the “show vlan private-vlan” command. The output below is just an example of what you might see – not an exact replication of the commands used above. Of course, the ultimate test of whether the private VLAN domain was configured successfully is that you have connectivity where you expect it.
In summary, the private VLAN feature gives a network administrator incredible granular control of communication between hosts in the same broadcast domain. It really isn’t all that scary of a feature or complex of a configuration, and can help address some pretty common business requirements in today’s modern networks.