Upgrades
Procedure
All production upgrades MUST be documented in the Engineering Change Order (ECO) app (or its replacement), and follow the normal ECO procedure.
All upgrades should be tested in the dev environment before pushing to production.
When to upgrade
ArubaOS upgrades do not occur on a regular schedule. Rather, they are as an as needed or as available basis. Several things can motivate an upgrade. Roughly in order of priority:
- Security fixes
- Stability fixes
- New features
- Incremental update available
The rational for security and stability are obviously the top priority when providing a network service. Similarly, new features allow us to provide a better or new services.
When there is a security upgrade, the system should be upgraded ASAP; target within the week. Of course, this depends on the severity of the vulnerability. For example, a CVE score of 9+ may motivate an upgrade outside the normal change window to expedite the fix. A CVE score of 3 may wait until after a maintenance restriction window (such as due to semester startup or finals).
Stability fixes should be implemented in the next change window or two, pending testing of the code.
New features can wait the longest before role out. It is more important that the system be stable and predictable than have the shiniest new feature.
Incremental updates should be implemented in 10 days of release, but not during a maintenance restriction.
What to upgrade to
Staying on the latest release within a code train has allowed us to be patched against security vulnerabilities before they are announced. When we lag behind, we have hit stability bugs that are already fixed in newer releases.
Aruba has two public release types: "Standard" and "Conservative". The conservative release is the more stable of the two.
At the time of this writing, we are on the 8.7 train, which is a standard release. It has a few key features:
- AP support
- RAP 500 series
- AP 560 series
- IPv6
- MM/MD connection
- clustering
- AirWave
Conservative release
This is the generally preferred release. Unless there there are known issues with the newer version, always go to the latest version.
Standard release
If we are already on a standard release (such as the time of this writing), stay within the same major/minor version (e.g., 8.7.0.1 to 8.7.1.2 is good).