Aruba 2620 firmware upgrade order

[Phyrstorm]

I have 65 Aruba 2620 switches deployed in the field that I have recently taken over part of the support for.  I have software versions ranging from RA.15.05.0006 to RA.16.02.0010.  I have been tasked on getting them all upgraded to the latest and greatest version of the software RA.16.02.0014.

I know that I will probably have to incrementally update the versions since there are so many in between but I can't find much information on what versions are required for each update.  All of these switches are either J9623A or J9626A, the 24 or 48 port versions so the software is the same on them.

I know upgradeing to 16.02.0014 recommends at least a 15.17 version or higher but further back then that I can't find any information beyond that.  Am I safe to upgrade the older ones to the 15.17 then jump straight into 16.02.0014 or are there other increments I need to follow before updating to 15.17 on these older versions?

[parnassus]

---

Phyrstorm wrote: I know upgradeing to 16.02.0014 recommends at least a 15.17 version or higher but further back then that I can't find any information beyond that.

I don't believe (where you have found that bit of information?).

I think BootROM was initially named on RA.15.12.0016 Release Notes document (so RA.15.12.0016 used BootROM RA.15.10) - before there wasn't any reference about BootROM - so, eventually, I will use that software version as an interim update step before going to the latest RA.16.02.0014 (which uses BootROM RA.15.11)...doing things that way you should expect four automatic reboots (two for each upgrade step) but, as long as I read the Release Notes, nowhere is written that the upgrade path needs a specific interim release to pass through...so it looks like you can really go straight to RA.16.02.0014 and expect just a single automatic dual reboot (first BootROM is upgraded, then the Software Image).

---

[Phyrstorm]

---

@parnassus wrote:

---

Phyrstorm wrote: I know upgradeing to 16.02.0014 recommends at least a 15.17 version or higher but further back then that I can't find any information beyond that.

I don't believe (where you have found that bit of information?).

I think BootROM was initially named on RA.15.12.0016 Release Notes document (so RA.15.12.0016 used BootROM RA.15.10) - before there wasn't any reference about BootROM - so, eventually, I will use that software version as an interim update step before going to the latest RA.16.02.0014 (which uses BootROM RA.15.11)...doing things that way you should expect four automatic reboots (two for each upgrade step) but, as long as I read the Release Notes, nowhere is written that the upgrade path needs a specific interim release to pass through...so it looks like you can really go straight to RA.16.02.0014 and expect just a single automatic dual reboot (first BootROM is upgraded, then the Software Image).

---

---

I found that information when going to download the 16.02.0014 update file.

UPGRADE NOTE: HPE recommends that you update to this software from one of the three previous releases (RA.15.17.xxxx - RA.16.01.xxxx). If your switch is running an earlier version of software, incremental updates are recommended. Please follow "Best Practices for Software Upgrade" section of the HPE ArubaOS-Switch Basic Operations Guide Version 16.02 for guidelines about configuration compatibility during upgrade.

[parnassus]

Interestingly that Upgrade Note (which appears only when you select the Firmware download) is not contained into any RA.16.02 software branch related Release Notes document...but I now see that for RA.16.01.0004 (first of RA.16.01 software branch) the same has been written, clearly with different values:

New release RA.16.01.0004

NOTE: HPE recommends that you update to this software from one of the three previous releases (RA.15.16.xxxx - RA.15.18.xxxx). If your switch is running an earlier version of software, incremental updates are recommended. Please follow "Best Practices for Software Upgrade" section of the HPE ArubaOS-Switch Basic Operations Guide Version 16.01 for guidelines about configuration compatibility during upgrade.

So at this point consider also:

RA.15.16.0005

IMPORTANT: This software includes an update to BootROM RA.15.11. If your switch has an older version of BootROM, the BootROM will be updated with this software. Do not interrupt power to the switch during this important update!

+++++++++++++++++++++++++++++++++++++++++++++++++
Digital Signature Note: Beginning with RA.15.09, the switch software includes a digital signature. However, if this software is downloaded by an earlier software version that does not understand digital signatures, the earlier software will remove the digital signature before storing the new software in flash.

In order to have digitally-signed software in the switch, you must boot the switch into RA.15.09 or later software, and then re-download the RA.15.09 or later software into the same flash it is already in (primary or secondary). Because the switch is now using a software version that understands digital signatures, the signature is not stripped during the download.

Use the verify signature flash command to see if the software has a digital signature. After entering the command, if the software is digitally signed the switch does nothing for approximately 30 seconds, then responds. If the software is not digitally signed, the switch responds in approximately 10 seconds.
+++++++++++++++++++++++++++++++++++++++++++++++++

[Arimo]

Firstly let's correct a slight misunderstanding: we don't have a single "latest" SW version for any of our switches.

RA.16.02.0014 is "latest and greatest" only in RA.16.02 -branch. We have multiple currently active branches (RA.16.01, RA.15.18, RA.15.16m) and all of them have their individual latest version. Same applies to all our ProVision/ArubaOS -based products. Which to use depends entirely on your situation and needs - choose the branch accordingly. It's impossible for me to decide for you, but here's something to consider. 

You're currently running RA.15.05 in some switches. Let's assume you're upgrading because you want to introduce some new capabilities which are only available on RA.16. In that case - by all means go for .16.01 or .16.02. But running this old FW versions imply that you're more interested in stability, just want to get the devices on the same FW level for management reasons, and don't want to upgrade too frequently. If this is the case, the Maintenance branch RA.15.16m might be more appropriate solution.

The functionalities of a Maintenance branch are locked, we only fix issues. The next time we want to add new features to a Maintenance branch, we will designate a new one. For example we might in the future decide that we want to change RA.16.02 as a new Maintenance release. It will have all the features it currently has (and what are added until that point) but new ones will be added to other branches. This means that a Maintenance branch has a lot longer lifetime than a CPE release, and upgrades are published far less frequently, only when necessary.

Note that this is not a statement that 16.02 will be the next Maintenance branch. I just chose it as an example how this works.

What comes to upgrade paths; they are always listed in the Release Notes. Currently Release Notes are available from RA.15.06 upwards. So just check out the latest RN on these. If intermediate steps are required, they will be listed. If there's no list, there's no limitations either. Likewise the RN contains a full list of available enhancements.

Personally I would do a long jump such as from 15.05 to 16.xx with a couple of intermediate steps regardless of what the RN says; and always upgrade the devices always via the secondary flash. But that's me... I rather err on the side of caution.

[parnassus]

---

Arimo wrote: But running this old FW versions imply that you're more interested in stability, just want to get the devices on the same FW level for management reasons, and don't want to upgrade too frequently.

We shouldn't understimate the case, not covered among your above suggested reasons, that some IT Administrators, particularly when speaking about switch units that "are just simply running undisturbed" for years after their initial major configuration, simply forgot (consciously or unconsciously) to keep them updated using published Maintenance or CPE releases [*].

Clearly that's just the - sad - opinion I formed through years of personal (in)experience in the field.

[*] Especially when we consider all related security fixes and all related enhancements a new software update usually brings in.