IRF upgrades for HPE 5930 switches performed using the In-Service Software Upgrade (ISSU)

[spgsitsupport]

I physically can not have each server connected to each switch as theey are different kinds:

2x JG336A
2 xJC772A

Fibre & copper, 2 of each.

ISSU upgrade still should NOT destroy the IRF during upgrade & spit it!

[spgsitsupport]

@GerryOBrien

Did you do the ISSU on 4 member stack as per:

https://community.arubanetworks.com/aruba/attachments/aruba/NorwegianForum/16/1/ISSU%20Docs.pdf

or

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=mmr_sf-EN_US000005131

Seb

[parnassus]

Starting on sheet 22 (of 68) there are three "Examples of using issu commands for ISSU on a four-member IRF fabric", respectively:

• Feature upgrade to a compatible version,
• Feature upgrade to an incompatible version (upgrading one subordinate member first),
• Feature upgrade to an incompatible version (upgrading multiple subordinate members first).

[GerryOBrien]

Hi Parnassus,

  Thanks you for the links. These are the most up-to-date doumentation we have seen for ISSU upgrades. We are now quite comfortable peforming a compatible upgrade on a four member IRF stack. Our problem is that we believe we will get a split-brain at some point in perforing an incompatible upgrade. Our proposed solution is below.

  Regards,
      Gerry



Our network is a 4 switch IRF stack connected in a ring and also with fully connected BFD MAD. Switches 1 & 2 are in one building and 2 & 4 in another. All servers and storage are dually connected to either switches 1 & 2 or else 3 & 4.Basically, our procedure is to upgrade all switches and reboot switches 3 & 4 first, splitting the IRF in two. After switches 3 & 4 have restarted they are running the upgraded software but all their non-MAD ports are disabled but we have  connectivity through switches 1 & 2. We then temporarily disable the MAD on switches 1 & 2 by shutting down the MAD Vlan. We then restore the MAD on switches 3 & 4 and, after a brief delay, reboot switches 1 & 2. When switches 1 & 2 have restarted all four switches are running the upgraded software so switches 1 & 2 join the IRF of switches 3 & 4. 

[spgsitsupport]

This manual  was written by somebody does know very littl;e or way too much.

It is completly inaccurate.

To start it references .bin file where the system upgrade comes ar .ipe

It does not assume how the connection to the stack is happening (IP or serial console)

It is is by IP?, in which case I will most likely loose connection during:

# Perform a main/backup feature process switchover.
<Sysname> issu run switchover

Or am I connect by serial, and if then to WHICH member in the stack?

Also:

# Upgrade the feature on subordinate member 2. After the upgrade, the subordinate member will leave
the original IRF fabric and form a new IRF fabric by itself.

If I remember that is exactly what happened last time, new IRF fabric with 1 member got created, but (as expected logically) with IP of the original IRF stack (could not be otherwise!)

So I had two identical IPs on the network, rather unworkable!

So the instructions are FAR from clear how to doi it properly with 4 members & an incompatible version (which I assume what I am facing)

[VoIP-Buddy]

Hi Spgsitsupport!

So you have to be careful here... Comware is Comware until it is not... 

The first document is taken out of context.  That is a document for ISSU for a multi-slot switch like a 12500, 12900, 11900, etc.  The ISSU procedure for that class of switch is different to some extent than the ISSU process for a TOR switch like the 5930.  The second document is closer to the reality of this situation.

They both look like official HPN documentation but not specifically for the 5930.

Regards,

David

[parnassus]

...and, worth to mention, the latest available HPE FlexFabric 5930 Switch Series IRF Configuration Guide (Part Number 5998-7767R valid for R242x, document version 6W100-20151220) doesn't contain a single reference to "ISSU"...neither the related IRF Command Reference reports any reference to "ISSU"...so will interesting to drill down a little bit why it is so for the 5930.

[spgsitsupport]

All I want to know how to upgrade 4 switch IRF stack, surely that is not too much to ask from company that charges big bucs for the units?

[spgsitsupport]

The only way I managed to upgrade it, was to do FULL reboot.

Which I find unacceptable (on this occassion I had full shutdown planned anyway, so was not a problem, but in a future it will certainly be a big problem)

Also at which point replication of updated system .bin file is supposed to happen from master to other members?

It did NOT happen before system reboot (so I did the extraction on each member by hand, in case it all went pear shape)

Seb