Cloud Managed Networks

Hello, community.

I have several CX switches in New Central and am wondering what happens if a switch fails. Is there an easy way to replace a switch? Specifically, I'd like to copy the configuration of a failed device exactly as-is. Unfortunately, I haven't found any instructions on how to do this, and I can't seem to find a way to do it in CNX either. The only thing I've found is a guide for Classic Central for ArubaOS-S switches, but that doesn't apply here.

Thanks for your help

------------------------------
Steffen
------------------------------

You haven't missed a doc, that workflow doesn't exist for CX. The Device Replacement tile in Classic Central only ever supported APs, AOS-S switches, and gateways. The replacement workflows explicitly exclude AOS-CX switches (along with AOS-S stacks and AOS-10 branch gateway clusters), so the AOS-S guide you found is the only one that exists, and it correctly doesn't apply to you.

The good news is that in New Central you mostly don't need it, because the config model is fundamentally different. There's no flat per-device config blob to copy anymore. Config lives in profiles that get assigned a device function and a scope, and Central pushes them to devices as structured YANG data rather than as CLI text. Those profiles inherit down Global >> Site Collection >> Site >> Device, with Device Groups sitting alongside, and precedence running Device >> Device Group >> Site >> Site Collection >> Global.

Practically, that means a replacement switch dropped into the same place inherits almost everything on its own.

1. Add the new serial to your inventory in GreenLake and assign a subscription.
2. Assign it the same device function as the failed unit (Access / Aggregation / Core) - this filters which profiles it's eligible to receive.
3. Put it in the same site and the same device group.
4. Let it ZTP. Everything from Global, Site Collection, Site, and Device Group scope lands automatically.

What you have to rebuild by hand is whatever lived at device scope. The scope-specific profiles pinned to the device level include System Information (hostname) and interface configuration, plus any local profile overrides you created on that specific switch (management IP, per-port stuff, VSX device-side bits).

So the real takeaway is a design one: the less you keep at device scope, the closer an RMA gets to zero-touch. If your port layouts are consistent, push as much as you can up to site or device-group scope and keep device scope to hostname/IP only. It also helps to document or export the device-scope overrides for your production switches now, while everything's healthy, rather than reconstructing them from memory at 2am.

Two caveats:

• Same model/part number makes life much easier - interface config obviously won't map cleanly across a different port layout.
• VSF or VSX members are a different animal. Stack member replacement is still driven from the switch CLI (no vsf member <id>, factory-default the replacement, matching firmware, then re-add), with Central picking up the change afterward.

If a proper CX replacement workflow in New Central matters to you, it's worth raising with your account team as a feature request. You're not the only one asking.

------------------------------
Dustin Burns

Lead Mobility Engineer @Worldcom Exchange, Inc.

ACCX 1271| ACMX 509| ACSP | ACDA | MVP Guru 2022-2023
If my post was useful accept solution and/or give kudos
------------------------------