@Tobias Heisele Correct. Primary VLANs are mostly a grouping concept.
Primary and secondary PVLANs are all still distinct VLANs, for L2 purposes, until or unless it gets routed, at which point they turn into the primary VLAN on egress toward the next hop (well...actually whatever VLAN is on the port facing that next hop, anyway).
The private VLAN types are roughly equivalent to these setups, if the PVLAN feature weren't there:
- Isolated - An individual/distinct VLAN per port (as if each one had a different tag), with each one being bridged individually with the primary VLAN, and a VACL prohibiting bridging from one isolated port to anything but that one primary.
- Community - A normal VLAN which is shared between all ports in that community VLAN, but bridged to the primary with a VACL prohibiting bridging from the community VLAN to other communities or isolated ports under the same primary.
- Community two-way - Same as community, but also has more L3 features available. Not available on all platforms.
- Primary - A normal VLAN that can talk to all of its secondaries, but which respects those VACL rules. The primary is also the one that can be associated with an SVI.
If the frame arrived at the switch on a port assigned to a given secondary VLAN, it is tagged with that secondary VLAN ID at ingress. It can then be forwarded within that PVLAN grouping per the rules of the type of PVLAN that VLAN is.
To successfully pass those frames over a normal trunk, if the switch is not also routing via an SVI and performing local proxy-arp (which is kind of a spot-cheat to "bridge" two ports that would normally be isolated from each other), you need to include that secondary VLAN ID on the trunk.
If both switches on a link support private VLANs, you should use a normal trunk and configure the same private VLANs on each switch either manually or via VTPv3 (VTPv2 doesn't support PVLAN). Otherwise, a switch that doesn't have the private VLANs configured won't treat them any differently than any other VLAN and will use normal forwarding/flooding rules to all ports with those VLANs assigned, while the switch that does have them configured will treat them as PVLANs. The result of that would be broken L3 connectivity beyond that point, since there's no bridging between them at all on the non-PVLAN switch.
You only use PVLAN trunks if the other device on the link doesn't understand PVLANs, but you still need to trunk multiple VLANs over that link. Examples might be a virtualization host that doesn't support or isn't licensed for PVLAN features (eg for VMWare, that's only available in distributed vswitches) or a router or switch with those restrictions, like a 2960X without at least the ip-lite license. It doesn't magically make that other device aware of the PVLANs and they will still treat them like normal VLANs, but it tells the switch that does understand PVLANs to treat those VLANs as PVLANs for that port for its own forwarding decisions.
