How to replace a 2920 stacked switch

[Stefano Colombo]

Hello all

we had a switch failure in a 2920 Stack and received a replacement.

I wonder what are the correct steps to replace it without causing downtime.

The stack is as follow

stacking
member 1 type "J9726A" mac-address 480fcf-169d40
member 2 type "J9726A" mac-address 480fcf-170900
member 2 priority 255
exit

The "survived" member is member 2

so I thought that the correct steps could be:

- remove member 1 from configuration before powering on the new switch.
 but would this remove the configuration for all the ports of member 1 as well ?

- powering on the new switch that should be taking the member 1 place

am I correct ?

can this operation cause downtime ?

thanks

SC

[akg7]

Hello,

You can refer below link, I believe it will help you:


https://www.arubanetworks.com/techdocs/ArubaOS_73_Web_Help/Default.htm#mas_guides/aruba_stack/Stack_Member_Replacement.htm%3FTocPath%3DArubaStack%7C_____7

https://support.hpe.com/hpesc/public/docDisplay?docId=mmr_kc-0114505

Thanks!

[parnassus]

Hi @Stefano Colombo, if you're going to replace the failed switch (Stack member ID 1 with SKU "J9726A" and MAC Address 48:0f:cf:16:9d:40) with another identical one (same SKU) and the failed switch was the one with the Standby role...you just need to physically remove the failed switch, insert the recovered Hardware Stacking module on the new replacement Switch (do not power it on immediately, at least not before seating the Hardware Stacking module taken from the failed unit or before seating a fresh new Hardware Stacking module if it's the case), connect the Stacking Cables (as they were connected before), pre-provision the new replacement switch from the current Commander and then power on the replacement switch (finally once reconnect Ethernet cabling).

On the Commander (the one that survived has Priority 255 so it should be the Commander of the fragment) pre-provision the new replacement switch by executing the below command:

stacking member 1 type J9726A mac-address <MAC-Address-of-new-replacement-switch>

All Stack member 1's configuration information is retained if the replacement happens by using the same SKU.

Have a look here (here, a repetition) and here.

[Stefano Colombo]

hello @parnassus 

thanks for your help

I think that the customer had powered on the new switch, for testing it with the old power supply, before inserting the stacking module.

Can this change all the procedure to add it to the stack ?

Before pre-provisioning the new switch with

stacking member 1 type J9726A mac-address <MAC-Address-of-new-replacement-switch>

Should I remove the old one with

stacking member 1 remove

Thanks

[Stefano Colombo]

Hello 

I've connected the replacement switch to the stack and all the interfaces on the commander went DOWN and cannot get them online again 

can anyone help with it ?

[Stefano Colombo]

I had to reboot the survived switch that had all the ports in down state.

After the reboot all the ports got back online as normal

What I'd like to understand is why that happened, procedural error or bug ?

During the replacement I was connected to the console of the new switch while was booting and saw that it recognized the firmware on the stack to be more recent and proceeded with updating it and then rebooted and joined the stack successfully

thanks

SC

[parnassus]

Ciao Stefano, how is the HP 2920 stack health now?

IIRC the replacement of a failed switch that owned the Standby (or Member) role (that is: it was the Standby or a Member of the backplane stack) should not cause the reboot of the remaining switch which has the Commander role...at least if - I'm speculating - assigned stack member priorities don't kick in addition to MAC Addresses values (both properties concurrently could cause a new-Commander election...if I'm not mistaken).

I mean, what was the initial condition when the Stack was running normally before member 1 failed?

The remove command you issued against member 1 (which was the failed one) in reality was intended to remove a stack member without proposing a replacement (as when you need to repurpose that switch - supposing it is fully operable - for use elsewhere)...so I belive it was incorrect...if the member 1 was already failed...then the procedure should not require that command:

as it is explained here (Removing a Stack member - Backplane stacking).

[Stefano Colombo]

Hello @parnassus 

The stack is working properly now.

I don't know which role was holding the failed switch however the surviving one was the commander and I don't understand why it disabled all the ports while the other one was powering on and joining the stack.

The commander had not suffered any reboot, I did it later because it was not possible to put the interfaces online , when the other member joined the stack.

The configuration has been maintained successfully

[techin]

@Stefano Colombo 

Is the issue resolved now?

[Stefano Colombo]

hello @techin 

yes , now the stacking is working properly