I’ve discussed Private VLANs before and I still consider them a useful technology. However, most mentions and implementations of PVLANs only use one switch, and it’s not clear what the interactions of PVLANs with other devices are.
The above setup features three switches and a firewall, all connected through trunk links. SW1 and SW3 can use PVLANs, and SW2 can use VLANs but has no awareness of Private VLANs, as it’s a transit switch. The firewall acts as default gateway for all the VLANs, including the PVLANs (a real-world example would be an ASA 5510 here). The requirements of the setup are that an isolated port on one switch can’t talk with an isolated port on another switch, an isolated port on one switch can talk with a promiscuous port on another switch, it works over transit switches, and the trunk link can be used as default gateway. Will this scenario work? Let’s examine.
Cisco recommends to define both the isolated and promiscuous VLANs on all trunk links and transit switches. To remain consistent between switches, frames are always sent over trunk links tagged with the originating VLAN. A frame coming from an isolated VLAN will go over a trunk link tagged as the isolated VLAN. This way, the next switch knows it came from an isolated port and will only allow communication with either a promiscuous port or another trunk link that allows the isolated VLAN.
This logic solves the first requirements: the information of the origin port is carried over to the next switch, and PVLANs can work perfectly over multiple switches. Does this also include the unaware transit switch? Yes it does: it treats the PVLANs as just a VLAN and allows traffic over the trunk links. Of course, if the switch is not aware of Private VLANs, it’s not possible to configure access ports in those VLANs, isolated or promiscuous.
But how does return traffic behave? If a frame is sent from an isolated port to a promiscuous one (a default gateway), how does it return? It returns tagged as the promiscuous VLAN over the trunk links and can communicate to all ports: trunk , isolated and promiscuous ports. And this is where the flaw in the PVLAN design is: over trunk links, the switch expects return traffic to arrive over another VLAN. A ping from a device towards the default gateway goes over the trunks in the isolated VLAN and returns in the promiscuous VLAN. And a firewall with trunk links (e.g. an ASA) can’t handle this: it has no awareness of Private VLANs. It will send return traffic down the same VLAN, and once this arrives on the switch, the switch will think it’s a frame from an isolated VLAN access port and deny communication with all other isolated ports. Return traffic cannot reach the destination anymore.
In defence of the ASA, not a single vendor has PVLAN awareness in firewalls or routers. And this cripples the technology in larger environments, as you’re constrained to use one access port per VLAN in a Private VLAN environment, and this doesn’t scale when dealing with many VLANs.
Update 13/03/2014: the test setup for this blog post did not cover MAC address learning so I missed a very important fact: non-PVLAN aware switches will flood traffic in the Private VLANs, as they will never learn the destination MAC addresses of traffic in the same VLAN. This will not scale. Thanks to the networking-forum.net members again for the nudge in the right direction!
Reggle 