We have recently begun a project to replace all of our core switches at our various remote locations. We have around 40 locations and 2 core switches for each location so, whilst not the largest undertaking, it’s an operationally significant project for a team of 1… We’ve used HP switches for a long time (we’re even still using some of the 3COM switches…) and we have a supplier that gets a good discount on these so I went shopping. Now that HPE have purchased Aruba, there’s some nicer models that we can get our hands on. We don’t have any stupidly high bandwidth requirements yet either so we’re not looking in the upper ranges, we usually stick to the SMB style switches (plus I have a hard time justifying the price increase with our use cases!).

The 2530 or 2540 is the obvious budget model if all you need is Layer 2 and some static routing. It’s the logical follow-on from the likes of the 1910/1920 of old. We’re going to cycle these into our edge when the time comes because they’ll be good workhorse devices for a few years. The 2930 model is where things get interesting for me. Also worth pointing out that the 2920 is cool but is EOL very soon so wasn’t a worthy candidate.

The 2930 splits into 2 models:

  • 2930M - Proper stacking cables, WAY higher PoE outputs, nice layer 3 features - Larger SMB Outfits - Price tag of ~£2.5k (48 port non-PoE)
  • 2930F - VSF stacking, nice layer 3 features - Smaller SMB Outfits - Price Tag of ~£900 (48 port non-PoE)

Given the fact that previously, we’ve been paying ~£200 for a HP 1920 switch, a jump to £2.5k is a bit much… The benefits of jumping to ~£900 was justifiable, however. Part of those benefits was the ability to stack the core switches.

Stacking is something that I toyed around with in my university days, using Cisco stacking cables to stack equipment in the lab. It was quite interesting and I could see the benefits of using it (easier switch swap out, better backplane bandwidth, etc). Coming into the industry and joining a company that not only wasn’t using Cisco equipment but was still using unmanaged 3COM switches, the reality was a little different to the fantasy. Due to this, I haven’t had the need to use any stacking for the last 3 or 4 years. When I saw the datasheet for the 2930F had VSF stacking, I started to do some research. The AirHeads forums are surpringly filled with decent information when it comes to this topic, so it didn’t take me long to figure out that I wanted to give this a shot. Queue the supplier sending me 3 2930F’s to test with.

Getting Started

At first, I didn’t see the option for VSF, which wsa a bit startling. Then I realised that I was on a firmware release from a a while back. It would appear that HPE/Aruba introduced the VSF options in firmware from January 2017 so if you need the firmware, search for your switch here and grab the latest. I went from 16.02.0003 to 16.06.0006 in one jump so there’s no interstitial upgrades required. Once the upgrade has been done to the Primary and Secondary BootROMs, you should be back up and running. Now, if you type

show vsf

you should get the below output.

Aruba-2930F-48G-4SFP(config)# show vsf
VSF is not enabled.

Good, this means we can begin the config! It’s relatively simple, especially for the first switch.

Aruba-2930F-48G-4SFP(config)# vsf member 1 link 1 2
All configuration on this port has been removed and port is placed in VSF mode.
Aruba-2930F-48G-4SFP(config)# vsf member 1 priority 200
Aruba-2930F-48G-4SFP(config)# vsf enable domain 254
This will save the current configuration and reboot the switch.
Continue (y/n)?

After hitting y at this prompt, the switch will reboot and you should be good to go. To explain some of these options further, domain is simply a number that you give to each set of stacks. Similar to VRRP or HSRP group IDs, basically. Do this part last because it’s the bit of config that triggers a reboot once comitted. The member key specifies which switch you’re operating on in the stack. We’ll see later on but as you add switches, you get members 2, 3 and so on. link is one I haven’t experimented with much yet, basically it seems that you can have 2 virtual ports on the VSF instance. Not sure what significance that has in terms of bandwidth, I’ll investigate that later. The number afterwards is simply the port number that you want to use to stack the ports together. From what I’ve research you can have multiple physical ports on one virtual link but as I mentioned, I haven’t looked much into that yet.

Post-reboot, you’ll have a new prompt

Aruba-VSF-2930F(config)#

which should indicate that VSF is live. You’ll also have an orange light on the port that you set up in the link command.

If you need further proof, the show command has some nice output.

Aruba-VSF-2930F(config)# sh vsf

 VSF Domain ID    : 254
 MAC Address      : 941882-xxxxxx
 VSF Topology     : No Stack Formed
 VSF Status       : Active
 Uptime           : 0d 0h 5m
 VSF MAD          : None
 VSF Port Speed   : 1G
 Software Version : WC.16.06.0006

 Mbr
 ID  MAC Address       Model                                 Pri Status
 --- ----------------- ------------------------------------- --- ---------------
 *1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander

This confirms the Member ID, Priority and Status of the switch. I’d recommend changing the hostname at this point to reflect that you’re going to be stacking things, otherwise it may get confusing in the future.

Aruba-VSF-2930F(config)# hostname "VSF-Test"
VSF-Test(config)#

Adding A Switch

There’s more than one way to skin a cat when it comes to adding a switch to a VSF fabric. If you have a switch of the same model/firmware as your current commander (not sure how strict that is, see HPE/Aruba for more details), you can just plug the new one into the link port! The new switch will get the VSF config and reboot, then it will join the VSF fabric!

