We are in the process of replacing a pair of 6509 chassis with 6509E's until we can replace them with Nexus 7ks next year. In making this change, we are also replacing the SUP 720-3Bs with VSS SUPs for added redundancy.
Today these cores have a typical setup using HSRP between them and IDF closets are replicated between them (connection in port g1/1 is to the same device as g1/1 in the other core).
My plan is to replace the first core with the new chassis and the VSS SUP, having the current configuration and VLAN data already on the new chassis and the new core configured as VTP client, allow it to come up to speed on its revision number and then place it back into server mode. Once HSRP is all set, then replace the second core and follow the same process.
Once both cores have been replaced and everything is stable, then issue the commands to start up VSS and reload both cores. Clean up port-channels, remove HSRP configurations,etc.
Is this the proper way to handle VTP and VSS in this setup?
The best way to do this is to bring the 2 new chassis and configured them as a VSS pair. If you follow the steps you are outlined here, you will encounter long outages, as the ports assignment for separate chassis is not the same as when you are running VSS. For example: if you have uplink port gi1/10 that connects to an access switch, after the VSS conversion this port will be changed to 1/1/10 (switch, blade, port) and so you have to move all the configs that was originally under 1/10 to 1/1/10 now.
Again if you are planning to do VSS, the best option is to do it from scratch and save yourself from a big headache.
No, when you convert to vss, you config is removed. You than need to copy the current config from the existing working switches to notepad, make the interface changes and paste it into the VSS pair.
If you can have all 4 switches up for the migration, you can do it with almost no downtime, assuming you have your IDF switches dual-homed. As Reza says, you'll incur a pretty big outage if you do it the way you've outlined and you gain very little.
I've done this exact migration at several large hospitals with all 4nodes online and had essentially no downtime. It involves moving spanning tree root and HSRP in a controlled fashion, then moving the access switches over one link at a time. They will only need to online together for a short time so hopefully you have enough power to manage that.
So are you bringing up the VSS outside of the network with their full configuration and paired together, bring them into HSRP as standby addresses, and then swapping the chassis in one at a time? Once that's done I'll need to then remove the HSRP standby groups and put the gateway addresses on the vlan interfaces.
So basically a blip for just the HSRP change?
You bring up VSS outside of the current environemnt. Create all vlans with a spanning tree priority higher than the existing.
Create all the vlan interfaces and leave them shutdown.
Connect the existing core to the new VSS core. Make sure that all vlans are properly crossing the trunk between old and new cores. Depending on how you're routing is set up, you might need to create a vlan to use for routing updates only.
At this point, you can start changing spanning tree priorities to move the root of the vlans to the vss. Once these have been moved, you can start to manipulate hsrp.
Whichever switch has the backup interface, shut those interfaces down. After this is done, shut the vlan inteface on the old core and no shut on the vss. Since vss doesn't use hsrp, it's hard to manipulate the vss since you want the vlan interface to be the previous standby ip.
Flipping the vlan intefaces shouldn't cause any issues. I've done this method several times in large hospitals with no issues.
Once you have the vss running, you can move the access switches 1 link at a time. Make sure you're running rapid pvst.
The method I've used for this is to create a port channel on both the access switch and the vss. On the vss, you can assign the interfaces into the port channel immediately. On the access switch, disconnect one of the interfaces that goes to the old core. Add the disconnected inteface into the port channel then plug it back in. It should come up as the only member of the etherchannel. After you verify this link is up properly, perform the same with the second uplink on the access switch. When you plug it in, it should join the channel and you should be fine. With rapid pvst, nothing should be noticeable when the links block and unblock.