A stack keeps forwarding when one member fails — but swapping that member back in without a second outage takes a specific order: confirm model, version and patch match exactly, stage the new unit as an unmanaged device, make sure the faulty unit was never the stack master, and only then power it down. This is that full replacement sequence, the pre-replacement checklist, and how to verify the swap actually took.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
A stacking system is built to keep forwarding traffic when one member switch fails — that resilience is the whole point of stacking. The replacement itself is where a rushed step can undo it.
When a member switch in a stack develops a fault, or ages out and starts affecting business, the fix is straightforward in principle: bring in a replacement unit of the same model, version and patch, and swap it in. What the source maintenance documentation is careful about is everything around that swap — the new unit must match the faulty one exactly, its stack configuration (slot number, priority, stack port) has to line up before it ever joins, and the faulty unit must not be the stack's master when it comes down. Confirm the License has capacity for one more managed device before you start, or the new unit won't be added at all.
If this stack was built by someone else, or you inherited it mid-fault, the failing member's model, version, patch, slot ID and priority aren't things to guess at from memory. Pull them from the controller the same disciplined way you would on a network you're taking over for the first time, then match the replacement to what you actually found on the device — not what the label on the box suggests.
Every stage below exists to keep the faulty unit's identity from ever conflicting with the new one, and to keep the stack's master role untouched until the swap is actually done.
Diagram labels are kept in English for engineering clarity.
The controller-side replace operation and the physical swap are two different actions — matching the ESN is what tells the controller the new unit is standing in for the old one, not a fresh addition to the stack.
Five checks, straight from the source procedure — model and version, stack identity, the master role, and License headroom.
| Check | What To Confirm | Why It Matters |
|---|---|---|
| Model / version / patch | display device on the new unit shows the identical Type as the faulty unit; display startup shows the same startup system software and patch package. | A mismatched model, version or patch is exactly what the source documentation flags as the reason to stop and source a different unit rather than proceed. |
| Stack ID and priority | The faulty unit's slot number and priority, read from the controller's Stack tab, must match what you configure on the new unit before it joins. | A new unit joins in slot 0 at priority 100 by default; joining with the wrong slot number breaks the replace-by-ESN match on the controller. |
| Stack port (cable stacking only) | If the stack uses ordinary cables rather than dedicated stack cables or a stack card, the stack port is configured to match the faulty unit's original business ports. | Dedicated stack cables and stack cards need no such configuration at all — configuring it when it isn't needed, or skipping it when it is, both break the join. |
| Master role | display stack on the faulty unit shows its Role, and Role must not be Master. | Powering off a stack master mid-replacement is a different, more disruptive event than replacing a standby member — switch it over first if it reads Master. |
| License capacity | The License has room for one more managed device before the new unit is added. | Without spare capacity the controller can't bring the new unit under management at all, stalling the replacement before it starts. |
Source: high-density campus network solution maintenance documentation, stack-member replacement procedure.
Six commands, all run on the device itself, that confirm the stage you're actually in before you move to the next one.
| Stage | Command | What It Confirms |
|---|---|---|
| Model check | display device | Shows Type (model) for the unit — must equal the faulty unit's model exactly. |
| Version / patch check | display startup | Shows the configured and next-startup system software and patch package. |
| Identity | display esn | Reads the new unit's ESN, needed to register it on the controller. |
| Stack state | display stack | Shows Slot, Priority and Role for every member — Role is the field to check before powering anything off. |
| Stack port state | display stack port brief | Shows each stack port's physical and protocol state before you touch interface configuration. |
| Persist config | save / save stack configuration | Writes the running configuration, and separately the stack configuration, so the join survives a reboot. |
<HUAWEI> display device
S5735-S24T4X's Device status:
Slot Sub Type Online Power Register Status Role
0 - S5735-S24T4X Present PowerOn Registered Normal Master
<HUAWEI> display startup
Startup system software: flash:/s5735-s-v200r019c10spc500.cc
Startup patch package: flash:/s5735-s-v200r019sph020.pat
<HUAWEI> display esn
ESN of slot 0: 210235860012xxxxxxxx
<HUAWEI> display stack
Slot Role MAC address Priority Device type
0 Master xxxx-xxxx-xxx1 100 S5735-S24T4X
1 Standby xxxx-xxxx-xxx2 100 S5735-S24T4X
<HUAWEI> system-view
[HUAWEI] stack slot 0 renumber 1
Warning: All the configurations related to the slot ID will be lost after the slot ID is modified.
Do not frequently modify the slot ID because it will make the stack split. Continue? [Y/N]:y
[HUAWEI] stack slot 1 priority 150
Warning: Do not frequently modify the priority because it will make the stack split. Continue? [Y/N]:y
<HUAWEI> system-view
[HUAWEI] slave switchover
<HUAWEI> save
<HUAWEI> save stack configurationSource: high-density campus network solution maintenance documentation — commands shown are taken from the original procedure, values and MAC/ESN fields anonymized.
Same procedure as the checklist above — here's what happens when a step gets skipped, and what to check instead.
RISKdisplay stack's Role field is not a formality — if the faulty unit is the stack's master, powering it off before switching roles takes down the whole stack's control plane at once, not just the one member you meant to replace.
SAFER PRACTICECheck Role before you touch the power. If it reads Master, run slave switchover first and confirm the role has actually changed before proceeding — the same discipline this site's dangerous commands checklist applies to any command that can take a whole device down at once.
RISKdisplay device only confirms the model (Type). The source documentation is explicit that the new unit's version and patch package, visible in display startup, must be identical to the faulty unit's — a same-model unit running a different version or patch can still fail to join cleanly.
SAFER PRACTICECheck both commands before you touch a cable — display device for the model, display startup for the exact startup system software and patch package — and correct any mismatch on the new unit before it goes anywhere near the stack.
RISKThe controller's replace workflow matches the new unit to the faulty one by ESN. Adding the new device to any site during the initial add-device step turns it into an ordinary managed device instead of a staged replacement candidate, and the replace operation won't find it.
SAFER PRACTICEWhen adding the new unit on the controller, set Site to “do not join a site” every time, and don't assign a site later in the process either — the replace step depends on that unmanaged state.
RISKThe source documentation's own warning on stack slot renumber and stack slot priority is unambiguous: frequent changes to either value can split the stack. This isn't a cosmetic renumbering command.
SAFER PRACTICEChange slot ID and priority once, deliberately, to match the faulty unit's known values from the controller — treat both commands as a one-time correction during this replacement, not something to adjust repeatedly while troubleshooting.
RISKIf the License has no room for one more managed device, the controller can't bring the new unit under management — the replacement stalls at the add-device step, not at the physical swap, and that's easy to discover too late if you check capacity after the faulty unit is already powered off.
SAFER PRACTICEConfirm License headroom before you power anything off. If there's none, expand the device-management License first — a five-minute check that prevents the faulty unit sitting powered-off with no replacement ready to take its place.
Back up the stack's current configuration before you start — a plain save on the stack captures the running configuration, and it costs nothing to have that snapshot on hand if any step below needs to be unwound before the faulty unit is even powered off.
Pulled straight from the field — the ones worth having an answer ready for.
Not per this procedure — the source documentation requires the replacement unit's model, version and patch to match the faulty unit exactly. If none of your spares match, the safer path is sourcing a matching unit rather than forcing a mismatched one into the stack.
Powering it off directly would take down the stack's control plane along with the one member you meant to replace. Run slave switchover first, confirm the Role field has changed, and only then continue with the replacement.
Only if the stack uses ordinary cables for stacking. Dedicated stack cables or a stack card need no such configuration step at all — check which type this stack uses before assuming either way.
The controller won't bring the new unit under management until there's room. Expand the device-management License first — this is worth checking before the faulty unit is powered off, not after.
Two independent checks: display device on the stack should show every member as Normal and registered, and the controller should show the new unit registered and online, matched by the ESN you entered when adding it.
Not in this procedure — the faulty unit comes down before the physical swap. That planned, brief loss of one member is exactly what the stack's remaining members are built to absorb; it isn't the same as an unplanned full-stack outage.
This note follows the stack-member replacement procedure from the high-density campus network solution's maintenance documentation, covering switches managed by iMaster NCE-Campus through the controller's add-device and replace workflows shown here. It assumes a same-vendor, same-model, same-version replacement — cross-vendor stack replacement isn't covered, and isn't supported by this workflow. It also doesn't cover replacing more than one member at a time; do these one at a time, verifying each before starting the next.
Send us the output of display device and display startup from both the faulty unit and the replacement, plus the controller's stack version/patch view, and we'll help you confirm the match before you power anything off.