SDA - replace fabric switches with different model

[Michael Warren]

Cisco DNA Center Version 2.3.3.7-72328

We have a use case where we'd like to swap a C9500-24Y4C for a C9500-48Y4C. Is this possible in DNAC, or would the new 48 port switch need to be added to the inventory/fabric site, assigned the fabric role[s] before the 24 port switch demoted and removed from the fabric?

We have one use case where we'd like to to swap a combined Control Plane / Border Node.

We also have another use case where we'd like to swap a C9500-24Y4C for a C9600 - is this possible?

thanks in advance, Michael

[jedolphi · Accepted solution]

Hi Michael, there is some work happening in this space, but there's nothing available today. For roadmap please speak with your sales or CX contact. For now  you'll need to provision the new devices separately please. Thanks, Jerome

[Michal Rzepecki]

Hi Jerome, is something available today? I need to replace border/cp node 9500-48 with 9500-24. What is the best approach available today?

[jedolphi]

Hi Michal, you'll need to add the new switch as a new BN and then delete the old BN, or vice versa. There is no workflow to replace one switch with a similar-but-not-the-same switch. Regards, Jerome

[Michal Rzepecki]

How it should look like? I would like to use the same edge node's uplinks so I think I can remove BN, CP and WLC from current border node. How can I release IP addresses from current border node downlinks and from edge nodes uplinks to be able use LAN Automation for addressing links between edge nodes and a new border node?

[anthony.wild]

I think maybe another question along the same lines is, how can we gracefully conduct a supervisor upgrade for Catalyst 9400 to the newer variant.

[LFR Admins]

Hello @jedolphi,  @Andrii Oliinyk 

Do you have any tips or best practices for this common use case?

I'd like to replace an 8-port C9200CX with a 24-port C9300L while minimizing downtime as much as possible.

The workflows available (RMA and Device Refresh) don't seem to fit this scenario.

I came up with a possible approach, but it doesn't work in every situation and comes with a few caveats. If you have a better idea, I'm definitely interested!

The main challenge I see is the underlay, since the links are provisioned through LAN Automation/IPAM.

Let's take my real life example, I have an 8-port C9200CX (Extended Node role) connected to a Border Node on interface Ten1/0/1.
I need to replace it with a C9300L-24P.

In theory, if I have a spare interface available on the Border Node, I could connect the new C9300L to Ten1/0/2 and run LAN Automation.

Once provisioning is complete, I could disconnect old switches, insert the old SFP to the new switch (because physical fiber connectivity of course) , physically replace the C9200CX with the C9300L, and then move the Border Node link from Ten1/0/1 (initial link from BN to C9200X) to the Ten1/0/2 configured during the C9300L LAN auto.(BN to 9300L)

Technically, this should work, but it changes the physical topology during the migration and results in different underlay IP addresses, which is not ideal.

On the other hand, it is fairly "plug-and-play".

Has anyone found a cleaner approach for this type of hardware replacement?

[Andrii Oliinyk]

Hi @LFR Admins 
1st of all. CatC 3x still has usecase of RMA w/ different HW unresolved: https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/catalyst-center/3-1-x/user_guide/b_cisco_catalyst_center_user_guide_3_1_x/b_cisco_catalyst_center_ug_3_1_x_chapter_011.html#:~:text=For%20Cisco%20SD%2DAc....

regarding described approach: i understand it as 2-phase action: a) fully provision new node on the new BN's port; b) within maintenance window replace old node w/ new node. this is only case where patching of the existing link to new ports (used during LAN-A) would make sense. So plan is Ok w/ only notice that u could consider decommissioning of old switch from CatC before u physically replace it with new one.

finally, "but it changes the physical topology during the migration and results in different underlay IP addresses, which is not ideal" - i'm not sharing this concern honestly :0)

[LFR Admins]

Hello @Andrii Oliinyk  

Thx for the quick reply !

Thanks, that makes sense.

Based on your response I basically have 2 options :
1) my proposed approach. It works, but it comes with two caveats: it requires spare ports on the BN and I need to update the related fiber documentation afterwards after I moved from Ten1/0/1 to Ten1/0/2 during maintenance window (lazy me :D)

2) traditional approach: remove the old switch from the fabric, remove it from inventory, and onboard the new switch through LAN Automation as if nothing happened. Caveats : longuer maintenance window required. 

Thanks for the clarification.

If someone has found a better way, I'm still interested. In the meantime, I'll keep my fingers crossed that a Cisco developer already has this use case somewhere in their backlog 😉.

[LFR Admins]

Oh, I almost forgot one more caveat with option 1 🙂

The new switch will get a different Loopback IP as well it may have an impact on firewall policies.

For the /31s though... fair point, that's probably not worth losing sleep over 😄.

[Andrii Oliinyk]

Many engineers use Loopbacks CatC automates for in-band mgmt. Many accounts also locate INFRA-VN bh central FWs resulting in whatever IP is allocated during LAN-A access to it protected by design. Nevertheless, it would be an operational horror to update FW to allow any new SDA node mgmt IP individually.