Upgrading software on HPE 10508 from 7.1.0-R7180 to 7.1.0-R7536P05

[rodukov]

Good day to everyone!

We are going to upgrage software on our two 10508 boxes (IRF mode) from version 7.1.0-R7180 to 7.1.0-R7536P05. In Release Notes we found next statement and would like to know what does it mean?

Restriction 3
In an IRF fabric with plenty of configurations, the system might take more than half an hour to collect
the diagnosis information.

We cannot use ISSU (because software versions are incompatible), so our plan is pretty simple - copy BOOT and SYSTEM binary files to linecards #4 and #5 on both boxes, correct boot-loader, save and reboot.

Our IRF stack has plenty of configurations, so what will happen after reload? Will our switches become out-of-service just for the ~5 minutes, needed for reload, or for half an hour, as written above?

Also, please, provide us any caveats on this procedure.

Thanks a lot in advance! :)

[rodukov]

One more question:

Is there any possibility to upgrade software without service disruption in our case?

[VoIP-Buddy]

Rodukov,

I think that restriction is when you are doing a display diag.  There is no diagnosis information  collected on restart.  It is hard for me to say though as you only cut that note out but didn't say where it came from.

You don't copy this code to LPU's... only the 2 MPU's in each chassis and set it up as you said with the boot-loader command.  Use the .ipe file.

As for a minimal downtime reboot, you need to ensure that all of your directly attached devices are dual-homed to both members of the IRF stack.  If they are, and both chassis' have a way out to the Internet or other internal network that the client devices need then you can probably do it if you boot one chassis at a time.  You will need to shut off the IRF so that the other chassis doesn't wait for its peer to restart.

We have done a procedure for 5900's that accomplishes that but it is HIGHLY specific to each case.   The principal could be adapted to 10500's.

If you can stand the 5 or 10 minute reboot, that would be the best bet.

David

[parnassus · Accepted solution]

In this HPE Knowledge Article (mmr_sf-EN_US000005579) an (incompatible) ISSU procedure between two HPE 10508 in IRF is described step by step (the reference OS was Comware v5 instead of v7 so no ipe file was used in that example); note - as @VoIP-Buddy reported above, the requirement of having a MAD mechanism in place to manage the Split Brain scenario that will happen during the IRF upgrade procedure.

[rodukov]

Guys,

First of all, thanks a lot for your answers. I really appreciate your help!

Few more questions:

1. If we follow the procedure described in attachment above, will be there any service disruption (in case if we have 2 downlinks to our servers and 2 uplinks to the Internet)? If yes, how long does it take?

2. Enough this MAD configuration, or we need to configure MAD LACP, etc. (see below)?

MAD ARP disabled.
MAD ND disabled.
MAD LACP disabled.
MAD BFD enabled.

mad bfd enable
mad ip address 10.0.0.1 255.255.255.252 member 1
mad ip address 10.0.0.2 255.255.255.252 member 2

[rodukov]

Bump

[parnassus]

One thing at time, regarding (2) a BFD MAD-enabled IRF configuration for a two-chassis IRF fabric requires that:

1. the IRF link down report delay should be set to 0 (zero) seconds (do that in system-view mode with the irf link-delay 0 command).
2. a BFD dedicated VLAN should be defined and at least two physical interfaces (of both IRF Members) are set members of that BFD dedicated VLAN, those two physical interfaces will be used to set up the BFD physical link between two IRF Members.
3. a VLAN Interface is configured for the BFD dedicated VLAN already defined above (as per three commands you wrote above).
4. Spanning Tree feature should be disabled (with undo stp enable command) on each physical interface which is member of BFD dedicated VLAN definded above.

That's should be enough (check with display mad verbose command).

Steps reported above were taken from "HPE FlexNetwork 10500 Switch Series Virtual Technologies Configuration Guide" (Part Number: 5200-1915, Document Version: 6W100-20161230).

Incompatible ISSU will cause L2 and L3 services distruptions (since there will be a switchover), restore of L2 services by control plane should be handled in just few seconds...regarding L3 services, it depends on what is configured so answering is difficult.