Wired Intelligent Edge

Hello, Airheads, 

Adding this post here to share the content of the Airheads Technical Webinar we delivered on, September 25th on LSwitch Stacking – ArubaOS Switch For those who could not attend the session please find below:

- Webinar Recording:

https://attendee.gotowebinar.com/register/3231015361901472001

 - Webinar Slides:

Please note that you can find additional on-demand technical webinars on our Airheads webinar repository page.

As well, the webinar calendar up to December 2018 is available here. 

Please feel free to leave any additional comments and questions you may have below. We will make sure to answer them as soon as possible.

Attachment(s)

Switch Stacking – ArubaOS Switch.pdf   12.48 MB 1 version

Hi Cristina.
As I can see, there are two ways of stacking: backplane and front plane.
For any of them, is it possible to add a new member or withdraw a failing member without impacting the service (e.g. without restarting the stack or any member and stop forwarding frames)?

Thanks in advance for your answer

Pedro

Hi Pedro, 

If the devices are already in a stack, it will not affect normal stack operation when adding a device.  However, if the stacking hardware is not installed into the backplane stacking switch, you will need to enable stacking which will cause a reboot.  The same is true with VSF, when VSF is first configured, it will reboot the switch.  When adding a VSF member to an existing VSF stack, it will not affect the existing VSF members.

The steps on page 343 in the Advanced Traffic Management Guide shows how to add a new member to the stack.  It does not have an effect on stack operation.

https://support.hpe.com/hpsc/doc/public/display?docId=a00050236en_us

With regards to VSF, the procedure is the same and you would follow the same steps as when deploying.  That can be found in the 2930F Management and Configuration Guide on page 738.

https://support.hpe.com/hpsc/doc/public/display?docId=a00050273en_us

Regards, 

Justin

Hi Justin,
Let me see If I understand the procedure of adding a new member to an existing stack.
Let´s say we have a stack of 3 switches 2930M (SW1, SW2 and SW3) in a ring topology using the backplane stackig module (JL325A) with all 1m stacking cables in place for recundancy.
Suppose I want to add a new member (SW4). The procedure mentions to provision the stack for the SW4 switch, power on the SW4 switch, install the stack module in the SW4 switch, perform "stacking enable" command in SW4, wait until the SW4 switch reboots (it does not says that the stack will reboot), and finally, confirm the new switch (SW4) is member of the stack excecuting the "show stacking" command.
Up to here, the frame forwarding process of the already stacked switches is not affected. Just the new added switch needs a reboot.
Is that correct?

The same is true for VSF.

Now, you have talked about "adding" a new member to the stack. What about removing a failing switch from a stack, does it affect the service of the working ones?. I have read the procedure for removing a member, the standby or the commander, and I do not see that the working switches in the stack need to reboot or lost service. Please confirm that this is correct.

Thanks in advance for you support

Have a great day

Pedro

Hi Pedro, 

That's correct in both cases, traffic will not be affected on the other members of the stack.  In a stack the traffic will stay local to the stack member as much as possible before going over stacking links.

The procedure you mentioned from the manual is the recommended safest way since it requires that switch with that specific MAC address to be added as the stack member in that specific postion of the stack.

Justin

Took a bit of time but here is the webinar Q&As.

Switch Stacking – ArubaOS Switch Q&A

Q1: What do you mean by "reliability"? are the front panel ports not reliable then?

A1: Both are reliable

Q2: Can I mix different models an versions of Switch?

A2: Recommended to have same model and version, even if you have a different version the added switch would download from commander

Q3: Does a Firmware Version be propagated by the Commander?

A3. Yes

Q4: How is a Firmware Update done?

A4. Once you upgrade the stack the commander will first download the firmware and then once you issue reboot the other members of the stack would also download the firmware from commander

Q5: on an existing stack, is it possible to see if the method is deterministic, or plug and go? (relevant to page 18)

A5. There is no show command for now

Q6: can I use different model switch in stacking

A6. No

Q7: in stacking how password recovery process

A7. Same as in a standalone one; but the steps to be performed in the stack commander

Q8: firmware upgrade how it will process like first member then standby after thatcommander ?

A8. Firmware would be downloaded by commander first and then by standby/members

