[Migration approach] C2960X L2-switches stack

[DamienTokyo]

Hi everyone,

I have been asked to support the migration from a 4-switches stack (WS-C2960S-48LPS-L)  to a new 4-switches stack (WS-C2960X-48LPS-L). We will re-use exacting same place in the rack, exactly same cables and exactly same configuration. These switches are L2 distribution devices mainly connected to user's devices (laptops, IP phones, etc) inside a medium-sized company local network. These switches are also connected to L3 core switches and so on.

I have a good idea of the work-around for this migration, basically re-using previous configuration and cables (connected to some servers and users's laptops). However I am thinking of what kind of checklist I should prepare before migration day.

Here are some ideas I have to make sure everything goes well after migration, for each point I will compare Before and After switches replacement status:

1. Create a matching list of Interfaces/VLAN/MAC Address/IP Address (show mac address-table, show ip arp)
   => Everything should match before and after except if a laptop is not connected, etc... 
2. Do a "show cdp neighbors" to confirm connected devices
3. On trunk interfaces (trunk connected to L3 switches): confirm spanning tree status with a "sh spanning-tree int <Interface name>" to confirm status is same as before

My question is, according to your experience, am I missing any other thing to check after migration ?

Thanks,

Damien

[balaji.bandi]

If you looking Like a Like Migration.

Build the new Stack offline using console cable same old, same like old numbering and priority, Copy the old switch config to new switch config, Few lines at a time make sure all the command accepted, no errors (some may be due to IOS code commands)

if all good config working as expected, write the config, in change window, save old Switch config, and power down, Power up new stack connect the Uplink check is the uplink ok, then connect laptop and test quick (Phone and PC working) - then patch rest of the cable

and monitor

Hope this works ?

[Leo Laohoo]

2960S and 2960X can be stacked together. 

So connect the 2960X to the stack and let the stack "synchronize" the config into the 2960X.

[DamienTokyo]

First of all thanks for your answers ! 
@balaji.bandi => That is what I have done, I have pushed old config through to new stack and you are right I had to be careful line by line because some lines got skipped for some reason (using TeraTerm on COM5 and console cable). Anyway so far I haven't had big issue create my new stack and pushing target config.

When you say "Monitor" this is precisely my concern, what and how should I monitor ?

@Leo Laohoo => That is good to know, but I am asked to not do any action on current production switches (neither config or hardware change like add stack member) but thanks for your answer anyway !

By the way, I have to add a new member to a another live stack (all switches are WS-C2960X-48LPS-L including the new one). The live stack has already 6 members, so I will add a 7th one. Regarding the process I have found these 2 interesting threads:

https://vmguru.com/2010/03/hot-adding-or-removing-a-cisco-3750-from-a-stack/
https://community.cisco.com/t5/switching/adding-a-switch-to-a-live-stack/td-p/3900837

I have just one question about this: is there any impact when adding the new member to the stack ? For instance you have to disconnect and reconnect the stack cabling set-up right ? Is this stack re-cabling making any disturbance to existing switches inside the originial stack ?

Thanks,

Damien

[balaji.bandi]

When you say "Monitor" this is precisely my concern, what and how should I monitor ?

I am sure as i suggested test 1 PC and 1 Phone working as expected ( any AP you have)

When i mentioned " Monitor" since you migrated to a new environment, all should work as expected - but keep an eye any unknown issue may arise, so keep track of them and fix and move forward. - no issue reported in weekdays from the user, all good you make a closure of this cutover.

I have just one question about this: is there any impact when adding the new member to the stack ? For instance you have to disconnect and reconnect the stack cabling set-up right ? Is this stack re-cabling making any disturbance to existing switches inside the originial stack ?

Adding to the existing stack does not have any impact, as long as you do not go beyond the limitation numbers

Look at the stack ring cable make sure you close the stack ring.

Always prepare new switch with a new number and priority save the config, connect the stack cables and turn on the device is best

if you are more concerned, to get confident and save yourself, do it in maintenance wndow.

[Richard Burts]

One other thing I would suggest adding to the list of things to check would be the output of show interface trunk, especially making sure that the last line about vlans active matches before and after the change.

In a migration like this the biggest challenge is the physical movement, making sure that a cable removed from an old switch is connected to the correct switch in the correct port of the new switch. Would it be feasible to have some type of labeling on cables to assist in verification of the physical movement? Would the output of show interface status be helpful (especially looking for ports that were connected now show up as not connected, or were not connected and now are connected)?

[paul driver]

Hello
Review list attached, I would suggest checking vtp if you are running it and make sure the new switches have there revision number set to 0 before adding them into the production
Also spanning-tree to make sure the stp root for the estate hasn’t changed post migration, Just make sure the new switches have the same stp BID priority as the old switches,

As for adding new switch to an exiting stack, as you have stated you will need to break the full stack ring ( full backplane bandwidth to half) so to add the additional switch however this shouldn’t incur any outage, just make sure you reconnect the stack ring.

[DamienTokyo]

Hi everyone, thanks for your replies. All your information are very helpful.

Replacement day is on July 31st, I will let you know afterwards how it has been doing.

[DamienTokyo]

Hi, I have noticed that one command which was configured on my previous stack is not accepted accepted anymore in CLI when I push it:

Switch#snmp-server enable traps cluster

"Invalid input detected at '^' marker."

I don't find any relevant information about this, except below link where I do not see any problem.https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960x/software/15-2_2_e/network_management/command_reference/b_nm_1522e_2960x_cr/b_nm_15ex_2960-x_cr_chapter_010.html

My switch's stack model are all WS-C2960X-48LPS-L and IOS version is 15.2.7E4(MD). 

Has someone an idea about this issue ?

Thanks,

Damien

[Leo Laohoo]

---

@DamienTokyo wrote:

Switch#snmp-server enable traps cluster

"Invalid input detected at '^' marker."

---

The command can only be entered in configuration mode. 

Currently, the switch prompt, the symbol "#", means the user is on enable mode only.

[DamienTokyo]

Hi, my bad my previous post was a an inaccurate copy/paste.

I confirm I did push it in config mode like this:

Switch(config)#snmp-server enable traps cluster

"Invalid input detected at '^' marker."

I got the error anyway.

[Leo Laohoo]

And what firmware is the switch running on?  The switch is not running on an "EX" firmware, would it?
I can see this command in my 2960X running 15.2(6)E2.

[DamienTokyo]

It is running on 15.2.7E4(MD)

[Leo Laohoo]

---

@DamienTokyo wrote:

snmp-server enable traps cluster

---

I know the reason why this command is not working:  Cisco IOS and IOS XE Software Cluster Management Protocol Denial of Service Vulnerability

The SNMP trap "cluster" is for Cluster Management Protocol (CMP).  This was the "grand-daddy" of the stacking technology. 

The software vulnerability was published way back in March 2019 and the 15.2(7)E4 was released in March 2021.  

Cisco had removed the cluster SNMP trap because CMP is no longer supported by the software release.  

CMP has been renamed to Horizontal Stacking and Single IP Management.

[DamienTokyo]

Thank you very much Leo Laohoo, it does make sense. Now I understand the reason why this command is not working anymore.

That was something good to know.