Best way to replace a core swicth with minimal down time

[G3000LEE]

Hi All,

I will be replacing a Cisco 3750x with a Nexus 3127 and would like some advice about how to go about the actual migration with the least downtime.

As this is a replacement upgrade, both switches which are core switches will have the same IP addresses configured on them. 

So far I have two options that come to mind and would like to see what other options are out there.

Option 1; Power up the Nexus and migrate the cables. Obviously, this will cause a complete outage to everything connected to the 3750x. 

Option 2; Configure a trunk between the 3750x and the Nexus 3k and then migrate the cables over one by one. But the issue here is both switches will have the same config, IP addresses with all devices upstream pointing back to these switches. I have never tried to see what the outcome of doing this would be, but I'm sure the outcome wouldn't be good.

I would appreciate any real-world experience in this situation on how you tackle it.

Thanks in advance.

[Reza Sharifi]

Hi,

So, the challenge with your migration is that you want to use the same IPs on the old and the new device at the same time. And so, bringing the new switch online and connecting it to the old one will cause IP conflict.

So, the option is to build all the config on the new 3k ahead of time and before you connect it to the network. Once you are done with that, in a maintenance window, disconnect the old switch, connect the new switch and move over all cables from one switch to another. If you have extra copper cables, you can also leave the existing cables on the old switch and just use new cables for the new switch. This way if something goes completely wrong with the migration, you don't have to cable the old switch again. This saves you a lot of time and the window does not have to be as long.

HTH

[G3000LEE]

OK, so I guess this is the same as I mentioned already as options 1 so nothing new to add from what I have already said.

But thanks for the input.

[balaji.bandi]

we need to mode information how this Exiting core connected - another part of the network, is this stack? standalone?

is the new nexus will be vPC or standalone?

High level :

If  you want to retain all the IP address (like any static routing, SVI)

You need to prepare a nexus switch and connect back to the old Core, this time still OLD Core will be Gateway for all.

Once the new Device connected, configure the SVI and IP address of the interface (in shutdown mode)

with brief downtime, shutdown the SVI and bring up the SVI on the new Switch (along with cable moves and physical re-connection)

The above steps based on the standard approach, so you need to give more information or a small network diagram to help you while migrating any challenges can be verified before migration)

[G3000LEE]

This is a stand-alone core switch.

From looking at the config all networks connect to the core switch including the inside/outside firewall and ESXi hosts connect to it.

There an uplink to a 2960x but don't know what connected on that swicth.

[Reza Sharifi]

regarding other devices like FWs, 2960x, etc..that are connected to this switch, if you have extra ports, optics, etc.. available, you can connect them and keep them in a down state until the window arrives. The other important part of a successful migration is good documentation with multiple reviews so, you don't have to scramble at 2:00 AM looking for ports, cables, or optics. Bottom line, the more prep work you do ahead of time, the shorter the window you need during migration.

HTH

[balaji.bandi]

if this is only a switch, prepare offline like a like migration, make sure all the configuration is done on the nexus side, you really need downtime for this cutover. ( also plan rollback plan accordingly if any service not working as expected).

make sure you have all the information you need, you need to know the uplink where it connected from 2960 before moving.

[G3000LEE · Accepted solution]

Thanks for all the input so far but I haven't had a direct answer to my question.

In simple terms, I just want to know apart from the 2 options I have outlined, is there another way to go about the migration?

Thanks for the tips and pointers which I know already but I just want answers to my question.

Thanks

[johnlloyd_13]

hi,

i've done a few switch migration. it's also important to verify active ports and label them prior the cutover. it also helps to bring along new patch cables with various lengths (2m, 3m, 5m) just in case the RJ-45 clip breaks or there's a distance from old to new switch.

[G3000LEE]

Thanks for the advice but your reply doesn't answer my question at all.

I myself have done lots of migrations. I was asking if there another way of doing it apart from the 2 options I have outlined.

[paul driver]

Hello
I would say you are pertaining to a staged migration in which you have the exiting old L3 core running in parallel with the new L3 core switch.

To accomplish this, you would require a new or existing L2/L3 connection between old/new core which would be advertise in any IGP you are running.

Create the L3 SVI interfaces on the new core but have them shut down, migrate the L2 interconnects first and then when your ready shutdown each l3 svis interfaces on the old core and enable on the new core.

Lastly relocate any upstream routed ports connection on to the new core switch (such as Firewalls or wan link, static routes etc… and then shut down the old core.

An alternative would be to migrate the L3 first, static routes etc and any upstream routed ports connections on to the new core switch (such as Firewalls or Wan) links, disable ip routing on old core turning it into a L2 host switch, As such you would be left with all its  L2 interconnects on the old core switch, which you can migrate at a later time.

If you require any additional information relating your your specific environment please don't hesitate to ask?

[G3000LEE]

This idea is maybe what I was looking for.

What I am not too sure about is using an IGP as both the old and new core switches have the same IPs. Can you explain a bit more on how I would approach this? Are you saying to add another subnet to the new switch, which I would configure say, EIGRP, and advertise the new subnet?

I would need to advertise all subnets in the IGP on both switches? Obviously, I won't have both SVI up at the same time

I have a 3750x and a nexus at home to lab this up.

How would I go about testing configurations beforehand, like the SIV and access ports.

Do you think it is a good idea for testing, to connect an access switch (2960) to the core via port-channel and place some ports in the same VLANs which are configured on the core? I know there are a couple 2960x that connect back to the core.

Thanks

[paul driver]

Hello
So to migrate L3 form old-new cores you need a l2 trunk for all the l2 vlans to traverse through and a l3 routed port or SVI for the routing.

Now you can usually utilize an existing SVI from your “old” core and apply it to the new core with a spare ip address of that existing SVI or create a brand new SVI on both old-new cores for migration purposes.

Now if you are running eigrp then the L3 subnet is either already being advertised (if you decide to use an existing L3 SVI) or it needs to be advertised ( if you create a brand new subnet for migration)

Upon initial connection between old-new core, you should have:
Old core
All L3 SVI’s active and all L2 interconnects between distribution/access layer switches connected
L3 uplink to wan/fws etc..
L2 trunk between new core
L3 eigrp adjacency between new core

New core:
Duplicate of all L3 SVI’s from old core – (SHUTDOWN)
L2 trunk between old core ( single or aggregated port channel)
All L2 vlans populated in to vlan database (automatically via vtp or manually applied)
L3 SVI which is being used for migration ( ACTIVE)
L3 eigrp adjacency between old core (ACTIVE)
Route table populated with eigrp routes
Reachability to wan and all distribution and access

Note: You should not have worry about STP if the L2 connection between Old-New core is a single or aggregated P2P connection, Any other connection that mean you have extended L2 physical connections between old/new core then you will need to append to maybe a possible FLEX/REP link to negate stp loops

At this point you should be ready to stage migrate the L2 interconnects off the old core on to the new core (obviously creating the L2 trunks for each distribution/access as you go along and once that has been completed, migrate the L3 as stated previously.