Understanding the PVLAN Promiscuous Trunk Feature for Routing on a Stick

Private VLANs are a layer two construct that can be used to isolate traffic in a single broadcast domain. Routing is necessary and unchanged when packets need to be delivered into a different VLAN.  When routing is performed in a layer three switch, the “private-vlan mapping” is specified directly on the SVI. But what if the desire is to punt routing up to a device with no concept of PVLANs? This article is intended to address the unique challenge and solution around building a trunk to a layer 3 device that has no understanding of private VLANs. Understanding these considerations should also further the understanding of how Cisco utilizes unidirectional VLANs to create the PVLAN functionality.

Before moving into the technical detail of this matter, I need to mention that this concept of a PVLAN trunk is briefly mentioned in some of the SWITCH course materials. Support for this feature seems to be quite limited. As a result, I currently lack access to a lab that has a switch that supports this feature. Therefore, this article is conceptual to a degree. I do believe that stepping through this example will help solidify the underlying knowledge of how PVLANs function and allow readers to understand some of the challenges in this scenario.

To fully understand the challenge of PVLAN routing on a stick, a basic understanding of PVLAN operation is required. PVLANs are meant to control traffic, as desired, at layer 2. This is accomplished doing some creative tricks with VLANs. From an operational standpoint, multiple VLANs are attached to ports in a unidirectional manner. “Primary” VLANs carry frames from “promiscuous” ports toward “secondary” (isolated or community) ports. Secondary VLANs carry traffic toward promiscuous ports. Generic 802.1q trunks carry VLAN tagged frames between switches that understand PVLANs.

The challenge with PVLANs and Routing on a Stick revolves around the trunk. From the switch perspective, traffic from isolated or community ports contain one or more VLAN ID’s. Traffic flowing back in the other direction is expected to have another VLAN ID. Therefore, multiple VLAN ID’s are associated with a single broadcast domain.

The solution to this is to merge groups of VLANS as relevant to the broadcast domain for the frames traverse the the PVLAN trunk link. In the diagram below, there are 2 distinct broadcast domains constructed out of a total of six VLANs. It is necessary to instruct the trunk port to address VLANs 100-102 similarly. In addition, VLANs 200-202 should also be grouped and handled as one.

The switch shown in the configuration looks like a 3750 or a 3560. As previously mentioned, support for this feature is sparse and may only exist on some 4500 series switches. The configuration steps listed below are based on my understanding and  research of the feature and will be solidified as soon as I can gain access to switches that support this configuration.

Switch Base Configuration

//disable VTP
Switch(config)#vtp mode transparent
Setting device to VTP TRANSPARENT mode.

Switch(config)#vlan 101
Switch(config-vlan)#private-vlan community
Switch(config)#vlan 102
Switch(config-vlan)#private-vlan isolated

Switch(config-vlan)#vlan 100
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#private-vlan association 101,102

Switch(config)#vlan 201
Switch(config-vlan)#private-vlan community
Switch(config)#vlan 202
Switch(config-vlan)#private-vlan isolated

Switch(config-vlan)#vlan 200
Switch(config-vlan)#private-vlan primary
Switch(config-vlan)#private-vlan association 201,202

//community ports for 192.168.100.0
Switch(config)#interface range fa0/1 - 2
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#switchport private-vlan host-association 100 101

//isolated ports for 192.168.100.0
Switch(config)#interface range fa0/3 - 4
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#switchport private-vlan host-association 100 102

//community ports for 192.168.200.0
Switch(config)#interface range fa0/13 - 14
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#switchport private-vlan host-association 200 201

//isolated ports for 192.168.200.0
SwitchA(config)#interface range fa0/15 - 16
Switch(config-if-range)#switchport mode private-vlan host
Switch(config-if-range)#switchport private-vlan host-association 200 202

Switch PVLAN Trunk Configuration

//Promiscuous PVLAN trunk
Switch(config)#interface fa0/24
Switch(config-if)#switchport mode trunk private-vlan trunk promiscuous
Switch(config-if)#switchport private-vlan mapping trunk 100 101,102
Switch(config-if)#switchport private-vlan mapping trunk 200 201,202

Router Configuration

interface fa0/0.100
 encapsulation dot1q 100
 description For VLAN 100
 ip address 192.168.100.1 255.255.255.0

interface fa0/0.200
 encapsulation dot1q 200
 description For VLAN 200
 ip address 192.168.200.1 255.255.255.0

Although this is not a feature that I see regularly used, I do believe understanding the concepts can be beneficial. By working through this and similar configurations, we get under the hood and understand how private VLANs are built and function. This understanding can be very beneficial when designing and troubleshooting networks that utilize the feature.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Design. Bookmark the permalink.

4 Responses to Understanding the PVLAN Promiscuous Trunk Feature for Routing on a Stick

  1. Elvin says:

    Good post!

    Elvin

  2. Cisco 3750 does not support the Promiscuous trunk port feature and as far as i know this is only supported on 4500 and higher.

    I’m currently looking for a solution to the problem because i have isolated vlan’s on a vmware switch running through a 3750 on it’s way to a Cisco ASA and i can’t get it to work.

    I can’t understand why 3750 can set up a promiscuous port, but not trunk and really can’t understand that the ASA don’t understand PVLAN at all. It’s not like Cisco have any alternative to the ASA.

  3. John Vasconcelos says:

    This post helped me solve this exact problem. I had 5 4948 trunking into a 3750-X which then trunked into a 7609. I was not able to do the promiscuous trunk on the 3750 to 7609 as it is not supported, so I set the promiscuous trunk between the 4948 to the 3750 and it worked perfectly.

    The SVI exists on the 3750X, which is performing DHCP to the customers leaving on the isolated ports of the 4948.

    Thank you very much for this post.

  4. Paul Stewart, CCIE 26009 (Security) says:

    Thanks for the great feedback.

Comments are closed.