Change VLAN id in trunk

Question

I have 3 L3 switches. They're connected to each other with a trunk (in which I need to define the allowed VLAN's).

On SW1 I have for example vlan 100.
On SW3 I also have vlan 100, but it's another broadcast domain.
I cannot change the vlan-id on SW1 or SW3 without breaking the network.
The reason is that both networks were in the past seperate networks, but now they're joining for some services.
The best solution would be a new rewrite of all the services, than the vlan's and rebuild the network, but that's not for now.

I need to have access on 1 port of SW3 to vlan 100 of SW1.

So: the vlan-id should be changed.

Is there a 'normal' way to do this?

I solved it like this for now:
On the trunk between SW1 and SW2: allow vlan 100.
Create an access port on SW2 with vlan 100.
Create a new vlan on SW2 with a vlan-id that is not in use on SW2 nor SW3 (vlan 200 for example).
Create an access port on SW2 with vlan 200.
Make a loop between both ports, with the remark: never do this at home.
On the trunk between SW2 and SW3: allow vlan 200.

On SW3 I now have access to that vlan and the id is changed to 200, but this seems a dirty way to do this.
So my question is: is there a better way, except a redesign of the network (which is scheduled for 2019)?

Answer 1

This problem is pretty common when joining separately grown networks.

On most switches you can "translate" a VLAN when you assign different VLAN IDs on each side of a trunk and transmit the frames untagged ("native VLAN") on the trunk.

On some switches you can even translate a VLAN by connecting two of the switch ports using the same logic. This may cause weird effects on other switches though, so test thoroughly before actual use. You also need to deactivate STP and any loop detection methods on these ports, obviously.

All these tricks cause serious problems when RPVST or MSTP are in use, beware.

After some success and more problems with these methods my advice is to change the conflicting VLAN IDs. It's easier than you might think with a good plan.

A completely different approach is to not merge the L2 structures but keep them separate across one or two routers (depending on whether you can reuse VLAN IDs on separate routed interfaces or whether you can/want to connect the router without VLAN trunks).

Answer 2

Sadly this is the "classic" method to do this.

Though, If you have certain high-end switches you could use the VLAN Translation in Trunk feature. While it's intended to wrap all customer VLANs into a new VLAN tag, it can also be utilized to create one to one translations between one switch and the next.

The feature isn't widely available, which is a shame, because this seems to come up al the time in my experience.

Still, it's worth checking on your switches and seeing if they support the feature, as it would be more preferable to having the separate physical connections.

Also: By "redesign the network" in 2019 I assume you mean simply add the new vlan, save the config to TFTP, run a find/replace operation on the configs of the switches who's vlan needs to change and then copy tftp over the running-config. Could take you all of 20 minutes if only changing a couple switches. Which could honestly be done in any given set of downtime with only some blips.