HP 2920-24G PoE+ should I upgrade the firmware

[Digital-Man161]

I recently took over as IT for a company and they had a brand new 2920-24G sitting on the shelf.  I want to put it in production and noticed that it is running firmware from 2012.  Should I upgrade to the latest?  I noticed there have been a few releases just in the last 3 months.  Thanks.

[parnassus]

Why you shouldn't?

In your opinion...is leaving your HP 2920 sitting on a shelf unused (since you don't use it in production yet) and unmantained (for sure with an old Firmware) any better than trying to update it to the latest Firmware available (let's say WB.16.02.0008 or WB.15.18.0011, considering that WB.15 and WB.16 represent two distinct Major Releases branches [*] for the same WB Platform) and then putting it in production?

[*] from the Release Process for ProVision Software guide published on 2015 (I think that it could be considered generally valid also for ProVision now branded ArubaOS-Switch):

"For ProVision software, a new major software version containing enhancements and defect-fixes is released approximately every four to six months. When this new software is released, a Current Product Engineering (CPE) branch is created for that software. Starting with software version 15.16, this release milestone is called Software General Availability (SW GA). Each CPE branch normally live for approximately 12 to 18 months."

[Vince-Whirlwind]

When managing a fleet of Procurve switches, my approach to firmware upgrades is:

 - keep an eye on firmware upgrades so I know when a new one comes out
 - for each newly released firmware, read the release notes so I understand what bugs are fixed, what new features are added, and what features are lost
 - Assuming I'm happy with the above, and even if there's nothing in the firmware specific to any requirements I have, roll out the new firmware to all switches

This is completely different from my approach to Cisco, for example, where I don't bother with firmware upgrades except if I need a feature or a bug fixed.

[parnassus]

Yep, with the Why and the How it should be easy to decide which route to follow. Note that, signin into MyPortal for Networking, you can let HPE to send you alerts on each new software release for various Switch series.

@just a clarification, when you wrote:

---

@Vince-Whirlwind wrote:

This is completely different from my approach to Cisco, for example, where I don't bother with firmware upgrades except if I need a feature or a bug fixed.

---

With the statement above...do you mean that you trust so much CISCO that you don't need to examine each Release Notes before applying an upgrade or do you mean that you usually don't upgrade CISCO Switch's Firmware at all...and, if you do upgrade them [*], it's just because you have a specific bug to fix and/or a new feature to implement?

[*] = indipendently of the frequency with which CISCO (or HPE) releases Switch Software's upgrades.

[Vince-Whirlwind]

Yes, with Cisco, I don't pay attention to new firmware releases and don't apply them unless I'm actually changing something.

I remember having to do a network refresh on a multisite Cisco network - my first step was to access all the switches and get their config - I did a "show run" on each of them, and the entire network (of Cisco 3500s from memory) had uptimes of between 1800-2000 days.

So, just saying, my experience of a Cisco is that they are very stable, once in place there is no need to ever touch them until it comes time 5 years later to replace them with something new.

I do prefer working with Procurve though, I only get involved with Cisco stuff if I have a crazy customer that has more money than sense. In any case, in terms of functionality I stopped selling Cisco to customers about 1o years ago as they no longer had the features I was looking for to fulfill my requirements. And I think a lot of people got badly burnt 5 years ago when they got involved with some pretty bad Cisco data centre switches. I've pretty much only put H3C in Data Centres since then, 5800s and now 5900s are absolutely perfect, with 12500 cores.

[parnassus]

Thanks! good to know.

[Digital-Man161]

I'm not quite sure you gave me an answer.  I didn't leave it on the shelf, the previous IT staff did.  It was brand new in the box.  I guess my question is, am I better off upgrading it to the latest, leaving as is, or (by the sounds of it) you're suggesting not even using it?

I think I was just trying to see if there are any issues with the latest because of the frequent updates and maybe if I am only using basic feature leaving as is might be a better option.  I did update to WB_15_15_0014 however over the weekend.

[parnassus · Accepted solution]

I Never wrote *you* left it unused on the shelf...and, trust me, I don't care who did before you nor what is going to be its fate.

Absolutely I never wrote nor suggested to not use it: IMHO you're very lucky to have that piece of Hardware with you (the updated WB.16.02.xxxx Aruba 2920 is very good and has good features: Backplane Stacking, ZTP Activate, AirWave, ArubaCentral, Private VLAN, Captive Portal for ClearPass, Expansion Module slots on back and so on...)...but all depends on your requirements.

My question (a bit challenging, I must admit) was written to encourage you to update your Switch, in fact the expected answer to such provocative question would have been:

Rather than leaving it sitting on the shelf (as actually it is, as *you* wrote) without any update, it's better to update it at the latest Firmware version actually available [*] so it will be ready for any future usage.

