Picking up where we left off on the first series, I want to discuss the other trunking option that we have in regards to PVLAN trunks. We might need a quick review on our PVLAN structure before we begin, however:
vlan 100 private-vlan primary private-vlan association 200-201 vlan 200 private-vlan community vlan 201 private-vlan isolated
This second trunk type is actually called the secondary, or isolated trunk. Much like the promiscuous trunk, this one has a pretty specific purpose, and that is to flip the VLAN tag when a frame is traversing a trunk. This time however, rather than removing the secondary VLAN tag, and replacing it with the primary tag, we are going to be doing the opposite! Remember how we were doing it with the promiscuous trunk? What happened here is the node with MAC A ingresses and is placed in VLAN 200. However, when it needs to reach the L3 GW (the router), we have to remove the secondary VLAN tag and replace it with the primary VLAN ID of 100 (so that it will hit the proper sub-interface on the router).
The routers return traffic will naturally be in VLAN 100 based on the sub-interface configuration. But the switch, knowing the private-VLAN structure, will allow that traffic to be send to MAC A on VLAN 200.
Again, this all works perfectly. But what happens if we throw in another switch; one that does not understand PVLANs (like a 2950). Well, this can cause some issues. Imagine that this 2950 has a port hanging off of it that is supposed to be in our isolated VLAN 201. Like any normal network, we have a nice little dot1Q trunk going down to the 2950. So what’s the problem with this setup? Lets take a look!
With a normal trunk in place, traffic coming from behind the router towards the host 192.168.1.11 would originally be placed in the primary VLAN 100. The first hop switch knows that it can reach MAC E in VLAN 201 off of the E1/5 trunk port going to the 2950, so it forwards the frame onward, still tagged with primary VLAN ID 100. Because the 2950 has no idea of PVLANs, this packet will be dropped, as there is no MAC E in VLAN 100’s CAM/MAC address-table. Therein lies the problem … even if it is a weak one. Since the 2950 doesn’t know that VLAN 100 is within the same PVLAN structure as 201, we need a way to get that traffic back to 192.168.1.11 (MAC E). The answer is, of course, isolated trunks! What we want to do is switch the primary VLAN ID with the secondary (isolated VLAN ID) when it goes across this trunk. Our configuration would look something like this, on port E1/5:
Interface Ethernet 1/5 Switchport mode private-vlan trunk secondary Switchport private-vlan association 100 201 No shut
Now some cliff notes … we can have up to 16 different associations like this on any given trunk link. We can also ONLY have a 1-to-1 relationship between any given isolated VLAN and a primary VLAN (i.e. we can’t have a statement that looks like ‘switchport private-vlan association 100 101-102′). Finally, the secondary VLAN must be an isolated VLAN. Note also, that we can still carry normal dot1Q VLAN traffic across this trunk! So ultimately, what does this configuration do? Well, it will switch the primary VLAN ID, with the secondary VLAN ID that it is associated to. Let’s take a look:
With the isolated trunk configuration now in place, the frame now needing to traverse the trunk to a known VLAN 201 host, will be remarked from VLAN 100, to VLAN ID 201 prior to being egressed onto the link. The result is that the 2950 switch will now have the traffic in the correct VLAN (201 in this case), and it will forward the traffic appropriately!