The 2920 series switches from HPE/Aruba has a special feature that no other switches in the old ProCurve/E-Series line-up has; dedicated stacking interfaces. On other HPE switches, stacking merely facilitates “simplified” management, by allowing you to manage any switch in the stack from the stack commander’s CLI. On the 2920 series however, you can use dedicated stacking interfacing, giving you 2 20 Gbps links to other switches in the stack and merging two to four switches into one coherent switch. This is quite similar on how stacking works on some Cisco models, but the specialized stacking interfaces gives you higher speeds between the members. In this article, I’ll show you have to set up the commander switch and how to add switches to the stack once it’s created. I’ll also go into how it affects the configuration of the switches, which is quite crucial if you want to stack switches that are already in production.
Before you get started
You need 2, 3 or 4 2920 series switches to form a stack. Additionally you’ll need a stacking module for every switch in the stack, and stacking cables. The stacking cables can be configured in two different topologies, chain or ring. Chain topology connects the switches in a long chain, which has the benefit of using one less stacking cable, but gives you no redundancy should a switch fail or a cable go bad. Ring topology adds a cable that connects the last switch in the chain to the first one, forming a loop. Personally I’d recommend sticking to the ring topology, since the stacking cables are very inexpensive components compared to the switches and stacking modules, and you only need one more for the ring topology.
How you start the stack is also important, and varies a bit depending on when you choose to install the modules. If you install the stacking modules before powering on the switches for the first time, they’ll automatically enable the stacking feature, and configure themselves as a member with priority 128. If you then connect the switches together using the stacking cables, they will automatically form a stack and elect a commander and standby (commander) between them. Which switch gets elected is random, but in the grand scheme of things this doesn’t matter much. I however have a bit too much OCD for that, so below I’ll show you an other way to set up the tack that gives you control over the stacking operation.
Configuring the Commander
If you powered on the switches before installing the modules, they will automatically disable the stacking feature, and will require a bit more fiddling before you can get them to form a stack. First, you’ll need to install the modules. The stacking modules can be installed with the switched powered on, but you have to reboot the switch to enable them. So, install the modules in the switches, but leave the stacking cables unconnected for now. Then issue the following command on the switch that you want to make the commander.
SW1(config)# stacking enable
This will cause the switch to ask you to confirm saving the running configuration and reboot. After the switch has booted, you can now issue the following command to check the status of your stack.
SW1(config)# show stacking
Stack ID : NO ID – will merge upon connectivity
MAC Address : d89d67-ffffff
Stack Topology : No Stack Formed
Stack Status : No Stack Formed
Split Policy : One-Fragment-Up
Uptime : 0d 0h 6m
Software Version : WB.16.01.0006
Mbr
ID Mac Address Model Pri Status
— ————- ————————————– — —————
1 d89d67-ffffff HP J9726A 2920-24G Switch 128 Commander
As you can see, you switch is member 1 in it’s own little stack and has elected itself as commander, as it’s the switch with the highest priority. Problem is, that if another switch now joins the stack, it’ll have the same default priority of 128, and you can’t be certain which switch will end up as the commander if the stack reboots (the switch that’s elected commander stays as the commander when new switches are added even though they might have the same priority). Let’s change the priority to the highest possible so that we can be certain SW1 stays as the commander
SW1(config)# stacking member 1 priority 255
Now if we reissue the command show stacking, we can see that the priority for member 1 is now 255.
SW1(config)# show stacking
Stack ID : NO ID – will merge upon connectivity
MAC Address : d89d67-ffffff
Stack Topology : No Stack Formed
Stack Status : No Stack Formed
Split Policy : One-Fragment-Up
Uptime : 0d 0h 8m
Software Version : WB.16.01.0006
Mbr
ID Mac Address Model Pri Status
— ————- ————————————– — —————
1 d89d67-ffffff HP J9726A 2920-24G Switch 255 Commander
Configuring the Standby Switch
Next, we’ll configure the standby in the stack. The standby switch acts as a backup commander, should something happen to the commander switch. The standby will only take over as commander if the commander switch fails. To configure this, you need to know the model and mac-address of the switch you intend to add as the standby, we won’t actually be connecting it before we’ve configured it. The model number that you give with the type option is the J-code for that particular switch. In my case, I’m using an identical 2920-24G switch.
SW1(config)# stacking member 2 type J9726A mac-address 7446a0-aaaaaa
This will save the current configuration. Continue [y/n]? y
When we again run the show stacking command, we can see that the standby switch has been added to the stack, even though it’s not yet connected. This allows us to configure the members of the stack beforehand, which gives use control over how the different members join the stack.
SW1(config)# show stacking
Stack ID : NO ID – will merge upon connectivity
MAC Address : d89d67-ffffff
Stack Topology : No Stack Formed
Stack Status : No Stack Formed
Split Policy : One-Fragment-Up
Uptime : 0d 0h 9m
Software Version : WB.16.01.0006
Mbr
ID Mac Address Model Pri Status
— ————- ————————————– — —————
1 d89d67-ffffff HP J9726A 2920-24G Switch 255 Commander
2 7446a0-aaaaaa HP J9726A 2920-24G Switch 128 Not Joined
As you can see, the other switch is configured in the stack with the default priority of 128, with the status of “Not Joined”.
We want to make sure that the second switch always becomes the standby, so we’ll increase the priority to some number that’s higher than 128 but still lower than 255.
SW1(config)# stacking member 2 priority 192
That’s it, now you can now connect the stacking cables and enable stacking on the second switch
SW2(config)# stacking enable
Now the second switch reboots, and joins the stack as the standby switch.
SW1(config)# show stacking
Stack ID : 0100d89d-6999af40
MAC Address : d89d67-ffffff
Stack Topology : Ring
Stack Status : Active
Split Policy : One-Fragment-Up
Uptime : 0d 1h 8m
Software Version : WB.16.01.0006
Mbr
ID Mac Address Model Pri Status
— ————- ————————————– — —————
1 d89d67-ffffff HP J9726A 2920-24G Switch 255 Commander
2 7446a0-aaaaaa HP J9726A 2920-24G Switch 192 Standby
As you can see, the second switch has now joined the stack and functions for all intents and purposes as a second module to the first switch. This might be a good time to rename the first switch to better reflect that it’s no longer an individual switch but a stack
SW1(config)# hostname SW-Stack
SW-Stack(config)#
Adding Remaining Members
After you have the commander and standby switches sorted, you can add the remaining switches to your stack. This is done by using the stacking member command to add them to the stack configuration, connecting the cables and issuing the stacking enable command on the new members to reboot them and add them to the stack.
SW-Stack(config)# stacking member 3 type J9726A mac-address 7446a0-bbbbbb
This will save the current configuration. Continue [y/n]? y
SW-Stack(config)# stacking member 4 type J9726A mac-address 7446a0-cccccc
This will save the current configuration. Continue [y/n]? y
SW3(config)# stacking enable
SW4(config)# stacking enable
SW-Stack(config)# show stacking
Stack ID : 0100d89d-6999af40
MAC Address : d89d67-ffffff
Stack Topology : Ring
Stack Status : Active
Split Policy : One-Fragment-Up
Uptime : 0d 2h 8m
Software Version : WB.16.01.0006
Mbr
ID Mac Address Model Pri Status
— ————- ————————————– — —————
1 d89d67-ffffff HP J9726A 2920-24G Switch 255 Commander
2 7446a0-aaaaaa HP J9726A 2920-24G Switch 192 Standby
3 7446a0-bbbbbb HP J9726A 2920-24G Switch 128 Member
4 7446a0-cccccc HP J9726A 2920-24G Switch 128 Member
Stacking Switches Already in Production
A big problem I had when I first started using the 2920 stacking feature was how it affects the configuration of the switches, especially the VLAN tagging of the ports. If you’ve read through this guide so far you might have noticed it already, but I’ll go through it here a bit more in detail. The switch you start off with is the switch that’s going to become the commander. This is also the switch that dictates the base configuration of the whole stack. It, for a lack of a better word, “seeds” the stack with it’s own configuration. What then happens when you add more switches to the stack is basically the same thing that happens when you add line cards to a modular switch. You gain more interfaces, but that’s it. When other switches are added to the stack, they forget their previous configuration, and all their interfaces are assigned to the default VLAN off the stack. And when you think about it, that’s perfectly logical. But this means that any information that isn’t in the configuration of the first switch is going to get lost in the process. So make sure that you have the configuration of the interfaces backed up somewhere before you start doing this.
The way I do it is by making a configuration file from the configuration files of the “slave” switches, with all the interface VLAN tagging and interface configurations. I then append the index to the interface numbers, so that they can be feed into the stack configuration.
You can divine the interface indexes for any interface from the stack configuration. When you switch over to a stack, the interface indexes change to the format [1-4]/[Interface]. The first number is the member ID of the switch in the stack, and after the slash you have the switch’s own interface index. So interface 22 on member 3 in the stack becomes 3/22 in the stack configuration. Pretty simple, right?
Resources
HPE has a quite good whitepaper that explains the different topologies and also shows you how to use the same commands as I’ve done here, but in a shorter format.
http://www8.hp.com/h20195/v2/GetPDF.aspx/4AA5-7121ENW.pdf
This post is part of a new series called Network Friday, where I explain a new networking concept every Friday and tell you have to configure it on (mostly) HP hardware. The series will mostly focus on the configuration side, as I feel there are lots of resources out there that do a fine job of explaining complex concepts, but very few that show you how to do it on your specific hardware. This series aims to address this somewhat, at least on the HP side of the fence.
Grumpy Techie 
Thank you for the input, Sebastian.
Question: Let’s say the “Commander” or any of the 4 switches in this topology is a L3 switch and does routing between 2 Vlans, e.g. VLAN1 and VLAN2. It is also is set as the default gateway for the whole network for every client. If it goes down, how can another one of the switches assume the Failover L3 gateway role for a stacking setup like this? Is it simply a matter of assigning a secondary gateway (by adding the secondary’s IP) in DHCP? Of course, the secondary switch would have to be a L3 and contain all the routes that the primary one has. Or does the secondary switch assume the role of the primary somehow?
Hello Alex!
What happens when these switches are stacked is that they are merged into one big distributed switch. As a result, it’s not any single switch in the stack that’s a “L3 switch”, but instead the whole stack. I’d wager that the stack commander handles routing in the stack under normal circumstances, and if it fails the standby switch takes over. As such, the whole stack doesn’t go down, it just looses the ports that the commander had.
Thank you much; had a 3810 fail and needed to break the stack and re-create.
Thank you very much for the guide…
Can you all change stacking priorities after the 16.04 update? I can no longer get the cli command to change priority to work under this version.
Thank you Sebastian Storholm,
In my case, I have two 2920 switches acting as core switches, stacking is configured.
Connecting them to the edges switches is by using the same port number to each edge, for example, core switch1 port#1 and core switch2 port#1 should be linked to the same edge switch to the trunk ports.
My question, how the edge will communicate with the 2 cores, both ports will have the same mac address?
Is there any need for STP or LACP configuration on the edge switch?
Connecting the 2920 switches to 2 NICs of the VMWare ESXi server is simply by having 2 NICs in the same standard vSwitch?
Hi Joe!
You’ll need to use either STP or LCAP when connecting your edge switches (otherwise you’ll get a loop) . Half of the reason for using stacking is so that you can use LCAP instead of STP, so I’d recommend using that, as you get at a lot more bandwidth out of your links. Connecting ESXi hosts is the same as connecting a host to a single switch using multiple links. Stacking on the 2920 series can be generally thought of as joining the switches together as a single switch.
Hope this helps!
Have a nice day!
Cheers,
Sebastian
Is there a way, when upgrading firmware in a stack, to reboot switches one by one and retain switch operation without downtime ( for routing and switching commander must be alive ) ? So far I see it’s not possible, because “boot system” will reboot entire stack, and whole stack will be offline for a period of time … so when using redundant cabling to and trunks to connect servers and achieve HA with stacked switches, firmware upgrade reboot will loose “high availability”.
Hi!
Not that I’m aware of I’m afraid, and all the documentation I’ve been able to find states that a reboot of the whole stack at once is the only way to update the firmware. I think it’s probably due to the fact that the stack switches need to run the same firmware to operate properly.
Cheers,
Sebastian
Is there a way, when upgrading firmware in a stack, to reboot switches one by one and retain switch operation without downtime ( for routing and switching commander must be alive ) ? So far I see it’s not possible, because “boot system” will reboot entire stack, and whole stack will be offline for a period of time … so when using redundant cabling to and trunks to connect servers and achieve HA with stacked switches, firmware upgrade reboot will loose “high availability”.
Thank you so much!
This has helped me a lot.
Cheers mate, glad it helped you!
-Sebastian
I have two 2920 switches in production. At the moment they are connected together with spf+
When I enable stacking and connect the stacking cables wihout first removing the spf+ cables, will i create a loop? Or is it possible to remove the cables later?
Hmm, it might create a bit off a mess, as the ports on the secondary switch will be in VLAN 1 after the switchover. Your best bet is to remove them before rebooting when you enable stacking. You can however install the stacking modules and cables beforehand, as the won’t do anything until you enable stacking and reboot the switches.
Cheers,
Sebastian
I’m just learning stacking your article was extremely helpful. I need to upgrade the firmware on the older switches prior to me joining. Can I upgrade the the firmware without rebooting and taking the switches?
Without taking the switches down?
Hi Renee!
Sadly upgrading the firmware always requires a reboot!
Cheers,
Sebastian
What happens to the vlans created after stacking? Also when upgrading the firmware what’s the best browser to use? I’ve tried to upgrade two through IE but it never completes. The switches are in use fully loaded with connections. Last question does both primary and secondary need to be the same firmware? I hope these are all valid questions.
Hi Renee, sorry for the late reply! The commander’s config is retained, and new VLANs are added as normal after stacking, aka. the stack behaves as a single normal switch. I’m not really sure about the browser question, I update them through the CLI using a TFTP server on my laptop. The switches should be the same firmware version before attempting stacking. Hope this helps!
Hi,
I hope you still monitor this post. If I stack four switches with the ring topology what is the best practice to set up the uplink lines on any switches.
Thanks,
Hi Hai!
I do monitor all my posts for comments, but I dropped the ball on this one a bit, so sorry for that. When you stack your 2920 switches, they essentially become one single switch, as far as the switch is conserned. However, you do need to spread the uplinks so that at least the commander and backup commander switches have uplinks, and prefferably all switches in the stack has one or two uplinks, that way you don’t loose connectivity regardless of what dies. So if you have 2 core switches that you want to connect the stack to, I’d run one uplink from each switch to each core switch, starting with the commander and backup commander switches if I don’t have the possibility to cable all 8.
Hope that makes sense!
Can I get the simple stack management capability on the newer Aruba switches as I did on previous models of Procurve, without the additional stacking modules? This was very beneficial to be able to manage multiple switches over their ethernet or SFP connections.
Hmm, the HP Procurve 2920 was a special model that actually had “real” stacking, with the stacking modules. The other Procurve devices simply had the “stacked management” that you mentioned. Newer models of Aruba should support that as well, since they run the same code as the older Procurves, and are essentially the same switches. The only ones that probably do not have the “stacked management” is the newer ones with “real” stacking. The difference is that when you use stacking modules, you’re literally bonding the backplanes of the switches together, creating a single multi-chassis switch. The “stacked management” doesn’t do anything for the switching fabric, it just bonds the management of the switches together, but they are still completely independent switches.
Isn’t it strange that HP dropped backplane stacking on newer 2930F models ? I’m still buying 2920, as long as they are available on the market 🙂
Yeah, it’s rather weird, but I think that’s the reason also, the 2920 was unique in HPs line-up, and as such they probably didn’t feel it was necessary to keep the code base running for just that one model. Also, I’ve noticed that the 2920 stacking can be quite buggy at times, and we’ve had several stacks fail, so these days I’m actually not bothering repairing the stacks if the fail completely, I just replace them with multiple 2930’s.
Any details about the fails ? I have few stacks, but no problems so far. Do you see any performance difference between 40 Gb/s back-plane stacking with old Aruba 2920 vs 10 Gb/s non back-plane stacking with 2930 ?
Thanks.
I’ve not seen any performance difference TBH, but we use them as ToR switches so the backplane does very little work anyway. I’ve seen some spectacular failures on 2920s where one member just ups and leaves the stack and won’t rejoin, as well as some times the whole stack will loose it’s configuration. I’ve never tried fixing them for more than 5 minutes through, instead opting to pull them and replace them with 2930Fs. The 2920-series seems to be quite sensitive to power issues, they can go quite wonky after a power outage fir example, only HP switches we have that does that.
We do have 6 2920 Stacks operational since January 2013 and no issues on the stacking part so far (Ring Topology – 10GBe LACP-Trunks as Uplink always spread out over at least 2 Switches). So I really need to say, that the stacking is working well.
I haven’t had a look for the Features of 2930Fs so far, but it sounds really sad, that they won’t have the real stacking any more, as we start to use them more and more cause 2920s are not longer on sale.
What’s starting pissing me off is that we had nearly 15 2920-48s till now, where always quad-stacks of interfaces stopped working with PoE (Power Enabled is “yes” but Detection Status is “disabled”) from one second to another without any reason. We had this at the end of 2017 were we enrolled our newly buyed ip-phones and needed to swap eleven 2920s (before we didn’t realise the issue, cause we had no PoE Devices in use, so the fault might have been there for years on some Switches). What i was really happy about was, that the RMA worked well – fault detected, fault reported, one Day later eleven Switches for swapping received.
Today the next switch lost 2 quad-stacks of modules at the same time – 1/13-1/16 and 1/37-1/40 as well as it did hang in an unknown state. Luckily a reboot did bring it back up, so that it was enaugh to switch the connected phones from there to other ports.
Thanks to the stacking it was really easy to swap faulty switches – I think we only needed to change the mac-address of that stacking member and the config was provided by the stack. I am a bit unsure about that, cause it was 2017 I did that, but i hope my documentation is right and it’s really working like that. Going to replace it on friday cause i am not in the mood to do this now.
Yeah, stacks are rather neat when you need them! It seems as if there might be some improvements to the 2930 series regarding stacking, but I need to get my hands on some to actually try it out!
I actually read up on this, and the new 2930M series brings back ‘real’ stacking like the 2920 series, so that’s rather neat!