Concepts and usage

To understand the concept behind PVLANs, the concept of regular VLANs need to be understood.

VLANs are a simple way to create different Ethernet segments on the top on one unique physical infrastructure. The main goal was to virtualize networks so that the same network infrastructure would be virtually able to supports multiple networks at Layer 2. The different hosts that are member of one particular VLANs will not be able to communicate directly with other hosts sitting on another VLANs.

“Directly” means that these hosts will be forced to go through some Layer 3 devices like a router, a firewall or anything able to do routing. These hosts will not be able to ARP each other and they have to go through their default gateway to communicate with other VLANs.

From a security standpoint, VLANs are a way to implement “choke points”. One VLANs that wants to communicate with another can be filtered or controlled at the Layer 3 devices.

Best practices for VLANs is to use one IP subnet per VLAN ID to allow interVLAN communication without the need to call for NAT.

Now let’s take a case where you are designing a backup infrastructure for your hosting network. You may have different departments of your company here (or different customers if you are an hosting provider). Each of these departments have multiple hosts and they required that other departments have no direct communication with them (or imagine you’re a provider, you obviously do not want direct communication possible between them). Then what are your options ?

Technically you can have multiple VLANs with multiple IP subnets. I think on some cases you may have different VLAN with the same IP subnets using NAT also, but it seems a pretty crappy design.

Let’s suppose you choose the first option. Now imagine you have 5 different department for which you need to provide backup (on a different scale imagine you have 500 customers ?). You need 5 (or 500) different VLANs and because you’re like me you like best practices, you also need 5 IP subnets (or 500 !).

That’s where PVLANs kicks in.

PVLANs

PVLANs introduce some new concepts. The first one is the concept of primary and secondary VLANs. Another terminology is to talk about parent and child VLANs.

A primary VLAN is a VLAN that will be tied to one or multiple secondary VLANs. From a Layer 3 perspective, the primary VLAN is the one that “owns” the IP subnet.

A secondary VLAN can be of two type : Isolated or Community. We will see later that a third VLAN type exists within IOS 15.0, the twoway-community.

Isolated PVLANs

An isolated secondary VLAN is a VLAN where member of the same VLAN cannot communicate with each other. With an isolated VLAN you can have, for example, 10 hosts sitting on the same VLAN ID and not be able to talk directly to each other.

Community PVLANs

A community secondary VLAN is a VLAN where members of the same secondary VLAN can communicate with each others but they will not be able to communicate with other secondary community VLANs or Isolated VLANs

Primary and Secondary VLANs need to be configured as follow. In the example, the VLAN 100 is a community vlan and vlan 200 is an isolated VLAN. Both are mapped to their primary VLAN.

vlan 10
  private-vlan primary
  private-vlan association 100,200
!
  vlan 100
  private-vlan community
!
vlan 200
  private-vlan isolated
!

The configuration can be check as follow :

SW1#sh vlan private-vlan

 

Primary Secondary Type              Ports

——- ——— —————– ————————-

10      100       community

10      200       isolated

 

Then, ports need to be associated to reflect their PVLAN status, here F0/2 is configured as a port connecting to an end-host which will be integrated in the primary VLAN 10 and the community VLAN 100.

interface FastEthernet0/2

 switchport private-vlan host-association 10 100

 switchport mode private-vlan host

end

 

Of course isolated and communities can be used together with one restriction though, there is only one isolated VLAN allowed per primary VLAN (as it has no sense to have multiple isolated VLAN inside the same primary anyway…).

Promiscuous Ports

One of the major benefit of PVLAN is that the IP subnet belongs to the primary VLANs.

The secondary VLANs can all sit into the same IP subnets and the rules between community and isolated will continue to apply as it’s a layer 2 feature.

These VLANs still may to be able to communicate with devices that will provide a common service. Promiscuous ports are the ports that can be reached by any isolated/community VLANs. Typically this is used to provide access to the default gateway.

Let’s continue the example, we have R2 and R4 connected to SW1. R2 and R4 or both in the community VLANs 100 which mean they can communicate together at Layer 2.

We also have R5 connected to SW2, R5 is located in the isolated VLAN 200 so it can’t communicate with no one.

Now, each of these devices need to reach their default gateway BB1 which is connected to SW1. We need to configured a promiscuous port on SW1 to accomplish this.

Fist let’s check the current PVLAN configuration, note that the trunk between SW1 and SW2 is a regular trunk :

SW1#sh vlan private-vlan

 

Primary Secondary Type              Ports

——- ——— —————– ————————-

10      100       community         Fa0/2, Fa0/4

10      200       isolated

 

R2 and R4 are connected to F0/2 and F0/4 so let’s try a ping from R4 to the broadcast address to check whose can reply :

R4#ping 10.0.0.255

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

 

Reply to request 0 from 10.0.0.2, 4 ms

Reply to request 1 from 10.0.0.2, 1 ms

Reply to request 2 from 10.0.0.2, 1 ms

Reply to request 3 from 10.0.0.2, 1 ms 

Only R2 is able to communicate with R4 

Now we try to ping the gateway for these VLANs with is BB1 10.0.0.254, at that point BB1 is inside VLAN 10.

R4#ping 10.0.0.254

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.254, timeout is 2 seconds:

…..

Success rate is 0 percent (0/5)

None of the devices can ping it.

The configuration of the promiscuous port to push is the following :

interface FastEthernet0/10

 switchport private-vlan mapping 10 100,200

 switchport mode private-vlan promiscuous

end

 

The port is configured as private-vlan promiscuous and a mapping is set up. This indicates to the port that the primary VLAN associated is 10 and the secondary VLANs allowed to be mapped are 100 and 200.

 

From a technical point of view, the frames which will go through the promiscuous port will not be tagged because it will be treated like an access port but the only VLAN which will be allowed to go through are :

• VLAN 100 the community VLAN
• VLAN 200 the isolated VLAN
• The primary VLAN will not be able to go through this interface

Now let’s test who reply to a broadcast ping from the gateway !

 

BB1#ping 10.0.0.255

 

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.255, timeout is 2 seconds:

 

Reply to request 0 from 10.0.0.4, 1 ms

Reply to request 0 from 10.0.0.5, 1 ms

Reply to request 0 from 10.0.0.2, 1 ms

 

So now, our isolated Layer 2 devices can still reach their common gateway and live their happy lives.

 

But what is we want to do the inter-VLAN routing directly on the layer3 switch instead of using a separated layer 3 device ?

 

This can also be accomplished by making the mapping on the SVI :

 

interface Vlan10

 ip address 10.0.0.254 255.255.255.0

 private-vlan mapping 100,200

end 

 

 

The new PVLANs on Nexus platform and 4500/4900 series

The configuration shown above applies on Catalyst Series and can also be applied on Nexus series. But there is one restriction one this configuration appears : What if multiple primary VLANs needs to go through the promiscuous port ?

In Catalyst 4500 series and Nexus series, a new features called Promiscuous Trunk can be configured to resolve this issue. With a Promiscuous Trunk port you now have the option to have multiple Primary/Secondary mapping onto the same trunk.

In the above example, we have now two primary VLANs that need to go through the interface connective SW1 and BB1, the promiscuous trunk should be configured here along with the mapping.

Of course has you will now need to differentiate between the two primary VLANs, the frames going out of SW1 to BB1 will be tagged with their primary VLAN tag and by so, BB1 needs to be configured to recognized 802.1q tags.