There are a few different rare cases where you may need to move a subnet to a completely new or different VLAN.  Making a layer 2 connection between two different networks with overlapping VLAN space or moving off of VLAN 1 for best practice reasons would be two examples.  I will be focusing on the latter in this discussion but the steps will be applicable in other instances as well.  To make this more practical lets keep the idea of very little to no downtime in mind.

As of late I have been doing a fair amount of reading into some of the “best practices” according to Cisco.  As I get a bit more experience in the network world I have come to realize that, yes, best practices do stem from somewhere and for some valid reason.  One such best practice example is the recommendation against the use of the default VLAN 1.

In my experience it seems like networks evolve.  For instance, a network was installed for a few computers and devices on VLAN 1.  VoIP was installed so a new VLAN was added.  A new special service was added and another VLAN was added for that.  A new admin takes over and tries to do a good thing and adds a separate VLAN for management.   The changes continue and the network grows typically without ever moving the original subnet off of VLAN 1.

VLAN 1 to switches is the control plane.  CDP, STP, etc packets are emitted from switch ports on this VLAN.   Management is configurable and can be shifted to a VLAN easily enough.  The original VLAN, often a user data VLAN, is most likely also running on VLAN 1.  Our goal is to shift everything from VLAN 1 to VLAN 10.  Enough explaining, let’s look at a visual:  The image below shows a simple topology, VLAN 1 is Red and VLAN 10 is Blue:

Ok, simple enough.  The only issue is how to does one move their network away from this type of VLAN 1 configuration?  The typical suggestion is to route between VLAN 1 and the new VLAN, slowly changing IPs from VLAN 1 to the new VLAN and changing the access mode of the ports as you go.  Do you see issues with this?  I sure do!  I will also have to verify DNS is updated, DNS caches are cleared, IP and access mode changes made in the correct order so I don’t get locked out if working remotely and the list goes on.

I have searched and searched for answers to this and have not found a good one, yet.  You are welcome to try my solution, however, this is experimental and I have not done anything like this in a large environment to know what types of issues could arise.  You have been warned!

My plan was to bridge VLAN 1 with the new VLAN that will be taking its place effectively making the two into a single broadcast domain.  I would then change access port settings to the new VLAN and connectivity should only experience a brief blip at most.  When that is completed I would connect the current default gateway to the new VLAN as I remove the old gateway from VLAN 1.  Finally, I would remove the bridge between the two VLANs and VLAN 1 would then be fully out of service.

The concept was simple but how do I actually make this happen?  I read that Cisco switches can do something called fall back bridging.  I thought I was on to something.  It turns this function  bridges only traffic of the non IP type between VLANs, bummer.   Another option came to mind, why not just bridge an access port in VLAN 1 with an access port in the new VLAN?  With spanning tree enabled this could cause issues but it should be possible.

I tried this without configuration changes and of course spanning tree kicked in.  I disconnected and tried again, this time tweaking the spanning tree settings on each port.   In my example switch ports Gi 0/12 and Gi 0/24 are being connected.

core(config)#interface range gigabitEthernet 0/12 , gigabitEthernet 0/24
 
core(config-if-range)#spanning-tree bpdufilter enable
 
core(config-if-range)#shut
 
core(config-if-range)#no shut

The ports then came up and linked together fine and without errors.  Just to reinforce this point lets disable the bridge protocol data unit filter again and see what happens:

core(config-if-range)#spanning-tree bpdufilter disable
 
core(config-if-range)#
 
*Mar  6 06:06:54.470: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Gi0/24 with BPDU Guard enabled. Disabling port.
 
*Mar  6 06:06:54.470: %PM-4-ERR_DISABLE: bpduguard error detected on Gi0/24, putting Gi0/24 in err-disable state
 
*Mar  6 06:06:55.477: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/24, changed state to down
 
*Mar  6 06:06:56.257: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/12, changed state to down
 
*Mar  6 06:06:56.483: %LINK-3-UPDOWN: Interface GigabitEthernet0/24, changed state to down
 
*Mar  6 06:06:57.255: %LINK-3-UPDOWN: Interface GigabitEthernet0/12, changed state to down

Obviously the spanning tree process is not so impressed with those actions…   If this happens you will need to re enable the bpdufilter, issue a “shutdown” and a “no shutdown” on each port and wait for spanning tree to again cycle through the waiting period on these ports.

In my example I had the access ports in portfast mode.  Portfast skips all of the stages of typical spanning tree and jumps right to forwarding.  The links come up quickly, however BPDU’s coming in on those ports cause the errors and take the ports down.  Without portfast but with BPDUs permitted the two VLANs will work themselves into a single spanning tree.  My preference is to use PVST (per VLAN spanning tree) so splitting the two VLANs by blocking BPDUs is still a good idea in that case.  Remember, the goal is to get off of VLAN 1 to another single VLAN anyhow…

Another step you may want to take is to disable CDP on the two ports that are bridged together.  They will generate CDP native VLAN mismatch messages if you don’t.

*Mar  6 06:23:34.912: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/24 (2), with core GigabitEthernet0/12 (1).
 
*Mar  6 06:23:34.912: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/12 (1), with core GigabitEthernet0/24 (2).

The topology of the network really wont change much aside from the link between VLANs.  You end up creating a topology similar to this in the end:

A few comments and words of warning on doing something like this:  Like I said, please be sure you know what you are doing, first and foremost.  Second, be sure this single link will not create a bottle neck.  For instance, if you create a bridged link, and migrate half of the access ports in your network you can figure on half of the traffic traversing this link.  Get your changes made and get this setup removed from the network as quickly as possible.  Third, remember how switches store host mac addresses in a MAC address table?  They will now have twice the entries because the address will be learned on each of the two VLANs.  This could cause issues if you try to accomplish something like this on a very large network.  Fourth, this probably would be best suited closest to the default gateway on the network.  Again, this would be a traffic consideration.  You do not want traffic traversing the inter-switch links twice just to pass through this bridging hack.  The fifth and final point is to experiment and be absolutely sure what you are doing with lab equipment before attempting to move a network this way.  Be sure the move is only a temporary thing and get the cable removed as soon as possible.

I hope this is helpful to someone and as always I would love to hear your comments on this particularly since this is an experimental idea…