last person joined: 21 hours ago 

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

HP 3800 Backplane stacking - Commander election

Jump to Best Answer
  • 1.  HP 3800 Backplane stacking - Commander election

    Posted Aug 09, 2019 04:45 AM



    I'm a little confused about the election of a new commander.

    The following output shows the stacking information.

    Member 1 goes down. Which switch becomes the commander and why.


    Regarding to the guides:

    1. The switches with the highest Stack Revision are discovered.

    2. The switch with the highest configured priority is selected as the Commander.

    3. If there are switches with the same “highest” priority, the switch that was the previous Commander is selected.

    4. If no switches were previous commanders, the switch that was the previous Standby is selected.

    5. If none of the above conditions apply, the switch with the lowest MAC Address is selected as the Commander.

    BUT, what is the stack revision? Do i see the revision in this output?

    For me, it could be that member 2 becomes commander because its standby and highest ID, but member 3 has the highest prio.. Can someone help me?

  • 2.  RE: HP 3800 Backplane stacking - Commander election

    Posted Aug 09, 2019 05:13 PM

    @Doelsner wrote: BUT, what is the stack revision? Do i see the revision in this output?

    i could be wrong...but I think that with "Stack Revision" they wanted to say really "Software revision"...so on a Stack the most updated Switch and the one with the highest configured Priority will win the election (in the most simple case).

  • 3.  RE: HP 3800 Backplane stacking - Commander election
    Best Answer

    Posted Aug 12, 2019 12:39 PM



    In this scenario, when member 1 (Commander) goes down, member 2 (Standby) will become the new Commander. (The Standby will always assume the Commander role during a failover.)


    Where priority comes into play is when multiple members (or the entire stack) are rebooted or powered up after an outage — the member with the highest priority becomes Commander, and the second highest priority becomes Standby. If there is a tie (multiple members have the same priority), rules 3 through 5 are applied as tiebreakers until there is one Commander and one Standby. 


    As for the Stack Revision — I believe this is referring to the version of the stacking protocol running on each switch (which is an internal value not visible in any switch 'show' command), and is associated with the version of switch software running on that switch.


    If the stack is booting for the first time with stacking modules installed and cables connected, the switch with the highest stacking protocol version is chosen as the initial Commander, and all other members are automatically updated using the Commander's software image, if possible. (In some cases, if a switch is running a software version one or more major releases behind the version running on the Commander, it will not be automatically updated and will need to be updated manually before it is able to join the stack.)

  • 4.  RE: HP 3800 Backplane stacking - Commander election

    Posted Aug 13, 2019 07:25 AM

    Thank you very much! I think, the confusing thing for me was, not to read the first step clearly. It says "The highest stack revision IS DISCOVERED" not the highest stack revision is used in THIS scenario.


    So Switch 3 would only become commander, if the whole stack has been rebooted?

  • 5.  RE: HP 3800 Backplane stacking - Commander election

    Posted Aug 14, 2019 11:16 AM

    That is correct, though you may also be able to make member 3 the Commander by performing a couple of manual failovers (using the redundancy switchover command), rather than rebooting the entire stack — member 3 should assume the Standby role after the first failover, then once member 1 rejoins the stack after rebooting, a second failover would result in member 3 becoming the new Commander.


    That said, the stack will operate essentially identically regardless of which member is the Commander, with the only significant exceptions being console port and OoBM behavior — the former will redirect serial console access from a non-Commander member to the Commander across the stacking plane, which may cause terminal sizing issues (as the switch cannot properly detect the size of the terminal window when redirected, as it can for a direct serial connection). Assigning a global OoBM IP addresses the latter, so that the same OoBM address can be used no matter which member is the Commander.