Aruba-2930F-48G-4SFP#
Rebooting to join VSF fabric with domain ID 254

Once rebooted, you will be greeted with the commander’s login prompt.

VSF-Test(config)#

Again, the show command will confirm this.

VSF-Test(config)# sh vsf

 VSF Domain ID    : 254
 MAC Address      : 941882-xxxxxx
 VSF Topology     : Chain
 VSF Status       : Active
 Uptime           : 0d 0h 17m
 VSF MAD          : None
 VSF Port Speed   : 1G
 Software Version : WC.16.06.0006

 Mbr
 ID  MAC Address       Model                                 Pri Status
 --- ----------------- ------------------------------------- --- ---------------
  1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander
 *2  e0071b-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    128 Standby

There’s another couple of interesting things about this screen that you’ll notice. We have a switch with ID 2. The star indicates which switch you’re consoled in to, if you are indeed consoled in. You can also see that by default, members join the stack with a priority of 128. We’ll change this shortly. You can also see that the VSF topology is set to chain by default. You can have either chain or ring topologies for your stacking. If you’ve done any stacking before, you’ll be familiar with the concept but if not, chain is just like daisy chaining your switches together whereas ring gives you the ability to have 3 or more switches set up in such a way that if one of the middle switches fails, you’ll still be able to use all of the other switches. In a chain you would lose every switch in the chain beyond the failed switch.

We’d better change that priority as well, because it’s usually better to have control of these things.

VSF-Test(config)# vsf member 2 priority 190

Replacing a Stack Member

An interesting scenario that I had was replacing a stack member. As the operational overhead of configuring a new switch was one of the reasons for looking at stacking in the first place, this was a fairly key test. If we look at the running config of our VSF fabric now we get the following.

hostname "VSF-Test"
vsf
   enable domain 254
   member 1
      type "JL260A" mac-address 941882-xxxxxx
      priority 200
      link 1 1/2
      link 1 name "I-Link1_1"
      link 2 name "I-Link1_2"
      exit
   member 2
      type "JL260A" mac-address e0071b-xxxxxx
      priority 190
      link 1 2/2
      link 1 name "I-Link2_1"
      link 2 name "I-Link2_2"
      exit
   port-speed 1g

Besides the link 1 and 2 thing which irks me (no vsf member 1 link 2 to remove that by the way), we can see that each member appears to be bound by a MAC address. This posed an interesting question as to what would happen if we swap out a failed stack member with a new switch. Let’s find out!

Firstly, we’re greeted by the orange light over the VSF port again. We also get an orange heatbeat symbol!

The switch is clearly quite sad that we’ve unplugged it’s stack buddy. If we check the logging with sh logging -r we can see some more info.

I 01/01/90 00:36:35 04992 vsf: ST1-CMDR: VSF port 1/2 is down
I 01/01/90 00:36:35 03271 stacking: ST1-CMDR: Topology is a Standalone
I 01/01/90 00:36:35 03272 stacking: ST1-CMDR: Stack fragment active
W 01/01/90 00:36:35 03258 stacking: ST1-CMDR: Standby switch with Member ID 2
            removed due to loss of communication
I 01/01/90 00:36:35 04992 vsf: ST1-CMDR: VSF link 1 is down
I 01/01/90 00:36:35 04992 vsf: ST1-CMDR: VSF port 1/2 is in error state

Luckily, I’ve got a 3rd switch ready to jump into the fray! After plugging the new one into the same port and waiting for it to reboot, we get some more log info.

I 01/01/90 00:43:11 00539 stacking: ST1-CMDR: Initial sync to standby starting
I 01/01/90 00:43:10 00256 ports: ST1-CMDR: Port 3/2 is reserved for VSF use
W 01/01/90 00:43:10 03270 stacking: ST1-CMDR: Topology is a Chain
I 01/01/90 00:43:10 02555 chassis: ST1-CMDR: Co-processor Ready
I 01/01/90 00:43:08 03125 mgr: ST1-CMDR: Startup configuration changed by SNMP.
            New seq. number 5
I 01/01/90 00:43:08 03803 chassis: ST1-CMDR: System Self test completed on
            3/1-52
W 01/01/90 00:43:08 03270 stacking: ST1-CMDR: Topology is a Chain
I 01/01/90 00:43:07 03279 stacking: ST1-CMDR: Member 3 (e0071b-xxxxyy) chosen as
            standby. Reason: Only available standby
I 01/01/90 00:43:07 04992 vsf: ST1-CMDR: VSF link 1 is up
I 01/01/90 00:43:02 04987 vsf: ST1-CMDR: VSF link 1 up: Peer has mac
            e0071b-xxxxyy
I 01/01/90 00:43:02 04988 vsf: ST1-CMDR: VSF link 1 port 1/2 up: Peer validated

Looks like we’re syncing the initial config which is always nice. The major problem that I can see here is that Port 3/2 is reserved for VSF use. Now, that first number indicates the chassis number, in VSF that would be the same as our member ID. Previously, we only had 1 and 2, now we appear to have a 3rd… Looking at the show command, we get the bad news. The eagle eyed amongst you will also notice that I’m masking the MAC address with y’s for the 3rd switch. This will continue going forwards so that we know which switch is which.

