5130 firmware versions

[racermonoid]

Trying to fix a three member 5130 irf intermittent problem, support told us to upgrade the firmware on all three members (currently on R3115P07) to the lastest version.

They proposed R3116P05 or R3208.

R3116P05 looked like the safest bet, had the most irf fixes in the release notes so tried that. All hell broke loose, the two nonmaster members stopped working, in the sense that client connected devices could not communicate, random behaviour on all three members, after much troubleshooting gave up and tried R3208.

R3208 currently working and monitoring to see if it will fix the original intermittent problem.

My questing is, what's the deal with these two firmware releases?

R3116P05 has the lastest build date, latter than R3208 (by a few days), but R3208 going be number count should be newer.

Are they two different tracks? Why won't support commit to one of the two (I asked and they didn't answer)?

Thanks,

[parnassus]

---

@racermonoid wrote:

Trying to fix a three member 5130 irf intermittent problem, support told us to upgrade the firmware on all three members (currently on R3115P07) to the lastest version.

They proposed R3116P05 or R3208.

R3116P05 looked like the safest bet, had the most irf fixes in the release notes so tried that. All hell broke loose, the two nonmaster members stopped working, in the sense that client connected devices could not communicate, random behaviour on all three members, after much troubleshooting gave up and tried R3208.

R3208 currently working and monitoring to see if it will fix the original intermittent problem.

Would be interesting to have a status's snapshot of your entire IRF Fabric taken before your update attempts and, also, would be interesting to read about the procedure(s) you followed - in both cases - to update the IRF Fabric (1st attempt, ended with a total failure) from R3115P07 to R3116P05 and (2nd attempt, ended with a total success) from R3115P07 to R3208.

My questing is, what's the deal with these two firmware releases?

R3116P05 has the lastest build date, latter than R3208 (by a few days), but R3208 going be number count should be newer.

Are they two different tracks? Why won't support commit to one of the two (I asked and they didn't answer)?

Thanks,

---

WRT Software Versions you tried, R31xx and R32xx are two different branches...so they, AFAIK, can follow two different release timelines...even if the product line they apply is exactly the same.

[racermonoid]

Thanks for the reply parnassus,

Update procedure was identical in both attempts, as outlined in the release notes.

Tftped the image to the master flash then boot loader file on all three members.
They all came up normally in both attempts.
Irf status was normal after both attempts, except nothing was working with the 3116 firmware.

Could probably get the irf status before the updates from the customer since he sent a bunch of stuff to support.

My confusion lies with the firmware releases, are there two tracks, what’s the difference, why are two different versions released so close to each other with different numbers, which one is the “right” one?

[racermonoid]

Didn’t see the second part of your reply.

That’s what I suspect about the different versions, it’s just confusing when trying to find a fix for a problem.

[parnassus]

Interesting...

WRT R31xx vs R32xx: from R3208's Release Notes we are able to discover that R32 software track started with R3207 and R3207, from what I understand, was developed from R3115P08, so R3207 used the R3115P08 as its starting base and then developed into R3208...so R31 seems on the bug fixes (and security fixes) path only - no new features as I understand - while R32 seems the current development path including bug fixes, security fixes and new (and/or modified existing) features.

New features and fixed bugs are reported on the "Remarks" column on each RN document.

Directly from R32xx RN documents:

HPE Comware Software Version 7.1.070 R3207 (1st R32 for HPE 5130) introduced:

• new fundamental features
• new IRF related features
• new Layer 2 LAN Switching features
• changes in existing features (so in features already available on the previous version, the R3115P08)
• bugs fixes

HPE Comware Software Version 7.1.070 R3208 (2nd R32 for HPE 5130 based on 1st R32 above) introduced:

• new MAC Address information displaly for IEEE 802.1X users in 802.1X VLANs of a specific type
• new Authorization CAR action in an ISP Domain
• new IEEE 802.1X Client
• changes in existing features (so in features already available on the previous version, the R3207)
• bugs fixes

Details should be found on the relevant RN's "Software Feature Changes" section.

WRT to R31 software track...related RN reports basically only bug fixes since R3115P08 release.

[racermonoid]

That's what has us confused,

going from R3115P07 to R3116P05 should have been less "desruptive" since R3116P05 was just bug and security fixes.

R3208, with it's new features, seamed a more risky option.

Of course troubleshooting in a production environment is never easy. 

[parnassus]

Yes, I know what you mean...performing updates within the R31 software track by updating a R3115P07 to R3116P05 (just 4 Patches ahead) should have been absolutely less risky and essentially a non disruptive operation than moving out from R31 to step into new R32 software track (which is a "bigger" step in comparison, at least in terms of software update since the update to R32 includes more modifications).

As a way of sharing experiences with other HPE Community members, as said, it would be great if you can share a (sanitized) configuration and status of your IRF Fabric before (sort of "Preparing for the upgrade" checklist) and after each update attempt (clearly if every steps was documented in a chronological way during the process)...considering that, from what you wrote above, only the R3116P05 attempt caused the IRF Fabric to split (?) with subordinate (standby) members not able to re-join (merge into) it properly again.