Another version could be:

Rather than leaving it sitting on the shelf (as actually it is, as *you* wrote) without any update, updating it is not actually worse than leaving it with an old Firmware, so it will be ready for any future usage.

It's really up to you.

[*] In the moment I'm writing this post - and depending on the Major Release branch WB.15/WB.16 you want to stay - Firmwares are WB.16.02.0008 or WB.15.18.0011, both at least two years ahead of the actual Firmware that Switch is running on.

Doing so your Switch, no matter what you will do with it, will be "ready for production" considering that - generally speaking - Firmware updates incorporates more frequently important bug/security fixes and new interesting features other than "regressions" (with "regressions" I mean the possible re-introduction of old fixed issues or the introduction of new nasty ones) <-- as reference read the various Release Notes published up to now.

[GrahamElder]

Hello,

I have a pair of 2920-24G switches on firmware WB.15.16.0009 and ROM WB.15.05.

I'm looking at the list of available updates and can see either WB.15.18.0012  or  WB.16.02.0012 as the latest versions. What is the difference between the two major firmware branches and do I need to stick to the branch I'm currently on? I cannot find documentation explaining how branches should be followed.

Thanks,

Graham

[parnassus]

I understand what you're looking for...AFAIK I never see a detailed presentation or just a technical paper that shows what was included into the new ArubaOS-Switch (formerly ProVision) 16.0x branch for K/KA/KB/RA/WB/WC/YA-YB [*] Switches series with respect to their latest 15.xx branches BUT there various Aruba presentations out there - Google and AirHeads Community could be your friend - showing that ArubaOS-Switch 16.0x branch introduced various new features since its first introduction (an example over all: VSF Virtual Switching Framework for Aruba 5400R zl2 with v3 zl Modules).

An interesting way to look for differences is to read the latest available ArubaOS-Switch Software Feature Support Matrix (actually you can find it here) and search for Features that require WB.16.0x as minimum software version (same search can be done considering WB.15.18 as the minimum software version).

What you will find is that there are - actually - 36 unique features that require WB.16.0x (basically since WB.16.01, some features were introduced specifically since WB.16.02) related to Aruba 2920 Switch Series, here is the list I redacted:

• LLDP over OOBM
• MAX VLANs: 1k
• MVRP: Multiple VLAN Registration Protocol
• Captive Portal for ClearPass
• Device profile: Auto configuration with Aruba AP detection
• Device profile: LLDP Authentication Bypass with AP (since WB.16.02)
• IP Service Level Agreement (SLA) (since WB.16.02)
• NTP: Network Time Protocol
• REST
• ZTP for Activate (since WB.16.02)
• QOS: Per Port Trus (since WB.16.02)
• mDNS (Bonjour and Chromecast) Gateway
• Job Scheduler
• Multicast: IGMP v3
• OSPF (since WB.16.02)
• OSPF ECMP (since WB.16.02)
• OSPF Neighbour Shutdown Notification (since WB.16.02)
• OSPF Neighbour Timer Information Display (since WB.16.02)
• OSPFv3 (since WB.16.02)
• OSPFv3 over 6in4 Tunnels (since WB.16.02)
• OSPFv3 Trap Global Enable/Disable (since WB.16.02)
• RIPng
• Tunneled node (per Port) (since WB.16.02)
• Tunneled Node enhancement: fallback to switching (since WB.16.02.0011)
• ACL Grouping
• ARP Attack Detection
• Local User Roles
• MAC Authentication: Port-based (since WB.16.02)
• MAC Authentication Toggle (since WB.16.02)
• ND Snooping
• Password Complexity
• PVLAN
• RBAC Role Based Access Control
• RADIUS Service Tracking
• Supportability Infrastructure: User Initiated Diagnostic Reset via Clear button
• Supportability Infrastructure: User Initiated Diagnostic Reset via Serial Console

Where "since 16.02 means "since 16.02.0008, at least".

This doesn't represent a complete answer...there are - as you know yet - other interesting genearl questions (partially answered on relevant 15.18/16.0x Release Notes) too...like:

• How/if features are inherited by Branch (n+1) from Branch (n)?
• How/if bugfixes are inherited by Branch (n+1) from Branch (n)?
• Branch (n+1) and Branch (n) are developed separately?

and so on...

For what is worth here a screenshot taken from a 2015 document called "Release Process for ProVision Software", it is partially outdated but still interesting:

 [*] Switch series based on ArubaOS-Switch:

• 2530 (YA/YB)
• 2620 (RA)
• 2920 (WB)
• 2930F (WC)
• 3500/5400 (K)
• 3800 (KA)
• 3810/5400R (KB)