RMA Procedure (SDA)

[KristofB]

Hello,

Cisco DNA Center User Guide, Release 1.3.1.0 describes the RMA Procedure.

It starts with the excellent statement;

“You can replace a faulty device with a replacement device available in the device inventory”

Clear, but how do we add the newly shipped RMA device into the inventory when you suffer a device failure!?

(To be clear, I’m talking about SDA Fabric devices)

Staging

One not-so-great option is to ‘pre-stage’ the RMA with minimum config and discover it.

-> Using the Uplink P2P IP address from the faulty device with a temporary default static route looked like a valid solution (avoiding ISIS config...) and to minimize the "manual" work.

I was able to discover the device, have it in inventory, and start RMA procedure. 

Software upgrade was performed, but after this it failed.

Via console I noticed my temporary uplink port configuration was cleared again. (and not replaced by the full faulty device config as I expected)

LAN Automation

Pre-staging the device is not very Software Defined, so using LAN automation would be a better option to get RMA device into inventory.   

Although you cannot LAN automate with routed ports, so you have to default the uplinks on Borders first.

LAN automation would assign new P2P’s to those interfaces…

I didn’t test it, but I assume if RMA procedure succeeds, you will have the old P2P’s on EDGE, and new P2P’s on border…. So you're screwed again.

So my question how is this full RMA workflow forseen? And no we do not have spare devices in our inventory when we start ;)   

For EDGE it’s probably more useful to just LAN Automate a new one (hope you remember your static (AP) port assignments) and don’t do the RMA procedure. But for Borders this is not applicable?

RMA procedure should certainly integrate PNP and take care of everything, same as RMA on ACI works perfectly!

Kristof

[Mariusz Kazmierski · Accepted solution]

Hi Kristof,

Currently indeed RMA workflow concentrates on some of the features, as described in:

https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/1-3-1-0/user_guide/b_cisco_dna_center_ug_1_3_1_0/b_cisco_dna_center_ug_1_3_1_0_chapter_011.html#id_114181

This include: 

• Deploying licenses

• Provisioning VLAN and startup configurations

• Reloading the device

• Checking for reachability

• Authenticating through Cisco ISE

• Revoking the PKI certificate

• Deleting the faulty device

• Syncing the replacement device
  etc.

The points that you used are very valid and indeed we are currently lacking full intent-based RMA workflow that will address some of the limitations that you described in the thread and the ones which are mentioned in the documentation.

What I would recommend going forward is to:

- for the issues that you described (failed software upgrade, uplink configuration, etc.) it would be the best to open TAC case to collect all the logs and determine the root cause of such unexpected behavior.

- for the extensions of the workflow please use 'make a wish' functionality in Cisco DNA-Center to submit your feedback to shape this functionality further in the future. 

Best regards,

Mariusz