Private VLANs on Trunks and SVIs

This article examines the function of private VLANs across 802.1Q trunk links (not to be confused with configuring private VLAN trunk ports, which are supported only on the Catalyst 4500 and 6500 series) and how they can be mapped to SVIs for multilayer switching. For a review of private VLAN fundamentals, check out Basic Private VLAN Configuration. We'll be using the example topology below as a reference.

Our private VLAN configuration on S1 and S2 looks like this (if you're following along in a lab, note that the community VLANs 101 and 102 must be created before being associated with the primary VLAN 100):

vlan 100
  private-vlan primary
  private-vlan association 101-102
!
vlan 101
  private-vlan community
!
vlan 102
  private-vlan community

Here are the physical interface configurations per switch for your reference:

S1

interface FastEthernet0/1
 switchport private-vlan mapping 100 101-102
 switchport mode private-vlan promiscuous
!
interface FastEthernet0/3
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface FastEthernet0/5
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface FastEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

S2

interface GigabitEthernet0/4
 switchport private-vlan host-association 100 101
 switchport mode private-vlan host
!
interface GigabitEthernet0/6
 switchport private-vlan host-association 100 102
 switchport mode private-vlan host
!
interface GigabitEthernet0/13
 switchport trunk encapsulation dot1q
 switchport mode trunk

Note that there is nothing special about the trunk configuration; both ends are configured as typical 802.1Q trunk interfaces.

Trunking

With the configurations above applied, the router is able to communicate with all hosts, and all hosts are able to communicate with the router and with the other host in their respective community private VLANs (e.g. host A can reach the router and host B, but not host C or D).

Of course, good network engineers aren't satisfied simply knowing that something works: we want to know how it works. This functionality is actually achieved by bending some rules about VLAN assignments. Traditionally, you expect return traffic originating within a VLAN to come back over the trunk tagged with that same VLAN ID. This is not always the case with private VLANs.

When the router sends a frame to one of the hosts on S2, the frame is tagged as belonging to the primary VLAN 100 when it traverses the trunk, because the router is attached to a promiscuous port. Frames originating from the hosts, however, are tagged with their appropriate secondary VLAN IDs. A frame from host B back to the router, for example, is tagged as VLAN 101 when traversing the trunk link.

To summarize:

• Frames originating from a promiscuous port are tagged with the primary VLAN ID
• Frames originating from a host port are tagged with the secondary (isolated or community) VLAN ID

And of course, here's a packet capture to help drive the idea home.

SVIs

What if we wanted to remove the router from our topology and do all inter-VLAN routing locally on our multilayer switch S1? No problem, we just need to create the primary VLAN SVI (switched virtual interface, also commonly referred to as a VLAN interface) and apply to it a mapping for our secondary VLANs. First we'll shut down the interface connected to the router and enable multilayer switching.

S1(config)# interface f0/1
S1(config-if)# shutdown
S1(config-if)# exit
S1(config)# ip routing

Next, we'll create the SVI for VLAN 100, assign it the IP address which was previously assigned to the router, and map our secondary VLANs.

S1(config)# interface vlan100
S1(config-if)# ip address 192.168.0.1 255.255.255.0
S1(config-if)# private-vlan mapping 101-102
S1(config-if)#
%PV-6-PV_MSG: Created a private vlan mapping, Primary 100, Secondary 101
%PV-6-PV_MSG: Created a private vlan mapping, Primary 100, Secondary 102

S1 now functions in place of the external router; all hosts can reach its routed Vlan100 interface but are still restricted to communicating with hosts in their secondary VLAN.