Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
j_silva
Contributor

Questions about CPUSE on Maestro VSX

Hi guys,

My client has an environment with a VSX cluster with Maestro Gateways (2 members) in version R81.10. We are doing some checks and are planning to upgrade the gaia version to R81.20. Yesterday I imported the installation package for the new version R81.20 and carried out the checks as follows:

Step 1 = I sent the package to the /var/log/ directory of the Security Group.
The uploaded file was -> Check_Point_R81.20_T634_ScalablePlatform_Upgrade.tar

Step 2 = gclish

Step 3 = Package imported:
installer import local /var/log/Check_Point_R81.20_T634_ScalablePlatform_Upgrade.tar [The package was successfully imported]

Step 4 - Package verification done:
installer verify <id> [Upgrade is allowed]

Until step 3 I didn't have any doubts about the process, however, after updating the cpuse from build 2 to build 68 the verification process was no longer completed. The verification status stops at 90% and does not complete. The symptom is similar to that reported in this sk -> https://support.checkpoint.com/results/sk/sk181674

However, if I do the individual check through each member's clish, I can do the check and have the result that it is possible to upgrade.

My question is whether the Security Group is really available for the upgrade or whether this behavior would be a problem that could impact the upgrade. The maintenance window is scheduled for 6/29 at 12am (midnight) GMT-3. If necessary we can schedule a remote session to verify everything.

0 Kudos
6 Replies
Lesley
Advisor

Looks like you verify the update on the MHO(orchestrator) and that fails. If you do it on a firewall itself it goes well.

Is this correct?

If this is the case you need to check why it fails on the MHO. In normal upgrade process you FIRST update MHO's if that goes well you proceed with the connected fw's

-------
If you like this post please give a thumbs up(kudo)! 🙂
0 Kudos
j_silva
Contributor

The MHOs are already up to date, this issue is happening with the Security Group members.

0 Kudos
emmap
Employee
Employee

It looks like you are experiencing that timeout issue, what JHF is installed on the SGMs?

0 Kudos
j_silva
Contributor

Hi,

The SGMs is running on version R81.10 JHF 81. 

Last week I did the same procedure mentioned here. The scenario was similar to this, I had a Maestro cluster (without VSX) in version R81.10 JHF 81 with two members who had the cpuse in build 2. With this build I was able to do all the validations, but when I started the upgrade, I received a message on the screen that stated that the cpuse was out of date. Therefore, I downloaded the updated cpuse (build 68, the same one used today to validate the upgrade) and managed to continue with the upgrade, however, I did not perform any verification when I was doing the upgrade, so I do not know if this behavior is expected due to the current version of gaia or take.

0 Kudos
emmap
Employee
Employee

The recommended and documented procedure is to update to the latest recommended JHF take on your source version before installing the new DA and proceeding with the upgrade. The recommended take for R81.10 also contains the fix for that verifier timeout. 

0 Kudos
j_silva
Contributor

Hi @emmap 

I agree that i need to keep the JHF up to date but recently i have been done the same procedure in another cluster with the same Gaia version and JHF and because this i´m concerning about this new one upgrade.

I believe that the i won´t have issue about the upgrade procedure but i´m sharing this experience with you just to know if someone already faced it and how was solved.

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events