Configuring Private VLANs on Cisco
- Tutorial
In this article, we will consider such an interesting technology, in my opinion, as Private VLANs in theory and practice.
First, let's recall what VLANs are. VLAN - a separate subnet, a separate Broadcast domain, is used for logical network segmentation, restriction of the broadcast domain, security, etc.
Usually the network is divided into VLANs, then using a router-on-the-stick or a multilevel switch (any device of level 3), routing is enabled (all traffic is allowed), and then, using access control lists, it is registered to whom, with whom and by what the protocol is allowed to “communicate” (or traffic control is applied based on the requirements of your organization’s security policy, as would be written in the Cisco tutorial).
But what to do when, for example, the network is already divided, segmented, but there is a need to isolate the servers or host groups from each other?
Cisco, like other vendors, has additional tools to help limit traffic forwarding between hosts located on the same subnet or to control traffic within the VLAN. For this, Private VLANs, VLAN access list and protected ports are most often used.
It should be noted that Private VLANs on Cisco are supported on Nexus models, as well as Catalyst since 3560 and older .
On switches of younger models there is such a thing as private vlan edge . It is configured very simply - from the interface configuration mode, we write the command (config-if) #switchport protected, as a result, the hosts connected to these ports will be isolated from each other at level 2 (i.e. physically they will be connected to the same switch, be on the same subnet, but will not “see” each other, while all other hosts will “see”). One of the drawbacks of this mechanism is that it has a local value for the switch and does not scale. (Ie if we connect switch A and switch B with a trunk, for example, then protected port of switch A can “see” the protected port of the switch B)
Let us dwell in more detail on private VLANs. The main goal of the article is to teach you how to configure private VLANs, understand the terminology, and also get a general idea of where to use them.
In the first example, the network is already divided into VLANs, but suddenly host isolation was required, what should I do? You will say that everything is very simple: we remove the hosts that need to be isolated in separate VLANs, enable routing, and use the access control lists to isolate them from each other. To do this, just create a few more subnets and that's it. But, suddenly you work in an organization where a very strict hierarchy of IP addressing and just getting another private subnet is not so easy or you don’t have free VLANs?
Fig. - Server isolation in DMZ.
You work as a provider and provide web hosting services for a large number of clients, you put web servers on the same network, and it turns out that there is no isolation, they all can “hear” each other’s broadcasts, that is, transmit traffic without filtering through the firewall. If a hacker can get to one of the servers, then he can deploy an attack on all servers, “put” the entire server farm. And, of course, customers want to isolate their servers from each other. PVLANs are especially relevant for providers that provide layer 2 connections as a type of service for client separation. Of course, the client doesn’t want his broadcast to go to client B. You understand what kind of security hole is opening here. The traditional way out of this situation by adding a new VLAN is not suitable here (the method is one VLAN per client), we “rest” on the scalability of the maximum number of VLANs 4094 minus reserved ones. The second problem, because VLAN is a separate subnet, you need to deal with subnetting and throw 2 more addresses to each subnet (subnet and broadcast) is a pity, since these are “white” addresses :).
In these situations, private VLANs come to the rescue .
A bit of terminology. Private VLANs are divided into:
Ports are divided into:
Only one isolated vlan can be bound to one promiscuous port. If you want several isolated vlan, then a separate promiscuous port must be associated with each vlan.
Usually only one isolated vlan is created, no matter how many hosts there are, they will not see each other anyway.
Unlike isolated VLANs, multiple community VLANs can be mapped to one promiscuous port.
Consider the following topology:
- All devices are on the same subnet 10.0.0.0/24 VLAN 10.
- R4 and R5 must be isolated from each other and R2, R3 - i.e. should only have access to the router interface.
- R2 and R3 should be isolated from R4, R5, but see each other and the router.
First, create 2 minor VLANs, 101 community VLANs and 102 isolated VLANs. We will make VLAN 10 the main one and bind the secondary ones to it (the order of command input does not matter).
Check:
Next, we must associate the ports with VLANs.
From the interface configuration mode, we first make it private vlan host (we tell it that it is an unusual port), with the second command we bind it to isolated and primary VLANs
By analogy, we set up the interface fa1 / 0/4
We write the same thing on fa1 / 0/9 - first we tell him that he is a private vlan host and so that he understands that he belongs to community vlan 102, we bind him to it, and also do not forget to bind him to the main VLANу.
Similarly configure fa1 / 0/9
The fa2 / 0/2 interface, since we want all the hosts to “see” it and “see” everyone, set the mode to promiscuous and, as a rule, tie it to the main and all secondary VLANs.
Checking the port association:
The next step is optional, we create an L3 SVI to verify that isolated and community hosts can “see” it like the promiscuous port.
And now the fun part is how it all works .
Let's look at the MAC address table on the switch; it looks unusual. It turns out that the host MAC addresses on the ports from which they were received are simultaneously associated with primary and secondary VLANs!
Why can't the R4 and R5 hosts in isolated vlan 102 see anything except the router interface? Note that the MAC addresses of these hosts within 102 of the isolated vlan switch are marked as BLOCKED, while the MAC address of the promiscuous interface of the router within vlan 102 is the same as normal DYNAMIC.
Now let's see why the router’s interface, marked as promiscuous can “communicate” with all interfaces, the fact is that it can see them through primary VLAN 10 (the first 5 lines in the MAC address table).
In the next article, we will consider the intricacies of scalability of private VLANs, both between switches supporting this technology, and through / through ordinary switches that do not even know such a thing as a private VLAN (no, there is no double tagging of the frame) and types of “special” trunks .
First, let's recall what VLANs are. VLAN - a separate subnet, a separate Broadcast domain, is used for logical network segmentation, restriction of the broadcast domain, security, etc.
Usually the network is divided into VLANs, then using a router-on-the-stick or a multilevel switch (any device of level 3), routing is enabled (all traffic is allowed), and then, using access control lists, it is registered to whom, with whom and by what the protocol is allowed to “communicate” (or traffic control is applied based on the requirements of your organization’s security policy, as would be written in the Cisco tutorial).
But what to do when, for example, the network is already divided, segmented, but there is a need to isolate the servers or host groups from each other?
Cisco, like other vendors, has additional tools to help limit traffic forwarding between hosts located on the same subnet or to control traffic within the VLAN. For this, Private VLANs, VLAN access list and protected ports are most often used.
It should be noted that Private VLANs on Cisco are supported on Nexus models, as well as Catalyst since 3560 and older .
The first example.
On switches of younger models there is such a thing as private vlan edge . It is configured very simply - from the interface configuration mode, we write the command (config-if) #switchport protected, as a result, the hosts connected to these ports will be isolated from each other at level 2 (i.e. physically they will be connected to the same switch, be on the same subnet, but will not “see” each other, while all other hosts will “see”). One of the drawbacks of this mechanism is that it has a local value for the switch and does not scale. (Ie if we connect switch A and switch B with a trunk, for example, then protected port of switch A can “see” the protected port of the switch B)
Let us dwell in more detail on private VLANs. The main goal of the article is to teach you how to configure private VLANs, understand the terminology, and also get a general idea of where to use them.
Second example.
In the first example, the network is already divided into VLANs, but suddenly host isolation was required, what should I do? You will say that everything is very simple: we remove the hosts that need to be isolated in separate VLANs, enable routing, and use the access control lists to isolate them from each other. To do this, just create a few more subnets and that's it. But, suddenly you work in an organization where a very strict hierarchy of IP addressing and just getting another private subnet is not so easy or you don’t have free VLANs?
| VLAN Support Matrix for Catalyst Swithes | ||
| Type of switch | Maximum No. of VLANs | VLAN IDs Range |
| Catalyst 2940 | four | 1-1005 |
| Catalyst 2960/2955 | 250 | 1-4094. |
| Catalyst 2960 | 255 | 1-4094. |
| Catalyst 2970/2550/3560/3750 | 1005 | 1-4094. |
| Catalyst 2848G / 2980G / 4000/4500 | 4094 | 1-4094. |
| Catalyst 6500 | 4094 | 1-4094. |
Fig. - Server isolation in DMZ.
The third example.
You work as a provider and provide web hosting services for a large number of clients, you put web servers on the same network, and it turns out that there is no isolation, they all can “hear” each other’s broadcasts, that is, transmit traffic without filtering through the firewall. If a hacker can get to one of the servers, then he can deploy an attack on all servers, “put” the entire server farm. And, of course, customers want to isolate their servers from each other. PVLANs are especially relevant for providers that provide layer 2 connections as a type of service for client separation. Of course, the client doesn’t want his broadcast to go to client B. You understand what kind of security hole is opening here. The traditional way out of this situation by adding a new VLAN is not suitable here (the method is one VLAN per client), we “rest” on the scalability of the maximum number of VLANs 4094 minus reserved ones. The second problem, because VLAN is a separate subnet, you need to deal with subnetting and throw 2 more addresses to each subnet (subnet and broadcast) is a pity, since these are “white” addresses :).
In these situations, private VLANs come to the rescue .
A bit of terminology. Private VLANs are divided into:
- Primary - Primary, Main VLAN
- Secondary - secondary VLANs (there are 2 types of isolated and community), all of them must belong to primary VLAN
Ports are divided into:
- Promiscuous - this port “sees” everything and it “sees” everyone, should be tied to the main and all secondary VLANs.
- Private vlan host may belong to:
- Isolated VLAN- “sees” only a promiscuous port, does not “see” other ports even in its isolated vlan. Must be tied to its isolated VLAN and primary VLAN
- Community VLAN- “sees” only the ports in the given community vlan to which it belongs and the promiscuous port. Must be tied to its community VLAN and primary VLAN.
General rules
Only one isolated vlan can be bound to one promiscuous port. If you want several isolated vlan, then a separate promiscuous port must be associated with each vlan.
Usually only one isolated vlan is created, no matter how many hosts there are, they will not see each other anyway.
Unlike isolated VLANs, multiple community VLANs can be mapped to one promiscuous port.
Consider the following topology:
- All devices are on the same subnet 10.0.0.0/24 VLAN 10.
- R4 and R5 must be isolated from each other and R2, R3 - i.e. should only have access to the router interface.
- R2 and R3 should be isolated from R4, R5, but see each other and the router.
First, create 2 minor VLANs, 101 community VLANs and 102 isolated VLANs. We will make VLAN 10 the main one and bind the secondary ones to it (the order of command input does not matter).
SW1 (config)#
vlan 101
private-vlan community
!
vlan 102
private-vlan isolated
!
vlan 10
private-vlan primary
private-vlan association 101-102
Check:
SW1#sh vlan private-vlan
Primary Secondary Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
10 101 community
10 102 isolated
Next, we must associate the ports with VLANs.
From the interface configuration mode, we first make it private vlan host (we tell it that it is an unusual port), with the second command we bind it to isolated and primary VLANs
interface FastEthernet1/0/11
description SW1 <-> R2
switchport private-vlan host-association 10 101
switchport mode private-vlan host
spanning-tree portfast
end
By analogy, we set up the interface fa1 / 0/4
interface FastEthernet1/0/4
description SW1 <-> R3
switchport private-vlan host-association 10 101
switchport mode private-vlan host
spanning-tree portfast
end
We write the same thing on fa1 / 0/9 - first we tell him that he is a private vlan host and so that he understands that he belongs to community vlan 102, we bind him to it, and also do not forget to bind him to the main VLANу.
interface FastEthernet2/0/2
description SW1 <-> R6
switchport private-vlan mapping 10 101-102
switchport mode private-vlan promiscuous
Similarly configure fa1 / 0/9
interface FastEthernet2/0/11
description SW1 <-> R5
switchport private-vlan host-association 10 102
switchport mode private-vlan host
spanning-tree portfast
The fa2 / 0/2 interface, since we want all the hosts to “see” it and “see” everyone, set the mode to promiscuous and, as a rule, tie it to the main and all secondary VLANs.
interface FastEthernet2/0/2
description SW1 <-> R6
switchport private-vlan mapping 10 101-102
switchport mode private-vlan promiscuous
Checking the port association:
SW1#sh vlan private-vlan
Primary Secondary Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
10 101 community Fa1/0/4, Fa1/0/11, Fa2/0/2
10 102 isolated Fa1/0/9, Fa2/0/2, Fa2/0/11
The next step is optional, we create an L3 SVI to verify that isolated and community hosts can “see” it like the promiscuous port.
SW#sh run int vlan 10 | beg int
interface Vlan10
ip address 10.0.0.1 255.255.255.0
private-vlan mapping 101-102
end
SW#sh int vlan 10 private-vlan mapping
Interface Secondary VLANs
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
vlan 10 101,102
SW1#And now the fun part is how it all works .
Let's look at the MAC address table on the switch; it looks unusual. It turns out that the host MAC addresses on the ports from which they were received are simultaneously associated with primary and secondary VLANs!
Why can't the R4 and R5 hosts in isolated vlan 102 see anything except the router interface? Note that the MAC addresses of these hosts within 102 of the isolated vlan switch are marked as BLOCKED, while the MAC address of the promiscuous interface of the router within vlan 102 is the same as normal DYNAMIC.
Now let's see why the router’s interface, marked as promiscuous can “communicate” with all interfaces, the fact is that it can see them through primary VLAN 10 (the first 5 lines in the MAC address table).
SW#sh arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.0.0.2 8 0014.a925.72a0 ARPA Vlan10 pv 101
Internet 10.0.0.3 5 0014.a925.4cd8 ARPA Vlan10 pv 101
Internet 10.0.0.1 - 0014.a98c.87c1 ARPA Vlan10
Internet 10.0.0.6 70 0014.a909.78d1 ARPA Vlan10
Internet 10.0.0.4 4 0014.a909.7870 ARPA Vlan10 pv 102
Internet 10.0.0.5 4 0014.a925.6460 ARPA Vlan10 pv 102
SW#sh mac-address-table
Mac Address Table
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Vlan Mac Address Type Ports
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
All 0100.0ccc.cccc STATIC CPU
....
10 0014.a909.7870 DYNAMIC pv Fa1/0/9
10 0014.a909.78d1 DYNAMIC Fa2/0/2
10 0014.a925.4cd8 DYNAMIC pv Fa1/0/4
10 0014.a925.6460 DYNAMIC pv Fa2/0/11
10 0014.a925.72a0 DYNAMIC pv Fa1/0/11
101 0014.a909.78d1 DYNAMIC pv Fa2/0/2
101 0014.a925.4cd8 DYNAMIC Fa1/0/4
101 0014.a925.72a0 DYNAMIC Fa1/0/11
102 0014.a909.7870 BLOCKED Fa1/0/9
102 0014.a909.78d1 DYNAMIC pv Fa2/0/2
102 0014.a925.6460 BLOCKED Fa2/0/11
SW1#In the next article, we will consider the intricacies of scalability of private VLANs, both between switches supporting this technology, and through / through ordinary switches that do not even know such a thing as a private VLAN (no, there is no double tagging of the frame) and types of “special” trunks .