I’m not completely sure what you want to achieve here with DHCPv6 and your isolated VLANs. In general, keep in mind that in order to get all hosts in all VLANs (primary, community, and isolated) to receive their IPv6 addresses via DHCPv6, the DHCP server must exist on the primary VLAN, and DHCP messages should enter the PVLANs on a promiscuous port. Otherwise, your hosts within an isolated VLAN will not be able to receive any DHCP messages.
In the event that you have multiple switches with trunks, you must first make sure that all the switches involved are PVLAN-aware. You must also ensure that you are configuring both switches correctly. Take a look at this NetworkLessons note on trunking Private VLANs for more info.
Can you give us some more information about your particular topology and the ultimate goal you want to achieve? That way we will be able to help you further.
After a short search, I have seen that some people have been successful in creating a GNS3 topology with private VLANs. I believe that the GNS3 forum is an excellent source for solutions to these types of problems. For example, take a look at this post that shows a topology with private VLANs on GNS3. https://www.gns3.com/marketplace/labs/private-vlan
In the past private VLANs were not configurable on GNS3 but recent updates have allowed it. I suggest you do a little bit of research to further examine where the problem is in your topology.
I use this basic setup. For PVLANs it works well, however at the same time I would need route non-PVLANs (VLAN70) as well.
Is there any option how to carry traffic from/to PVLANs and non-PVLANs via R6<>SW6 link (the same link, without adding another one) simultaneously without configuring it as a trunk promiscuous port (that’s not possible on this switch) or replace SW6 L2 switch to L3 switch and configure its SVI?
Adding another, parallel link R6<>SW6 would be possible and VLAN70 will be routed then, however this solution in not very “elegant”.
I see that your VLAN 70 has hosts that are using a different subnet. Therefore, you would have to enable routing to allow communication between VLAN 70 and any of the isolated or community PVLANs you have created. So the issue here has nothing to do with private VLANs, it is a simple matter of routing from VLAN 70 to other VLANs.
The solution would be to create another physical link between SW6 and the router as you suggest, but I agree, that would not be very elegant. Another solution is to create a router on a stick, which creates a trunk port between the switch and the router. The router will have subinterfaces, one for VLAN 70 and the other for VLAN 100 (and all of its mapped private VLANs). And you can route from one VLAN to another using the appropriate router subinterface as the default gateway.
Still another solution would be to get rid of the router, and use an L3 switch and perform inter-VLAN routing.
I will try to explain the problem that I’m facing better:
PVLAN needs for communication with router promiscuous port, right? SW6’s uplink can be either trunk port or private-vlan promiscuous port?
When I configure SW6’s uplink as trunk port, only VLAN70 is dot1q tagged and can communicate with its GW (despite I configured sub INT for VLAN 100 as well).
On the other hand when I configure SW6’s uplink as promiscuous port then VLAN 100 can communicate with its GW. VLAN70 can’t because SW6’s uplink is not trunk port.
This is the reason why I think about adding another parallel link. One would be “classic” trunk link and the second one promiscuous… However if there is better solution I would be glad for it.
I read that there is promiscuous trunk port that carries PVLAN an non-PLAN traffic at the same time. However SW6 doesn’t support this function.
Ah, I see, thank you for the clarification. Indeed, the solution I would suggest is to use a promiscuous trunk. A promiscuous trunk will allow VLAN 70 to traverse the trunk normally, while at the same time, it would rewrite the private VLAN tags to that of the primary VLAN ID, thus the router on a stick would be able to correctly receive the tagged frames and route them appropriately. More about this can be found at this NetworkLessons note on the topic.
Yes, that’s the feature I described above. However, I find it strange that a switch that supports PVLANs does not support a promiscuous trunk. What image/device are you using? In any case, if SW6 does not support this feature, then the only other solution I can think of is your original suggestion of a second physical link.
I’m using GNS3 network simulator with Cisco VIRL IOSvL2 image. Although there is integrated a lot of functions in the image it definitely has its limitations. I wasn’t sure if this (promiscuous trunk function) is one of them or I configure something wrong way.
Now that I know (based on your info) that in the real world a switch that supports PVLANs should also support promiscuous trunk and that promiscuous trunk solve this issue, I’m ok with that
Anyway, I plan to buy real equipment for studying in the near future…
Hi Rene,
I need your help with a design query, I have PVLAN configured on a L2 switches, Say Pri VLAN is 600 and Secondary isolated VLAN is 601
the L2 switch is connected to a L3 switch, via TRUNK and VLAN 600 & 601 are allowed VLAN’s on that trunk link between the two switches.
The Layer 3 switches has both 600,601 configured as normal VLAN.
VLAN 600 on the L3 switch has the gateway IP address .
The isolated host connect to the L2 switch are not able to ping the default Gateway.
Is there anything i can do to make this work
Ideally, you should configure the L3 switch to participate in the private VLAN setup such that it is aware of the PVLAN configuration, and can be configured with a promiscuous port such that the default gateway will be reachable.
However, if you do not wish to do this, there is a workaround that you can use. You can configure the trunk as a promiscuous trunk on the L2 switch side. Whenever a frame is sent out of such a trunk from a secondary or isolated VLAN, its tag will be rewritten with the appropriate primary VLAN (i.e. VLAN 600) thus being able to reach the default gateway. Take a look at this NetworkLessons note for more information.
