I'm evaluating the purchase of two HPE FlexNetwork Switches 51x0 HI switch series with the essential pre-requisite of supporting IRF+ISSU technologies (I'm also comparing these switches to, say, Aruba 6300M providing VSF+ESU technologies). The EI doesn't provide ISSU.
I noticed that currently, on ASP, for HPE FlexNetwork 5130 HI switch series, which reached EoS on June 30th 2022 (EoS here), more recent software versions released could be found compared to the ones published for HPE FlexNetwork 5140 HI switch series, switch family which replaced the 5130 HI since mid 2022 (not US software versions):
Is this really the "software release" situation or am I missing something? I looks like the 5140 Hi is EoS instead of 5130 HI and not the contrary, at least comparing the software release pace.
The same could be say - similarly - comparing the HPE FlexNetwork 5510 HI with the HPE FlexNetwork 5520 HI (which replaced the former, declared EoS).
Hi, I run many hundreds of 5130 and my observations are:
1) While you may have seen a recent version of code for the 5130 they do not come out very often. Likely when a serious security bug needs patching (and doesn't always make it into the release notes). You'll see from the release notes of the two you linked that the 5140 hardware is very different so a serious bug in 5130 would not create the need for a 5140 release. For the 5900 which we have a lot of in the DCs the last release was in 2018 even though EoS was December 2021. Recently a version was released but only because of a high CVE scoring security vulnerability.
In short, I would be cautious about relying in comware software releases and purchas only if you are very happy with the current one.
2) TAC support for comware has been poor for years. Not because of individuals but because Aruba do not create the code and the relationship between the two companies clearly is reduced after Aruba pushed their own OS. I found when raising a Comware bug the delays were much larger than I would expect.
3) Having worked for a (different) vendor for over a decade, and having worked with network gear for 25+ years, ISSU has never worked to the point where I would be confident in putting it into a design. I would be more confident with the 'hot patch' concept in CX because this is more like patching one of the underlying unix daemons alone and therefore should only affect that aspect. My experience with comware switches, both the small 5130 and upto the 59xx is that they require a reboot once a year to protect against various bugs/issues that take a long time to manifest. We have experienced enough that it is our policy to reboot in a controlled window even with an upgrade once a year.
4) Automation- no libraries or support for comware. Some limited support for CX. If that will be important for you in the future go with CX.
So even though we have a lot of skills/knowledge in Comware we are purchasing CX from this point on in order to future proof the organisation.
Hi Ian, thanks for answering me and pointing out about those interesting facts.
(1) I agree 100% with you, different Switch series (even if they belong to the same broad HPE FlexNetwork family) can't be compared apples-for-apples. Mine was just a way to say how strange is to not seeing updates in a about a whole year on HPE FlexNetwork 5140 HI.
(2) Taken (what's a pity).
(3) OK, you're not (and it looks like you weren't too) confident about the ISSU mechanism (hoping you are confident on IRF at least); is that lack of confidence tied to the fact that ISSU never worked the way it is explained (or it didn't work the way you wanted in your scenarios) or what exactly? could you explain it to me? on the other side, on regularly rebooting a switch (at least once per year), I don't see how that could be an issue giving that we usually update them regularly (at worst once per year) as a part of a planned maintenance schedule.
(4) We will survive but we see that - speaking about Ansible modules - exactly as there are modules for ArubaOS-Switch and ArubaOS-CX there is ansible-hpe-cw7 very well documented and that's enugh for our automation requirements (at least at that point of our story).
and finally about your last sentence "So even though we have a lot of skills/knowledge in Comware we are purchasing CX from this point on in order to future proof the organisation." we too are evaluating an Aruba CX solution versus one with HPE FlexNetwork switches (we have some VSX so there are some skill in-house yet), specifically Aruba 6300 with its VSF+ESU (running at least ArubaOS-CX 10.11 or 10.12)...and, to be honest, we have more skills with the latter (Aruba CX) than the former (HPE FlexNetwork)...we are just exploring possible solutions to a scenario we are going to deploy soon (a simple 2 members Stack with Hitless Management features).
Hi Ian, I really appreciate your insights! really!
"Regarding ISSU, I believe the issue this has caused customers pain over the years since the idea was first created is that the ISSU element itself requires coding"
OK, I agree with you but, we should admit that, the above is a very generic consideration applicable to a lot of systems.
Isn't valid for ESU on ArubaOS-CX too?
Given that Aruba ESU requires coding to implement new features, are you implictly saying that coding for Comware ISSU is worst than coding for ArubaOS-CX ESU (and so, consequently, the ArubaOS-CX ESU feature behaves better in the field than the Comware ISSU feature)?
"Code creates bugs."
Absolutely. More lines of code, potentially more bugs.
"Compared to the idea of loading a complete software onto a switch and rebooting into it."
OK, both Comware ISSU and ArubaOS-CX ESU rely on OS patching AFAIK, isn't a risky approach for both implementations?
"Moreover, each version seems to require a new ISSU code as bugs in just the ISSU part creep in past the first release (it isn't possible to get this right once and everyone is happy)"
Now I believe I understand that Comware lacks of some love although it deserves it.
"Also, there are caveats documented with ISSU for some products. Firstly, only minor releases tend to be ok. Secondly, some features are not compatible."
The same applies to ArubaOS-CX ESU (it works only within the same Major Release, it's not supported omogeneously on all models, no downgrade, strict pre-requisites and so on...)
"So in general, I create a design that permits upgrades without ISSU. For example in the DC with Comware 5900 in IRF pairs I can upgrade the pair with only 1s of LACP packet loss (i.e. one lost ping). This allows a complete reboot of each IRF member for upgrade or any other reason."
That's the way thing should be done! my requirements for a tiny procject (evaluating the best approach and the best hardware/software architecture among other things) are very simple: an island for a new DMZ which should be highly available, no Layer 3 on the Stack, no other fancy features Switch side, upstream and downstream peers dual homed (well, the Firewalls Cluster part is going to give me some headaches despite the simplicity of the redundant interconnections between the Stack and the Firewalls), Layer 3 on the Firewalls Cluster...to say I'm not too worried about the Server peer side, I'm much more worried about the Firewalls Cluster peer side.
"I fully appreciate that your network is very different."
On the contrary, hope it's not a joke? ;-)
In the end, we are going to evaluate a pair of HPE FlexNetwork 5140 HI (IRF+ISSU) versus a pair of Aruba CX 6300M (VSF+ESU) and also (a little bit over budget and mostly underutilized for the performances/features it provides) a pair of Aruba CX 8100 (VSX).
Original Message:Sent: 9/27/2023 9:35:00 AMFrom: parnassusSubject: RE: HPE FlexNetwork 5130 HI and 5140 HI switch series (IRF+ISSU features) software releases pace
Original Message:Sent: Sep 26, 2023 01:54 AMFrom: IanNightingaleSubject: HPE FlexNetwork 5130 HI and 5140 HI switch series (IRF+ISSU features) software releases pace
Original Message:Sent: Sep 25, 2023 11:09 AMFrom: Davide PolettoSubject: HPE FlexNetwork 5130 HI and 5140 HI switch series (IRF+ISSU features) software releases pace
Hi, I think I should clarify that I have a lot of experience with ISSU from other vendors, lots of experience dealing with Comware upgrades, but no experience with CX ESU. I'm not comparing the two types of ISSU. My comments are on the concept of ISSU versus reboot-upgrades. For those with little experience it would seem a good idea to use ISSU even when other options are available. I'd like everyone to understand that reboot-upgrades are a lower risk way forward when all options are available to the designer. In my opinion that ISSU should only be used for specific use cases where other upgrade options would not work. The risks are matched by my Aruba Systems Engineer I've asked.
If high availability of a service attached to a IRF pair of comware was required, I would be happy using LACP if available from the servers. That works really well for hitless upgrades. That would provide 100% uptime to the service and allow reboots for reasons other than upgrades. If the connecting devices cannot use LACP and the service must be up all the time, I would consider ISSU. Though I would worry about not being able to reboot ever.
I'm not sure what circumstances I would use CX-ESU. Given the conductor must reboot during the upgrade, If I needed just a two member stack I am no better off than a traditional upgrade method. I guess if I had 8 members I could attach single wire devices only to the non-conductors. But that might be expensive.
I would be interested in your experience of CX-ESU as I'm about to upgrade our DC infrastructure (Comware 5900) and will likely have CX. I have really good experience of VSX-upgrade for the larger boxes (hitless and really easy to do compared to comware) but no experience of VSF only boxes which we will also require for copper port connectivity. If ESU was rock solid I would consider for the minor upgrades etc, and schedule downtime for the major upgrades etc.
Original Message:Sent: Sep 27, 2023 09:50 AMFrom: IanNightingaleSubject: HPE FlexNetwork 5130 HI and 5140 HI switch series (IRF+ISSU features) software releases pace
Simplifying, to me a deployed two members VSF made of ArubaOS-CX based Switches supporting ESU to manage hitless updates is quite similar to a deployed two members IRF made of Comware 7 based Switches supporting ISSU to manage hitless updates; this - at least - considering the potential impact of a stack update operation on any "dual homed" peer connected...so from a peer standpoint.
To come back to the thread's original subject, I noticed that - finally - on ASP was recently published an updated software version for the HPE FlexNetwork 5140 HI switch series "rebalancing" the initial situation:
so part of my initial doubts are basically gone.
To be correct I should highlight that (a) the very latest HPE FlexNetwork 5130 HI software release is really the Comware 7.10 R3507P10 US (released in May 2023) but that's the "US software" (not for RoW) so, for a like-for-like comparison with the HPE FlexNetwork 5140 HI, it was omitted and that (b) the software of HPE FlexNetwork 5140 HI moved from Comware 7.10 R6615P07 (June 2022) to Comware 7.10 R6628P35 (September 2023) and this "jump" is not ISSU compatible (just to say...).
just wanted to add that I recently discovered that our 5130 HI do not support TLS1.2. They only offer SSLv3,TLS1.0 and TLS1.1.
To add to the discussion: I only upgraded the 5130 via reboot.
Might be another reason to switch to CX.
Hi! thank you for sharing.
Side Off-Topic note (not tied to supported features comparison but about purchase costs comparison): we discovered that, in a like-for-like comparison between a pair of 2 copper ports non-PoE HPE FlexNetwork 5140 HI equipped with dual PSUs and a a pair of 24 copper ports non-PoE Aruba 6300M equipped with dual PSUs, the offered price for an HPE FlexNetwork 5140 HI pair is sensibly cheaper [*] than the equivalent Aruba 6300M pair (including - on both the offerings - the 5Y NBD HPE Aruba Networking Support). This made me think a lot (I'm not particularly worried about OS differences or about IRF+ISSU versus VSF+ESU differences) because I thought a "push" to sell Aruba CX assets would reasonably translate in a more affordable purchase price in order to discourage the usage of HPE FlexNetwork but it looks like the contrary (are they pushing the cheaper HPE FlexNetwork to empty the warehouse? I don't believe so...).
[*] The delta represents about the 30% of the entire cost of the HPE FlexNetwork solution or about the 25% of the entire cost of the Aruba CX one.
© Copyright 2024 Hewlett Packard Enterprise Development LPAll Rights Reserved.