Q9: We have a ring topology and we configured with deterministic method, so we have a commander and we have a standby.

If there is a failover event we experienced that if the old commander comes back again with the highest priority it doesn't get back

automatically the commander role. But If we reboot the actually commander, the old commander (with the highest priority) get back the commander role.

It is the same behavior with standby members.

A9: In the standby case during its reboot it will take over a role as one of the member, because the next member in the stack will content for the standby election which would chose that role for standby.

Only if the whole stack is rebooted the standby will retain the role.

Is it a normal behaviour? So After a failover event we always have to reboot the actual commander and standby switch to stand back to the original state?

If you need actual commander and standby back to its role, you need to reboot the current commander and standby.

Q10: We have an other question related stacking. After the failover when all of the switch working again one of the led on the switch is still blinking. We checked the cli and everything seams ok but the led is still blinking. Do you know why this led is blinking or how can we terminate this blinking behavior? (without a reboot) . Sorry I forgot that there are 7 member of the stack for the first question

A10: We need to know which LED light was blinking, any specific port in questions or status LED?

Have to verify if the member is stable and there shouldn’t  be continuous blinking if the stack is stable. You may see all LED lights flashing during the election process

Q11: How to restart a stack member without restarting the entire stack?

A11. #boot member <member id>

Q12: If a member has a higher firmware as the commander when joining the stack - will it downgrade it's firmware accordingly?

A12. Yes it will downgrade the firmware from the commander

Q13: In the mesh they are three equivalent paths if the connection from 2-3 is broken:

2-1-3

2-5-3

2-4-3

Why the stack choose 2-5-3 as the best path?

A13. The path 2-5-3 is only for representation. It can be any among the equivalent paths mentioned above

Q14: You mentioned some slides before that a member switch does not hold any configuration. So what configuration is removed when removing a member from the stack?

A14. All configuration irrespective of stacking configuration

Q15: When members are renumbered for whatever reason - will the configuration adjusted accordingly? So if I had a specific config on port 1 on member 1 and renumbered member 1 to 4 - will the configuration then "moved" to port 1 of member 4?

A15. No. A re-number is possible only through “stacking member <member number> remove” command. This command removes the config associated with the member also. So, in the example above, when member 1 is removed, the specific config on port 1 of member 1 will be removed. So the config will not be “moved” if the removed member 1 is later provisioned as member 4 in the stack.

Q16: How is "greater fragment" decided when a stack with an even number of members is broken exactly in the middle (leaving to fragments with 2 members at a 4 stack as example)

A16. The fragment which has a commander will be decided as the greatest commander (Active fragment)

Q17: Why would one need to change the Member ID's? What impact do they have on the Stack? I don't see any reason because Commander and Standby are defined by Priority Number

A17. There is no direct re-number option. There is a command to remove a stack member (like “stacking member 3 remove”). This removes all the configuration corresponding to this member also. This removed member can be added as another member with provision command (like “stacking member 4 type <J number> mac-address <MAC address>”).

The aim for the member remove and provision commands mentioned above is to remove and add members to the stack; not to re-number them.

Providing some additional info.

To replace a faulty switch with retaining the config, the switch should be disconnected from the stack first. Then provision another switch of same J number in the stack using command “stacking member <member number> type <J number>”. Then make the stacking connections and power on the replacement switch.

Q18: In the previous slide, the route if a link fails doesn´t look like optimal route... :(

Slide 9, the shortest route should be 2->3->4, the 2->1->2->3->4 is larger

I'm talking about the right picture

A18: I agree with that, the picture is stating when it tries to reach 4 it sense the link to 4 is down then it chooses the best path which is 2->3->4

After the link 1-4 is broken, 1 will inform 2 about this. The path in 2 will be re-programmed after getting this info. After reprogramming, the packet will directly go as 2-3-4.

Q19: In regards to the deterministic methods, is it member 1 which is elected Commander?

A19. Yes

Q20: For what is priority used in stack member configuration?

A20. It is to decide which one should be commander, standby & member when setting up deterministic method.

Q21: How to minimise client data traffic interruption during a stack upgrade?

A21. Upgrade needs to done in scheduled down time and there is no method to minimize it since the entire stack/switch would go through reboot process during the upgrade