VSF-Test(config)# sh vsf

 VSF Domain ID    : 254
 MAC Address      : 941882-xxxxxx
 VSF Topology     : Chain
 VSF Status       : Fragment Active
 Uptime           : 0d 0h 46m
 VSF MAD          : None
 VSF Port Speed   : 1G
 Software Version : WC.16.06.0006

 Mbr
 ID  MAC Address       Model                                 Pri Status
 --- ----------------- ------------------------------------- --- ---------------
 *1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander
  2  e0071b-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    190 Missing
  3  e0071b-xxxxyy     Aruba JL260A 2930F-48G-4SFP Switch    128 Standby

Hmm… If you remember the running config output from earlier, you’ll remember that the MAC address was set as a command. Let’s give that a try.

VSF-Test(config)# vsf member 2 type "JL260A" mac-address e0071b-xxxxyy
This will save the current configuration. Continue (y/n)?  y
A switch with the specified MAC address already exists.

Oops, no joy there. The list of options available for the VSF member isn’t extensive either.

VSF-Test(config)# vsf member 3
 link                  Create an VSF link on the specified member.
 priority              Assign a priority to the specified VSF virtual chassis
                       member.
 remove                Erase the VSF virtual chassis member configuration.
 shutdown              Shut down the VSF virtual chassis member.
 type                  Configure the family of the VSF member-switch being
                       provisioned.

Now, as we’re replacing a member that should have configuration on, we can’t just remove member 2 and re-add it. Here’s the cleanest way I’ve found to do this (pro tip: for future break fixes, don’t get this far. Have the break/fix engineer swapping out your kit give you the MAC of the new switch before plugging it in, that way you can do this without the extra steps).

  1. Remove the new member with vsf member 3 remove. You’ll get a complaint from the switch but such is life.

    The specified VSF virtual chassis standby member will be removed and
its configuration will be erased. The resulting configuration
will be saved. The VSF standby member will be shutdown. Continue (y/n)? y

  2. Now you should be able to run the vsf member 2 type "JL260A" mac-address e0071b-xxxxyy command that failed earlier. Your status will show as provisioned in sh vsf.

    ID  MAC Address       Model                                 Pri Status
--- ----------------- ------------------------------------- --- ---------------
*1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander
 2  e0071b-xxxxyy     Aruba JL260A 2930F-48G-4SFP Switch    190 Provisioned

  3. Have a kind human (or break/fix engineer, whatever is available) hard reboot the new switch. Not ideal, I’m aware. Short of separating the 2, manually connecting to the new switch and factory resetting it, this is the best way I’ve found.

  4. Welcome your new stack member into the fold!

I 01/01/90 01:04:41 00539 stacking: ST1-CMDR: Initial sync to standby starting
I 01/01/90 01:04:40 00256 ports: ST1-CMDR: Port 2/2 is reserved for VSF use
W 01/01/90 01:04:40 03270 stacking: ST1-CMDR: Topology is a Chain
I 01/01/90 01:04:40 02555 chassis: ST1-CMDR: Co-processor Ready
I 01/01/90 01:04:38 03803 chassis: ST1-CMDR: System Self test completed on
            2/1-52
W 01/01/90 01:04:38 03270 stacking: ST1-CMDR: Topology is a Chain
I 01/01/90 01:04:38 03125 mgr: ST1-CMDR: Startup configuration changed by SNMP.
            New seq. number 7
I 01/01/90 01:04:38 03279 stacking: ST1-CMDR: Member 2 (e0071b-xxxxyy) chosen as
            standby. Reason: Only available standby
I 01/01/90 01:04:38 04992 vsf: ST1-CMDR: VSF link 1 is up
I 01/01/90 01:04:33 04987 vsf: ST1-CMDR: VSF link 1 up: Peer has mac
            e0071b-xxxxyy
I 01/01/90 01:04:33 04988 vsf: ST1-CMDR: VSF link 1 port 1/2 up: Peer validated

 ID  MAC Address       Model                                 Pri Status
 --- ----------------- ------------------------------------- --- ---------------
 *1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander
  2  e0071b-xxxxyy     Aruba JL260A 2930F-48G-4SFP Switch    190 Standby Booting

 ID  MAC Address       Model                                 Pri Status
 --- ----------------- ------------------------------------- --- ---------------
 *1  941882-xxxxxx     Aruba JL260A 2930F-48G-4SFP Switch    200 Commander
  2  e0071b-xxxxyy     Aruba JL260A 2930F-48G-4SFP Switch    190 Standby

Now you can continue on with your day, safe in the knowledge that the P1, 4 Hour Fix call you were working on is resolved. Good Job!

Word To The Wise

The smart way to do this is to get the break/fix engineer to phone you before they get to the site. Then, they can provide you with the MAC address from the side of the box, as seen below.

That way, you can run the vsf member 2 type "JL260A" mac-address e0071b-xxxxyy command well before there is ever the mention of a 3rd member.