Private VLAN trunking question

[Sanjay Ramaswamy]

I have a question on when to use private VLAN trunking.  I have read when trunking to a device that is not PVLAN aware, you should use PVLAN trunking.  If you are trunking between devices that are PVLAN aware the you should use regular trunking.

What it doesn't tell me is why.  Why do we need to use private VLAN trunking??  If the PVLANs are tagged using dot1Q then what is the purpose of using PVLAN trunking - it is not clear what is gained.

Thanks in advance...

[Peter Paluch · Accepted solution]

Hello,

Your information is correct - if the interconnected devices both understand Private VLANs then you should use a regular trunk. If one of them does not understand PVLANs then there are other special types of trunks to enable the communication under circumstances.

The first special trunk type is the promiscuous PVLAN trunk. Whenever a frame from a secondary VLAN is going to sent out such trunk, its 802.1Q tag will be rewritten with the appropriate primary VLAN ID. That is usable if you are, for example, doing a router-on-stick between several primary private VLANs. As the router does not understand that multiple secondary PVLANs actually map to a single particular primary PVLAN, the promisc trunk port will translate all secondary PVLAN IDs into the corresponding primary PVLAN ID.

The second special type of a trunk is the isolated PVLAN trunk. An isolated PVLAN trunk translates primary PVLAN ID tag into the isolated secondary PVLAN ID that is associated with the primary PVLAN. This is used if you want to extend the secondary isolated PVLAN onto a switch that does not support PVLANs. Thus, if a frame is coming from a promisc host port somewhere in the primary PVLAN and is about to be sent out the isolated PVLAN trunk port, its 802.1Q tag currently carrying the primary PVLAN ID will be rewritten to the isolated secondary PVLAN ID. If a frame comes in with the isolated secondary PVLAN ID, the tag won't be changed.

So, in essence, the speciality of these trunks is in the tag rewriting they perform:

• A promisc trunk port rewrites the secondary PVLAN ID into the primary PVLAN ID upon sending a frame. When a frame is received, no tag manipulation is performed.
• An isolated trunk port rewrites the primary PVLAN ID into the isolated secondary PVLAN ID upon sending a frame. When a frame is received, no tag manipulation is performed.

Note, however, that these special trunk ports are available only on Catalyst 4500 and higher. You may want to read this chapter from the 4500 Configuration Guide for more information:

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/54sg/configuration/guide/pvlans.html#wp1167271

Best regards,

Peter

[Sanjay Ramaswamy]

That makes it very clear - thank you for detailed response.

Sanjay

[MikeLight]

Clear, informative, concise -

I applaud you, sir. You should teach.

Mike

[theMethod]

Thank you professor.

[jmurphy]

Hi Peter,

I have been searching around for hours now trying to find a clear defintion of the isolated trunk port as I could always find how to do it but nothing ever said why you would do it. I have never posted before but your information is so useful for a particular project I am working on so I had to say thankyou.

Regards,

Justin

[Silviu Pietris]

Greetings,

I was reading the CCIE v5 book about PVLAN and funny - this explanation was in the book but looking on who provided the answer - well, it is one of the book authors.

I want to make sure I have got the explanation correct: is the frame rewriting applicable only for frames arriving on secondary vlans - all others keeping their tag in place (ex. frames from promiscuous trunks and regular vlans)?

Many thanks!

Best regards

[Peter Paluch]

Hi Silviu,

Yeah, I took the liberty of retaking some of my answers here into the book as I was editing it. You know, if an explanation works - and it seemed like this one worked for many people - I just decided to reuse it.

I want to make sure I have got the explanation correct: is the frame rewriting applicable only for frames arriving on secondary vlans - all others keeping their tag in place (ex. frames from promiscuous trunks and regular vlans)?

That is correct. All tag rewriting applies only to Private VLANs. Promisc PVLAN Trunks rewrite secondary VLAN IDs into the primary VLAN ID. Isolated PVLAN Trunks rewrite primary VLAN ID into the isolated secondary VLAN ID. Normal VLANs passing over these trunks will have their IDs unchanged.

Feel welcome to ask further!

Best regards,
Peter

[net-harry]

Hi Peter,

Thank you very much for your great explanations!

I have two follow-up questions;

1. Why are only isolated private VLANs (and not community private VLANs) allowed on isolated pvlan trunks?

2. We have one community VLAN for each customer. I would like to send the community VLANs on a trunk to a F5 that does not understand private VLANs. Servers on one customer community VLAN should not be able to reach VIPs (on the F5) for a different customer. Is there a way to do this?

Best regards,

Harry

[Peter Paluch]

Hi Harry,

Thank you for your kind words!

1. Why are only isolated private VLANs (and not community private VLANs) allowed on isolated pvlan trunks?

This follows from the purpose of the Isolated PVLAN Trunk - to extend the reach of a particular isolated secondary VLAN to another switch that is capable of isolating its own ports (using the switchport protected command) but does not support PVLANs and has no idea that this particular VLAN should be treated as isolated secondary VLAN. The trick in supporting this is to do a clever handling of the traffic that has entered the network at some other promiscuous port and is being forward out this Isolated PVLAN Trunk. If nothing was done, the frames would be tagged by the ID of the Primary VLAN which the other switch does not understand. So the Isolated PVLAN Trunk really replaces the tag of the Primary VLAN with the tag of the Secondary Isolated VLAN as the frames are forwarded to the other switch. The other switch does not really see anything special - it sends frames tagged by the secondary isolated VLAN, it receives frames tagged by the secondary isolated VLAN - all is good to him.

