Migrating from default VLAN to a specific VLAN

[bsdnazz]

We have approximatly 20 Procurves switches of various ages connected up in our building.

Our 'backbone' is a pair of HP2824s which are interconnected and to which 4 HP2650s are connected. Each HP2650 is connected to each HP2824.  Obviously we have spanning tree turned on. We also have 3 ESX hosts connected to both HP2824s.

Currently all the switches are configured to use the DEFAULT_VLAN but want to migrate to a new VLAN ID which will be 172.

It's easy to add the 172VLAN to the switches and configure trunking between the swiches. We can run two separate VLANS over the switches - that's the point of VLANs after all!

To simplify the migration process we'd like to be able to internconnect the two VLANS so that all systems on one VLAN can see all devices on the other. This would enable us to migrate devices one at a time with minimal network disruption.

We tried connecting an untagged port on the DEFAULT_VLAN with an untagged port on the 172 VLAN and things worked briefly (a few seconds) until the spanning tree protocol kicked in!

Is there is nice way to do what we want to do or are we looking a extended networkdown time?

[W Fooshee]

Making VLANs talk to each other involves routing. VLANS are effectively different networks, so routes would have to be defined to have them see each other. Connecting them together wouldn't make them talk to each other. And being separate networks, they'd need to be different IP address ranges or you won't be able to route between them.

The default gateway of each VLAN would need a static route to the device that contains the default gateway of the other VLAN.

If all you're doing is migrating without changing the IP addresses of the equipment, then you're looking at downtime while you reconfigure the switches and get the ports untagged all the way through. Devices on untagged ports of one VLAN will not see devices on untagged ports on the other VLAN.

[Vivek_Singh]

Hi,

I want to make sure that I understood it correct, so you connected two switch wiith a new port and untag 1 on one side and untag 172, is that correct?

After you perform above changes STP kick in and issue start.

I would recommend to enable BPDU Filter this ports and then untag 1 on one side and untag 172 on another. I will suggest to try in lab enviornment first and then check. I will try this in my lab and let you know.

[bsdnazz]

Hi Vivek,

We want to migrate an existing network with 172.16.x.x IP addresses running on the DEFAULT_VLAN (id1) to a new VLAN (id 172) while avoiding an IP renumber and network down time.

We have a number of interconnected switches on VLAN 1 and I've defined VLAN 172 and it's available on all the switches with the necessary trunking. I can easily control which VLAN a port is on and run the two VLANs independently as would be expected.

Ideally I'd like to be able to connect the two VLANs so that devices on one can see devices on the other and vice versa.

Simplistically, I marked a VLAN 1 port on one switch as untagged, a VLAN 172 port on another switch as untagged and then connected the two ports with a patch lead. With test devices (spare laptops) on each VLAN I was able to get brief connectivity lasting a few seconds.

Looking at the switch logging some spanning tree changes took place when I we connected the ports so I assume that the extra cable created an extra loop which was promptly disables.

All the important switches are MSTP capable but are mostly configured with RSTP.

[Vince_Whirlwind]

If you want to temporarily bridge the two VLANs, use a pair of switches with STP disabled on them.

Bridging the two VLANs could be a valid way to migrate a network into another. I know I've done that before, but only in special circumstances.

I think in your situation, I would prefer to enable VLAN 172 on a switch-by-switch basis: pick a switch, enable VLAN 172, and change all the switchport VLAN configs to replace VLAN 1 with VLAN 172, assuming inter-switch links currently have VLAN 1 untagged. This way, as you go along, the VLANs are bridged on every switchport that connects any migrated VLAN172 switch with any unmigrated VLAN1 switch.

As far as avoiding network downtime goes - you should be doing this out of hours anyway.

If your servers are in the same subnet as other hosts, then perhaps moving to multiple subnets/VLANs is a better idea anyway - it is usually best to avoid spanning any VLAN across multiple access switches if it can be avoided, and you should segregate clients from servers.