- CheckMates
- :
- Products
- :
- General Topics
- :
- Questions about CPUSE on Maestro VSX
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)! 🙂
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The MHOs are already up to date, this issue is happening with the Security Group members.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It looks like you are experiencing that timeout issue, what JHF is installed on the SGMs?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
