Private VLAN Trunking with Promiscuous Host Trunk Ports

[david.mitchell]

Hi all,

Hoping someone can explain to me how a Promiscuous Host Trunk Port can keep track of multiple Private Secondary VLAN streams.

The was I see it, you have a router that doesn't support Private VLANs on your WAN boundry.  Trunking from the router you have a 6509 that does support Private VLANs. 

You have Private Primary VLAN 100 and Private Secondary Community VLANs 10 and 20 configured within additional switches trunked elsewhere off the switch and all VLANs in the 6509 VLAN Database.

You configure the trunk to the WAN router as per a normal trunk but you also create a mapping on the Promiscuous Host Trunk interface that correlated Primary VLAN 100 to the two Secondary Community VLANs (or Isolated VLANs if you like) 10 and 20.

Scenario

PC 1 in PVLAN20 sends traffic destined for somewhere outside of the LAN.  The 6509 knows that VLAN20 tagged packets correspond to VLAN 100 tagged packets and therefore retags with Primary VLAN 100 and sends onto the Promiscuous Trunk.

The bit I don't get is when the traffic comes back into the Promiscuous Trunk Port on the 6509 it is tagged with VLAN 100 so how does the switch know where to send the traffic (or rather which Secondary PVLAN to retag the packet with as you have Primary VLAN 100 mapped to both Secondary PVANs 10 and 20?

I assume there is some entry in the CAM table similar to a PAT table tagging conversations as the occur but would like to know for sure?

Any help appreciated as always

Thanks

David

[Peter Paluch]

Hi David,

The bit I don't get is when the traffic comes back into the Promiscuous  Trunk Port on the 6509 it is tagged with VLAN 100 so how does the switch  know where to send the traffic (or rather which Secondary PVLAN to  retag the packet with as you have Primary VLAN 100 mapped to both  Secondary PVANs 10 and 20?

By definition, if a frame comes in through a promisc port then this frame is allowed to be delivered to any station within the entire PVLAN (i.e. to each station in every secondary PVLAN associated with the given primary PVLAN). This should be logical since if every station from the PVLAN can talk to the device behind a promisc port, the device must then be able to respond to any such station anywhere in the PVLAN.

Let's reuse your PVLAN numbers - the primary PVLAN is 100, the secondary PVLANs are 10 and 20. When a frame comes through a trunk port tagged with VLAN 100, this frame will be switched according to its destination MAC address. This destination MAC address will be looked up among all CAM table entries that are learned within secondary PVLANs associated with the primary PVLAN - in this case, in VLANs 10 and 20. The frame will the be switched accordingly, or if no MAC address is found, it will be flooded out all ports associated with VLANs 10 and 20. If the frame is to be sent through another trunk, the VLAN tag will not be changed and will remain set to 100. Remember that when this frame is sent through a secondary community or isolated port, such a port never uses tagging anyway, so the tag would be removed.

In other words, a frame received in the primary PVLAN is never retagged because it is precisely the tag of the primary PVLAN that tells the switch that this is a "promisc" frame that can be delivered to any secondary community/isolated port. The tag is removed if the frame is sent through a secondary community/isolated port, but it is never changed to a different VLAN ID.

Please feel welcome to ask further!

Best regards,

Peter

[david.mitchell]

Thanks very much for the quick reply Peter; I have been looking into this the wrong way and had forgotten the basics of MAC address switching in the process.

I understand now the frame is received into the Promisc Host Trunk Port on VLAN 100 with a destination MAC of aaaa.bbbb.cccc for PC1. The 6509 looks at its CAM and sees that to get to MAC aaaa.bbbb.cccc you need send onto Secondary Private VLAN 20 if it was directly attached to the switch.

If it wasn’t directly connected to the switch, the process would be the same but the VLAN 100 tag would remain until it reaches its destination switch where the CAM lookup would occur here and map the Secondary Private VLAN 20 where the MAC address table would point to aaaa.bbbb.cccc out of fa0/1 for example.

I hope my understanding of the above is correct

“Remember that when this frame is sent through a secondary community or isolated port, such a port never uses tagging anyway, so the tag would be removed”

With regard to the above and sending the frame onto another Secondary Community or Isolated Port I assume this would mean Community or Isolated Host ports with end devices attached rather than trunk ports or Permisc ports?

I guess the VLAN tag would only change if the frame (tagged VL100) hit another Isolated Host Trunk Port going downstream to another switch that also doesn’t support PVLANs? i.e. that downstream trunk tags the traffic from VL100 to VLAN 20 for all PCs connected off the downstream switch.

Thanks again,

David

[Peter Paluch · Accepted solution]

Hi David,

I understand now the frame is received into the Promisc Host Trunk Port  on VLAN 100 with a destination MAC of aaaa.bbbb.cccc for PC1. The 6509  looks at its CAM and sees that to get to MAC aaaa.bbbb.cccc you need  send onto Secondary Private VLAN 20 if it was directly attached to the  switch.

I would slightly rephrase the process:

A frame with VLAN tag 100 is received on a promisc host trunk port. The destination MAC address is aaaa.bbbb.cccc. The 6509 first looks up which secondary VLANs are associated with the primary PVLAN 100, and it finds out that these are VLANs 10 and 20. Next, the switch will perform the lookup for the aaaa.bbbb.cccc MAC address only among those entries of the CAM table whose VLAN ID is set either to 100, 10 or 20 (we need to perform lookups on VLAN 100 as well because we may have two stations on two promisc ports communicating with each other).

If it wasn’t directly connected to the switch, the process would be the same but the VLAN 100 tag would remain [ ... cut ... ]

This is correct.

With regard to the above and sending the frame onto another Secondary  Community or Isolated Port I assume this would mean Community or  Isolated Host ports with end devices attached rather than trunk ports or  Permisc ports?

Correct. In fact, promisc host ports (not trunk ports) also do not use tagging, so the frame would be removed also if it was sent out a promisc host port. So the tag is removed on community/isolated host ports and on promisc host ports. The tag is retained on normal trunk ports, and may be modified on special PVLAN trunk ports.

I guess the VLAN tag would only change if the frame (tagged VL100) hit  another Isolated Host Trunk Port going downstream to another switch that  also doesn’t support PVLANs? i.e. that downstream trunk tags the  traffic from VL100 to VLAN 20 for all PCs connected off the downstream  switch.

Correct. You understand the PVLAN operations much better than you appear to admit yourself

Perhaps this article would be of interest to you, although you seem to already know this.

https://supportforums.cisco.com/thread/2037752

Best regards,

Peter

[david.mitchell]

Thank you Peter, you have really helped cement my understanding of PVLANs

Your help is much appreciated

Thanks again

David

[Cristian Ruta]

Hi, great question, I had this problem too. The key answer is in understanding how PVLAN is manipulating VLANs. So, the traffic from a secondary port is transported to the promiscuous port/trunk over the secondary VLAN. And the return traffic is carried by the primary VLAN ( the only mapping is that configured by you on the interface ).

On a deeper dive we notice that the VLAN manipulation works by marking MACs with specific types:

A MAC learned on a isolated port is marked as DYNAMIC pv in the primary VLAN and as BLOCKED on the isolated VLAN. ( -> so he cannot communicate with other isolated MACs because there are marked as BLOCKED, and the return traffic can be received because of the DYNAMIC pv type in primary VLAN)

The MACs learned on promiscuous ports are DYNAMIC pv on secondary VLANs and normal DYNAMIC on primary VLAN

The MACs from community ports are DYNAMIC in community VLAN ( can communicate freely with the other hosts in the same community) and DYNAMIC pv on primary VLAN (receive only).

Hope this helps,

Cristian