Note: as example, was the irf auto-update setting enabled before starting? it should have been enabled by default...and/or...were IRF members' priority properly set on the IRF Fabric (read: IRF Master member should have the highest priority, IRF Standby members should have lower priorities set into a descending logical order, this as a best practice)?

[VoIP-Buddy]

We have been recommending R3208 for a while now.  The older 31xx code stream is very old and that migrated as the base for the R32xx code stream.  Patches upon patches can be more risky than starting a build cleaner.

FYI... if you are running the 5130 EI's with the 10gb Copper Ports, please be aware that there is a software issue in R3113P05 and R3207 that prevented them from working reliably.  R3208 fixed the problem.

Regards,

David

[parnassus]

---

@VoIP-Buddy wrote:

We have been recommending R3208 for a while now.

Hi David, that's interesting...for a while now...written that way it seems that R32 has been around that long but, really, R32 on 5130 was published only in June 2017 (isn't it?) and so it is available since that month...so it's not that old (it's just 4 months old!).

The older 31xx code stream is very old and that migrated as the base for the R32xx code stream.  Patches upon patches can be more risky than starting a build cleaner.

What do you mean with starting a build cleaner? I'm curious: if R32 was born from a previous specific R31 release (exactly the R3115P08 May 2017) it was probably not that clean...I mean...that R32 has a "code heritage" that necessarily goes back to R31 (so it's not totally new code, isn't it?)...or are you just trying to say that 5130 users should forget about updating within theirs R31xx and they should instead jump into latest released R32 software version no matter why?

FYI... if you are running the 5130 EI's with the 10gb Copper Ports, please be aware that there is a software issue in R3113P05 and R3207 that prevented them from working reliably.  R3208 fixed the problem.

Regards,

David

---

OP wrote its IRF Fabric initially ran R3115P07 version so the 10G copper port issue looks not directly applicable to his case.

[racermonoid]

Hi David, thanks for your input.

> FYI... if you are running the 5130 EI's with the 10gb Copper Ports, please be aware that there is a software issue in R3113P05 > > > and R3207 that prevented them from working reliably.  R3208 fixed the problem.

Does this apply to the 10Gb DAC cables as well?

[parnassus]

Strictly speaking DAC Cables go to SFP+ ports, not Copper ports...but, maybe, David can add more details with regard to his note above.

[VoIP-Buddy]

Morning!

The SFP+ ports are fine.  You can use DAC cables or 10gb fiber transceivers.  The issue is only with the built-in copper 10gb ports.

Glad to help! 

Regards,

David

[marcelkoedijk]

Iam running in problems with de 10GB-BaseT ports dont come online.

My Switch Model is JG941A 5130-EI

HPE Comware Software, Version 7.1.070, Release 3208

The problem seems dont fixed correct in 3208.

[parnassus]

To say the truth (with respect to what @VoIP-Buddy reported few posts above), reading the latest R3208 Release Note, no recent 10GBase-T ports related problem can be found (if it isn't reported it wasn't fixed nor exists a workaroud, if any) apart from one that was fixed with the old R3113P03 (201604091715) "Symptom: When a 10G Base-T port is connected to a specific device model, speed autonegotiation takes 20 to 30 seconds and the negotiation result can only be 1 Gbps."...that's to say that if an issue with 10G Base-T ports really exists actually on 5130 EI it should have been clearly reported (if fixed) on latest Release Notes (considering that each Release Notes document is made to report basically all the knowledge about a software release for the involved product)...or the information related to 10G Base-T ports issue comes from internal support and it's (still) not publicly available so it's not reported on any release notes.

[VoIP-Buddy]

Hi Parnassus!

Your comment about release notes is a black and white comment.  In this particular case, the Comware release notes are gray.  Not every issue is documented in the release notes.  For example, issues that are found in the normal QA process are not usually reported because they are caught earlier in the development cycle.

When we recommend to upgrade it is usually because the code that is running is so old that Engineering will not fix the code because it could have been corrected in a following newer release.

The other reason why we recommend upgrades is that if we read in the release notes that a particular feature has seen a number of fixes done to it, there is a chance that another issue in the related area could have also been fixed because all of the code had been touched to deal with the documented issues.  Sometimes that approach is successful and other times not.

In regards to why R32xx is better than the R31xx code is partly because of the guidance we get from Engineering.  Merges take place from the older code to a new code stream that most likely has other improvements and new features merged in as well.  It is a better starting point because that code would go through a rigorous QA cycle to verify the fuctionality.  Patch releases are a little easier while still rigorous, the scope and breadth of what needs to be verified is a bit less.

As for R3208 with the XGT ports.  I actually tested that in the lab and I know that to be a working build of the code.  If there are issues, then we would need to have a case to be able to try to reproduce that in the lab and then discuss with Engineering.  At this point, I'm not hearing about any issues with the 10g copper ports.

Regards,

David