Wired Intelligent Edge

last person joined: yesterday 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

How switch stack commander failover works?

This thread has been viewed 10 times
  • 1.  How switch stack commander failover works?

    Posted Oct 16, 2018 09:38 AM

    Hi All,

     

    How the switch stack commander failover works?

    We set a switch stack priority to 255 to become commander and another switch priority to 254 to become standby. If the commander switch fails and reboot or lose connection with stack the standby switch will be the commander, and if the commander come back the switch with stack priority 255 not become a commander so the standby switch will remain the commander. If we reboot the standby after the switch with priority 255 came back this switch will be a commander again. I think it is not a good method.

    Is it normal working progress or is there any setting that we should set up to get back automatically the commander?

     

    Another question: If we remove a stack member from middle of the stack, for example: we have 5 switch in stack in ring topology and we shutting down the 3rd member the 2nd and 4th member's Global Status led is flashing in orange slowly (that means: A fault or self-test failure has occurred on the switch, one of the switch ports, or a fan.The Status LED for the component with the fault will flash simultaneously.) and if the 3rd switch came back the leds of 2nd and 4th switch will flash and will not stop, but if we reboot the 2nd and 4th switches the flash will stop.

    Is there any option to acknowledge this "fault" on cli or we need to reboot the switches anyway?

     

    Thank you!



  • 2.  RE: How switch stack commander failover works?
    Best Answer

    EMPLOYEE
    Posted Oct 16, 2018 03:25 PM

    Greetings!

     

    The failover behavior you described is as intended — when a failover occurs, the standby becomes the new commander and retains that role, even after the old commander reboots and rejoins the stack. This is done to minimize unnecessary reboot cycles, as rebooting a stack member takes down all ports on that member until the reboot is complete. The priority setting comes into play when a stack election occurs, as happens if both the commander and standby (or an entire stack) has rebooted at the same time; it will not cause the standby to relinquish the commander role when the original commander rejoins.

     

    Keep in mind that there is little practical difference in stack operation with the standby operating as the commander — it retains the same configuration, and as long as all stack members are operational, it behaves identically no matter which member is operating in that role. (One of the only operational differences can be observed when connecting to a non-commander stack member via serial console — the serial console redirect function causes the session to operate with a set console height and width, ignoring the settings used by the terminal application being used.) 

     

    With regards to the second question — depending on the switch model, either the switch status LED (for 2930F/5400R VSF stacks) or the stacking status LED (for 3810/2930M backplane stacks) are expected to flash to indicate that there is a stacking-related issue — either a link is down, or one or more stack members are missing. The LEDs should return to normal once the issue has been resolved; if you are not seeing this behavior, please post sanitized event logs and the results of show stacking or show vsf so we can determine if this is a bug.