11-05-2017 12:15 PM - edited 03-08-2019 12:37 PM
Hi
I am migrating our core switches next weekend and was looking for some advice on the actual move itself.
I am moving our current Cisco core stack to a new core stack. I am keeping the same IP address and using the same rack space. The core switches have around 10 SVI'S, some DHCP and static routes. I will setup all the config prior to the day so its ready to go.
Is there any issue with simply taking the old stack out then putting in the new stack and connecting the cables?
I see lots of people saying about a staged migration which would be nice but i need to use the same Ip address as the existing stack and the same rack space so this will get messy so if i can just do a switch over this would be preferred.
I have arranged downtime with the business so this is not an issue.
Thanks in advanced.
Solved! Go to Solution.
11-05-2017 12:45 PM
Hello,
actually I think your approach of shutting down the core stack altogether and replacing it, rather than doing a staged migration, is the much better way, especially since you have scheduled downtime for it. If something isn't working, you just have to look at one system, the new one. I used to do these kinds of migrations on weekends, out of business hours; the only thing I would recommend is to dry run the entire thing and time it, just to make sure that you have actually enough downtime scheduled. Other than that, since you have to use the same rack space, a staged migration would be messy and take a lot more time than the all-in-one-go approach...
11-05-2017 12:45 PM
Hello,
actually I think your approach of shutting down the core stack altogether and replacing it, rather than doing a staged migration, is the much better way, especially since you have scheduled downtime for it. If something isn't working, you just have to look at one system, the new one. I used to do these kinds of migrations on weekends, out of business hours; the only thing I would recommend is to dry run the entire thing and time it, just to make sure that you have actually enough downtime scheduled. Other than that, since you have to use the same rack space, a staged migration would be messy and take a lot more time than the all-in-one-go approach...
11-06-2017 12:51 AM
Thanks for the reply.
Ok great, that would be my preferred method. I will have to restart all the servers after but this is not an issue.
This core switch has access switches trunked to it. Will these be ok while the core switch is being removed, will they need a reboot after the new core is in?
Thanks
11-06-2017 07:38 AM
I dont think that access switches will require a reload.I have done in this past and they came up fine, just double check them. Thanks
11-06-2017 07:44 AM
11-13-2017 01:06 AM
11-06-2017 08:51 AM - edited 11-06-2017 08:53 AM
Hello
i would tend to lean towards a staged migration -once everything is setup it's just a mater of closing down svi on the old core and enabling the other it give the added.benifit of the troubleshooting issues to if they arise and incurs less outage to users
Staged migrations can also be done using the exact same addressing also.
Res
paul
11-06-2017 11:35 AM
Thanks everyone for the advice.
The main issue with the staged migration for me is the rack space as the new switches are going where the old ones are.
12-18-2018 10:08 PM
How staged migration takes place...
12-19-2018 03:04 AM
Hello
@saikiran_chary wrote:
How staged migration takes place...
In simplistic terms the main processes would include:
1)You create the new core will all the same L3 svi and ip addresses but have these in a shutdown state
2) Make sure the stp root is still the old core and the newcore is the secondary root then create a L2 trunk between old and new core, this provides not only will populate of the vtp database of new core but will provide L2 interconnection for the access-switches.
3) Manually relocate the access-switches onto the new core as and when applicable to site, the only outage you should experience would be to that access closet whilst you relocate the cabling
4) Once you've migrated all access-layer over to new core, arrange some downtime with site and then shutdown L3 svi on old core and enable the L3 svi on the new core relocate wan connections and disconnect the L2 connection between the old and new core.
Note: the procedure would vary depending if you have an IGP also running between core/ distribution/access-layer, static routing etc..
12-19-2018 04:44 AM
@paul drive
Thanks for the info Paul, yes we do have IGP running in network.
Instead of that can we just make replica with new core switch and switch the ports from old to new. as we replacing access switches as well with new one.
thanks
12-19-2018 04:55 AM
Helllo
absolutely yes you can - However the downside to that would be if for some reason you have a failure you would have back out the whole migration as aposed to a managed transition which will be piecemeal and if a failure occurs then you don’t have to rollback any previous changes
12-19-2018 06:41 AM
Thanks Paul.. OK assume am going wit managed transition.. can you brief the steps for it.. as we are replacing access switches as well with new one.. and I said before IGP is running in between.
Appreciate if you had any documents for this migration.
12-25-2018 10:55 PM
Hello Paul,
As we are running pvstp on old core switch.. can please suggest on that like how to create secondary root in new core switch.
Thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide