Clarification Required on Build, Take, JHF, and CPUSE?

[Saranya_0305]

Dear Mates,

We have cluster setup running in R81.20, but recently one of the device faulty and we get the new device with same version.

When we try to put it in cluster setup it is getting failed with below message.

Reason for state Change: Member with older software version has been detected.

When we check the Build Numbers

New RMA device : Build is 707
Our Running device : Build 055

But both are in same R81.20 version and Take 634.

Deployment Agent_2672 on both devices.
Jumbo Hotfix Take_119 on Running device and on new device no JHF.

What is the difference between JHF, Deployment Agent(CPUSE),Take and Build No?

Can you help me on this, is there any way to upgrade the Build No?

Regards,

Saranya

[Martijn]

Hi,

When a new major version is released, there is a build number. This has nothing to to with JHF or CPUSE agent.
When looking for an ISO, the base build number is shown.

Sometimes Check Point releases a new build of the base version. Please Check:

https://sc1.checkpoint.com/documents/R81.20/WebAdminGuides/EN/CP_R81.20_RN/Content/Topics-RN/Build-N...

There is mentions a new build was released in June 3rd 2024 because of the VPN CVE.

So the RMA has a newer build of the base R81.20

Regards,
Martijn

[Saranya_0305]

Hi,

Actually we upgraded the Running device to R81.20 from R81.10.

Is cluster issue is related to build no. or JHF ?

If it is related to Build no. How can we upgrade Build no.?

Regards,

Saranya

[Martijn]

Hi,

If old member is on R81.20 JHF take 119 and the new one is on R81.20 with no JFH, the cluster status seems to be related to the JHF.

A cluster member with a higher version will never become active if all  pnotes are OK on both members.
Sometime, if there is a big difference in JHF this is also can happen. In your case, there is a big difference.

Once both members are on R81.20 JHF take 119, this message will be gone.

Martijn

[simonemantovani]

Hello

I agree with the thread of @Martijn ... The Build it's related to the major release installed... it's recommended to install the latest JHF on your gateway, it's not recommeded not to have JHF installed; so the first best thing to do is to have the same JHF on both gateways.

Deployment Agent is the service in charge to manage software update, if this service is not running you can't perform upgrade; usually to upgrade to a newer release could be necessary to have installed the latest version of Deployment Agent (upgrade of Deployment Agent could be done automatically or manually by importing the package download from UserCenter).

[Steffen_Appel]

To be a little more specific, newer builds may include certain jumbos.

[emmap]

The command 'show version all' from clish will show you the base OS build.

'fw ver' shows a build of the software that is unrelated to this and can change with JHF installs.

The DA build is unrelated to either of the above.

The JHF take is the build of the JHF that is installed. This will never affect the base OS build.

You should always make sure your cluster members are running the same CP Version (OS Build generally less important) and JHF take.

[the_rock]

Hey @Saranya_0305 

I believe you got all the right answers already. Did you sort this out?

[Vanness_Chen]

Hi @Saranya_0305 

I encountered a similar situation last month while deploying newly purchased SG3970 appliances for a customer, and the root cause was quite similar to what you described.

At that time, both gateways were initially installed with R82.10 Build 271. However, one day before going live, the second SG had to be reinstalled. Since I didn’t have the same ISO version on hand, I downloaded a newer ISO from the official website.

After the installation, the cluster remained in a down state, showing a target version mismatch. I later realized that the issue was caused by an OS build mismatch — the reinstalled gateway was running Build 464.

As a workaround, I enabled MVC (Multi-Version Cluster) to resolve the issue. However, this is not an ideal long-term solution. It is still recommended to install both gateways using the exact same ISO version to avoid such problems.

[emmap]

In this specific example you have more than just a different build with minor differences, those two R82.10 builds have different hotfixes included. So in your case it is very important to upgrade or rebuild the original gateway to the new build. I recommend fresh building off the new ISO so that the factory defaults image is updated, and for consistency with the newer built gateway.