Hello Lee,
I would say the security enforcement provided by a PVLAN configuration is local indeed. But to allow an end-to-end communication the seconday pvlans has to be created and allowed on the intermediate switches trunks => The flows will be tagged just like any regular VLAN.
In order for [secondary] pvlan hosts :
- To be able to communicate with the outside/promiscuous port (from the VM to the N7k)
- To be able to communicate between them (ex : two hosts from the same community pvlan but on different ESX).
- And for the other PVLAN switches of the domain to be able to know if a communication is allowed or not.
For all of these conditions, the secondary tag has to be extended throughout the switches (or at least to the other switches using PVLANs where communication need to go through).
We have also to note the PVLAN traffic flow is considered as unidirectional => the tag depends on the traffic direction =>
Upstream direction :
From the end device (VM in pvlan) to the exit device (where the promiscuous port is located), the traffic travels with its associated secondary vlan tag.
Once it reaches the promiscuous port (on the N7k) :
=> If it is a “normal” promiscuous port, the secondary tag is stripped and the packet sent untagged to the FW or the L3 device (untagged / primary pvlan).
=> If it is a “promiscuous trunk” port, the secondary tag is re-written with the primary vlan dot1q tag.
Ex : VM in isolated PVLAN 121 needs to communicate with the outside => The flow are tagged with pvid 121 between all the switches until it reaches the exit promiscuous interface .
This is why the secondary pvlan has to be created and allowed on the upstream trunks.
Downstream direction :
From the promiscuous port switch to the end devices, the traffic flow is tagged with the primary pvlan tag. When it reaches the end local switch, the flow is then forwarded through the associated private-vlan host interface.
The primary pvlan has to be created and allowed on the downstream trunks.
===
We have also to consider the communication between two hosts in the same community pvlan and
hosted in two different ESX => The communication (within the pvlan domain / no need to reach the promiscuous port) is tagged with the community pvlan tag through the intermediate physical switches.
===
I suppose it could work by tagging asymmetrically (secondaries on upstream trunk / primary + community on downstream) depending on the direction but I do not do that => I am used to create and allow all the pvlans on each side of the trunks.
So the ultimate answer is yes => We need to create the secondary vlans and allow them on intermediate switches trunks just like any regular vlan. The security enforcment occurs on the end devices locally as you said.
I also think there is different ways to reach an end-to-end PVLAN secure communication especially depending on the restrictions and conditions (for ex. vlan defined as pvlan on the N1k and the N7k where the promiscuous port sits - But as regular vlan on intermediate switches...). Anyway here is what the documentation states :
http://www.cisco.com/en/US/docs/switches/datacenter/sw/5_x/nx-os/layer2/configuration/guide/Cisco_Nexus_7000_Series_NX-OS_Layer_2_Switching_Configuration_Guide_Release_5.x_chapter6.html#con_1344030
You can extend private VLANs across multiple devices by trunking the primary, isolated, and community VLANs to other devices that support private VLANs. To maintain the security of your private VLAN configuration and to avoid other uses of the VLANs configured to be private VLANs, configure private VLANs on all intermediate devices, including devices that have no private VLAN ports.
Hope that helps.
Kind regards.
Karim
