I looked over some of the release notes of the 17.12.X version. There is no explicit explanation of the boot process for a switch stack, but the upgrade process does seem to indicate that the install add file command will automatically reboot the primary switch, and will wait for all other switches in the stack to reboot as well:
Preparing to autoboot. [Press Ctrl-C to interrupt] 0
boot: attempting to boot from [flash:packages.conf]
boot: reading file packages.conf
#########################################################################################################################################
#########################################################################################################################################
Waiting for 120 seconds for other switches to boot
Switch number is 1
All switches in the stack have been discovered. Accelerating discovery
<output truncated>
Note: The system reloads automatically after executing the install add file activate commit command. You do not have to manually reload the system.
This is relatively conclusive proof that the reboot takes place for all devices at the same time and thereâs no option to make the switches reboot in a staggered fashion.
In any case, even if you could stagger the reboots, you still would not have zero downtime, because any hosts connected to one switch would go down when it reboots, and then any hosts on the other switch will also go down when that switch reboots. Does that make sense?
A quick question, what is the difference between a standby and a member switch in terms of state and configuration? I know that the standby switch can take over the active switchâs role but apart from that, does its configuration or state differ in any way in comparison with a member switch? Theoretically, could a member switch also take over the active role without any issues?
A standby switch is one that is in a âhot-standby stateâ. This means that it has full synchronization of the running configuration, control plane protocols (OSPF, EIGRP etc) and MAC/ARP tables. As the active switch updates these constructs in its normal operation, the standby switch gains real-time updates on all of these, so that in the event of a failure of the active switch, the standby switch can assume the role without any service interruption.
Member switches donât have this live update of synchronized structures. Member switches only have a synchronized copy of the running configuration.
Now having said that, when the active switch fails and the standby switch takes over as the new active, the stack automatically promotes one of the remaining member switches to become the new standby switch.
In order for a member switch to have to immediately take over as active switch, both the current active and standby switches must fail at the same time. If that happens, there will be a temporary loss of the control plane, so there will be an outage. The remaining member switches would initiate a stack master election, and the newly elected active and standby switches would have to rebuild the control plane constructs in order to get back to full operation. So no, a member switch could not take over without any disruption. It would eventually take over but with a substantial network interruption. Does that make sense?