Having a trunk to support similar operations for community VLAN would pose problems. Remember, the purpose of the Isolated PVLAN Trunk is to replace the Primary VLAN ID with the Secondary Isolated VLAN ID on outgoing frames. However, if this principle was to be extended to community secondary VLANs then what particular secondary VLAN ID (out of potentially many community secondary VLANs) should be used to replace the Primary VLAN ID? Should that be just one or more secondary VLANs? Which ones? Notice that if you decide to support multiple community secondary VLANs, you will need to actually send a single frame in multiple copies on that trunk, each one being tagged with a different particular secondary community VLAN. That is not scalable - you could end up with a need to carry much more traffic than was originally sent simply because you would need to do the replication - one copy for a particular secondary community VLAN.

So I would assume that these reasons, along with a generally low demand for this feature, have led Cisco to not support this kind of special trunking for community secondary VLANs.

2. We have one community VLAN for each customer. I would like to send the community VLANs on a trunk to a F5 that does not understand private VLANs. Servers on one customer community VLAN should not be able to reach VIPs (on the F5) for a different customer. Is there a way to do this?

First of all, because the F5 does not support PVLANs, there are only two options of connecting it to your switched network: Either use a Promiscuous PVLAN Trunk on your switch toward the F5, or use a simple promiscuous port toward the F5. If using a Promiscuous PVLAN Trunk, this will allow you to carry multiple different VLANs including the Primary VLAN and all associated secondary VLANs under the disguise of the Primary VLAN to the F5 - normal VLANs will use their normal tags, all secondary VLANs will be rewritten to the primary VLAN tag. In the case of a promiscuous port, only the secondary VLANs associated with this particular primary VLAN will be able to access the F5 through this port, and no tagging will be performed at all.

In either case, servers in any of the community secondary VLANs will be allowed to talk to the F5, as that is the purpose of the promiscuous port or promiscuous trunk - to allow any associated secondary VLAN to talk to the device attached to such a port. To disallow servers in one community VLAN to talk to only a subset of IP addresses of the F5 attached to such a port is no longer in the competence of PVLANs. This will need to be taken care of on the F5 itself - presumably, using ACLs (if F5 supports any).

Best regards,
Peter

[net-harry]

Hi Peter,

Thank you very much for the additional information!

The F5 supports ACLs, so it would be an option to use those, but in my opinion it would be more difficult to manage. It would have been very nice if it was possible to map community private VLANs on the switch to normal VLANs on the trunk port.

Please find below an example of a (somewhat artificial) potential use case using only CIsco equipment:

A remote office hosting 3 companies has one layer 2 switch (private VLAN capable) and one router. 3 companies (A, B and C) all connect their HQs to 3 serial interfaces on the router and the interfaces are allocated to VRFs A, B and C. Company A, B and C all use 10.0.0.0/8 and have over-lapping addresses in their HQs.

In the remote office all users (belonging to company A, B and C) are connected to the same subnet (172.16.100.0/24), but they are in different community VLANs depending on company. There are some shared services (e.g. printers and DHCP servers) that belong to the primary VLAN.

We would now like to connect the ethernet interface on the router to the layer 2 switch and give each company access to their HQs. If it were possible to map community VLAN for A to a normal VLAN for A on the trunk port to the router and do the same for the VLANs for company B and C this would have been trivial and in my opinion a nice feature if it would have been supported.

Best regards,

Harry

[Peter Paluch]

Hi Harry,

It would have been very nice if it was possible to map community private VLANs on the switch to normal VLANs on the trunk port.

If you use a normal trunk (switchport mode trunk) then actually you're doing this already. On normal trunks, secondary VLAN tags are preserved. This is how trunking between multiple switches supporting Private VLANs works - if a frame is received on a port assigned to a secondary VLAN (isolated or community) and is going to be sent out a trunk, it will be simply tagged with that secondary VLAN ID. A frame received on a promiscuous port will be tagged with the primary VLAN ID. The receiving switch will analyze the frame with the tag and will decide based on this flag where the frame can be forwarded:

• If the tag belongs to a primary VLAN, the frame can be forwarded out through any other associated promisc port, trunk port, and any port in any associated secondary VLAN (community or isolated)
• If the tag belongs to a community secondary VLAN, the frame can be forwarded out through any other associated promisc port, trunk port, and any port in the same community secondary VLAN.
• If the tag belongs to an isolated secondary VLAN, the frame can be forwarded out any other associated promisc port or a trunk port

Getting back to your scenario and use case - if you configured the port toward the F5 as an ordinary trunk, all secondary VLANs would simply keep their tag unchanged on this trunk. As I understand, this is what you want to achieve. In this case, however, I am not sure why you actually deployed the private VLANs in the first place. This could have been done simply with ordinary VLANs. Do you do anything special with private VLANs somewhere deeper in your switched topology?

Best regards,
Peter

[paragparekh85]

Hi Peter,

I am just attaching topology which I am planning to use in my current project requirement.  But I am unable to achieve communication between FW and router configured as router-in-stick.  Purpose of using PVLAN is to block communication between 2 different customers.  Request you to please share your thoughts.  Few details are given in topology itself.

[tckoon]

Question about VMware virtual distribution switch that is private vlan support or enable private vlan.

The switch interface connected to VMware host , shall it be just a normal dot1q trunk port ?

Or need to configure as isolated trunk port ?

Also please refer to diagram question in ppt slide, I have few question/answer to be validated.

Thanks

[Nadav]

Hi,

As has been stated in this discussion, since VDSes are PVLAN aware you'd use a standard trunk port. So if your primary VLAN was V1 and your isolated VLAN was V2, you'd configure a standard trunk carrying both those VLANs to the VDS.

As for the VDS itself, you'd map V1 as promiscuous and V2 as isolated for that port-group.