Wired Intelligent Edge

I had a problem in a 5412R switch that was a part of a VSF stack and I wanted to reboot it.

However, when programming a reboot (using the reload at command), I can only apparently reboot the switch with a commander role (and sadly, the switch I wanted to reboot was the other one)

Is there any way of rebooting all the VSF stack or a member of a VSF stack that is not the commander?

You would try to force a redundancy switchover so the actual VSF Member with the Commander role will reboot to let the other VSF Member with Standby role to take the Commander role as a result of the switchover...once in this new status then reload that new Commander...but, as you understood, the redudancy switchover approach is equivalent to the reload approach in case of a two members VSF deployment (and Aruba 5400R zl2 is necessarily a two-member VSF stack).

IIRC probably, since you're trying to operate on the actual VSF Standby member and not on the actual VSF Commander, a vsf member 2 shutdown command would work without causing any VSF Split scenario because, if that command is accepted, the VSF Standby member with VSF Id = 2 will power off and it will be there just one active fragment made of your VSF Commander (you have VSF Split mitigation mechanism in operation, isn't it?). Powering off is not like just rebooting...but, coupled with a cold boot, it could be used to simulate a warm reboot.

In this case, though, as the intended behavior is either a simultaneous reboot of the full VSF fabric or reboot of a non-Commander member (for which there is no specific command provided), the boot system command would be appropriate. Neither reload nor redundancy switchover would be as useful, as they will only result in triggering a failover to the Standby by rebooting the Commander; multiple uses of the command would be required, making a full fabric reboot far more efficient. The vsf member x shutdown command would definitely not be recommended here as this precludes a restart of the affected member entirely until an operator can manually reset or power-cycle the member locally.

---

@Matthew_Fern wrote:

In this case, though, as the intended behavior is either a simultaneous reboot of the full VSF fabric or reboot of a non-Commander member (for which there is no specific command provided), the boot system command would be appropriate. Neither reload nor redundancy switchover would be as useful, as they will only result in triggering a failover to the Standby by rebooting the Commander; multiple uses of the command would be required, making a full fabric reboot far more efficient. 

---

That's correct. So the first choice is a full VSF fabric reboot...in the end driving a specific VSF member to reboot looks not an easy task.

---

@Matthew_Fern wrote: The vsf member x shutdown command would definitely not be recommended here as this precludes a restart of the affected member entirely until an operator can manually reset or power-cycle the member locally.

---

Yeah, since the OP initially didn't told that power-cycling the relevant member was necessarily an out-of-question approach (clearly that will be a maintenance operation to be performed necessarily on site and with a technician front of the VSF)...it is indeed a possible way...my two cents: if I can't perform a reboot because it is denied by software (or because it is difficult to achieve) but I can do a controlled software driven power-off followed by a manual driven power-on...that sequence is like (or, sometime, is better than) doing a software driven reboot. Isn't it?

Thank you for your answers

The boot system command was what I was looking for.

I guess that i could schedule it with a job to reboot both 5412R switches in the night so the reboot has a minimal impact (ex: job example at 21:30 "boot system"). Am I right?

About the "redundancy switchover" proposal: is it possible to do it without rebooting the Controller? If the 5412R could switch roles without any downtime, that could also be a good solution in order to only reboot a non-commander switch.

Either reload or redundancy switchover will trigger a reboot of the Commander as part of the failover process.

Is there a specific reason that you're requiring the stack to reboot on a regular basis? This is clearly not a normal situation as these switches should be able to operate pretty much indefinitely without rebooting, so if there's an underlying issue serious enough to require regular reboots of one or more stack members, it would almost certainly be more prudent to address that as soon as reasonably possible.

Alright, thanks.

No, I dont plan to reboot the stack on a regular basis (in fact before this reboot the switches had an uptime of several months).

I also wanted to have a better understanding about how it works because I saw no mention of rebooting all the stack or a non-commander switch in the VSF guide (since reload only reboots the commander), and sometimes you need to reboot a switch for whatever reason.

Thank you for your answers.