Flexfabric 12900E upgrade question

[Mike Lavery_2]

Hi,

We have two FlexFabric 12900 Switch Series (Type-E modules) on software version 7.1.070 Release 2610H13.

We want to upgrade to R2713

Both switches are interconnected and HPE are stating that both switches will need to rebooted at the same time which will mean a disruption to service.

Is this correct and what work arounds are there?

thanks

[parnassus]

Hi!

HPE Support is correct.

The HPE FlexFabric 12900E Switch Series supports ISSU (In-Service Software Upgrade) only when the update is going to be performed starting from R2710 or R2712 software releases to latest R2713 software release, any other software release within the R27 software branch (as example R2708 or R2706P01) or within the R26 software branch (as example R2610, R2609 or R2606) is not supported by ISSU feature so an IRF will suffer from a disruptive upgrade process to R2713 if starting from one of those software releases. The same is true if you are planning an upgrade from any R26 software version to any other R27 software version (particularly interesting are the R2710 and R2712, that's because R2710 is the ISSU baseline for IRF enabled ISSU). So, apaprently, there isn't any workaround to avoid a disruptive update/upgrade to R2710, R2712 or R2713 from R26.

ISSU support matrix (within R27 and within R26):

• R2710 -> R2712 -> R2713
• R2710 -> R2713
• R2712 -> R2713
• R2609 -> R2610

References:

• R2713 Software version Release Notes
• R2712 Software version Release Notes
• R2710 Software version Release Notes
• R2610 Software version Release Notes

[Mike Lavery_2]

Hi,

thanks for the reply, appreciate it.

Based on this being a disruptive upgrade, how will this work? Do we upgrade one switch, traffic moves to the other then do the 2nd switch once the first comes back. Slave first, master 2nd....

HPE are stating that we may lose service for up to a minute. Is this correct?

What could we do here as this is a critical client environment so we cant have downtime.

thanks

[Brian_Dsouza]

@Mike Lavery_2  The disruptive upgrade recommended by HPE is a full reboot on both the IRF member switches which can be achieved simply by running the "reboot" command. This is going to reboot both the switches at the same time and thereby the time taken for the switches to come up post the reboot is the downtime you'd concede.

I would say a 1-minute downtime too less to anticipate(not being pessimistic). It actually depends on all the LPUs and their types. I would say we could give it a good 3 minutes at least.

I understand you are looking to minimize the downtime as much as possible to which the answer is what @parnassus precisely answered using ISSU which is for a compatible upgrade.

However, we have another approach for incompatible IRF upgrade viz, using MAD BFD. I'd encourage you to have a look at the below video explanation. I have tried this on a fixed port switch and has worked well in the past.

https://community.arubanetworks.com/t5/Video/Incompatible-upgrade-of-IRF-stack/ta-p/550292

Based on what I have observed I would strongly recommend a full-reboot explained in the first section unless you can test the second approach (using BFD MAD) before trying.

Hope this helps.

[parnassus · Accepted solution]

Yes @Brian_Dsouza, the Incompatible ISSU approach is exactly what we discussed via PM as an alternative approach...clearly it's viable with a BFD MAD mechanism correctly working (the video series you posted from Airheads is exactly what I was referring to even if I didn't push my discussion that far).

In all honesty, whatever the procedure @Mike Lavery_2 will decide to follow (and we all agree that an Incompatible ISSU is a rather brute force method), IMHO a complete pre-upgrade checklist related to his IRF deployment shall be required.

[Mike Lavery_2]

many thanks guys, really appreciate the detail here. Helps alot.

Best Regards, Mike

[parnassus]

Follow-Up: Few days ago a new 12900E software version was released, see R2714 Software version Release Notes.