Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Dave_F
Participant
Jump to solution

Upgrading form R81.10 to R81.20

I am upgrading my firewalls appliances members  in a cluster from R81.10 T87 to R81.20.

I am using the Installation and Upgrade Guide R81.20 page 417 on Zero Downtime Upgrade of a Security Gateway Cluster and it is not accurate!!

Procedure:
1. On each Cluster Member, change the CCP mode to Broadcast
Important - This step does not apply to R80.30 with Linux kernel 3.10 (run the
"uname -r" command).
Best Practice - To avoid possible problems with switches around the cluster
during the upgrade, we recommend to change the Cluster Control Protocol
(CCP) (CCP) mode to Broadcast.
Step Instructions
1 Connect to the command line on each Cluster Member.
2 Log in to the Expert mode.
3 Change the CCP mode to Broadcast:
[Expert@FW1:0]# cphaconf set_ccp broadcast
Notes:
This change does not require a reboot.
This change applies immediately and survives reboot.

Actual output:

1) First issue

[Expert@FW1:0]# cphaconf set_ccp broadcast

CCP mode is only unicast
This command is obsolete

[Expert@FW1:0]#

which is ok if that is not problem since it is only unicast now.

2) do we need to remove the standby member from the cluster and add it back in?

If so what is cli commands to add/remove member from a cluster?

   runnning "clusterxl_admin down

Actual output:

[Expert@FW1:0]# clusterxl_admin down
bash: clusterxl_admin: command not found
[Expert@FW1:0]#


4 Make sure the CCP mode is set to Broadcast:
cphaprob -a if


2. On the Cluster Member M2, upgrade to R81.20 with CPUSE, or perform a Clean Install of
R81.20
Important - You must reboot the Cluster Member after the upgrade or clean install.

With all that being said above what is the "exact procedure" since it is not listed?

Regards

 

Dave F

34 Replies
Matlu
Advisor

Hello, @Bob_Zimmerman 

To upgrade the Hotfix on my ClusterXL, a couple of doubts ...

1- Is part of the requirements that for the Hotfix upgrade to work, the SMS and the GWs that form the Cluster, must have Internet access? Or is it only necessary for the SMS to have Internet access?

2- In ClusterXL HA, to upgrade the Hotfix from the SmartConsole, the "step by step" is maintained as if it was done locally?
First I would start updating the passive, then I would "switch" from the GW CLI, and finally I would update the active, from the SmartConsole?
Is this the order?

Thanks for your comments.

0 Kudos
Bob_Zimmerman
Authority
Authority

First, you need to update CPUSE on the management. This can be automatic, or via thumb drive or whatever for an air-gapped management server. When you do any action with CDT, if the management's version of CPUSE is newer than the firewall's, CDT pushes the management's version to the firewall and installs it.

You don't need Internet access from any device. All you need is a way to get the jumbo you want to install into CDT's repository. This requirement can be fulfilled by giving the management access to the Internet and having it download the jumbo, or you can download the jumbo on some other system and bring it to a system with SmartConsole via thumb drive, DVD, or whatever.

Once the jumbo is in the management's repository, the management can push it to the firewalls. If the firewalls have access to the Internet, the management can also tell the firewalls to download it from Check Point themselves (nice for firewalls which have a big Internet connection but which are managed over a smaller WAN link). When you start the patch process via SmartConsole, this is controlled by the "Package Location Source" picker.

 

As for your second question, yes, the jumbo is installed on all standby members of the cluster first. Once the first standby is back up and talking with the management and the cluster reports it's healthy and synchronized, the cluster is failed over and the jumbo is installed on the formerly-active member. Upgrades follow a similar process, just with 'cphaconf mvc on' to enable cross-version sync before the failover.

The admin takes a single action to start the process, and that's it. All of the update or upgrade steps are handled fully mechanically.

Note that the cluster needs to be healthy. If any of the cluster members have any status other than ACTIVE, STANDBY, or BACKUP, the failover may not work.

0 Kudos
Matlu
Advisor

Hello,

Is it feasible, to try to do the "update" of the Hotfix, directly on the Cluster object?

By double clicking on the Cluster object, and sending the "Install Hotfix/Jumbo", without the need to do the 1x1 update.

JHF1.png

If you do it this way, do you have to be "careful" with the way the Cluster is "configured"?

I am referring to the correct option that must be selected in "UPON CLUSTER MEMBER RECOVERY".

JHF2.png

Doing the update directly on the cluster object, is it advisable?

Thanks.

0 Kudos
the_rock
Legend
Legend

Thats easy way of doing it, though I prefer old school method via web UI, but thats just me : - )

Andy

0 Kudos
the_rock
Legend
Legend

@Bob_Zimmerman described it perfectly.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    Thu 11 Jul 2024 @ 10:00 AM (BST)

    CheckMates Live London

    Tue 30 Jul 2024 @ 05:00 PM (CEST)

    Under the Hood: CloudGuard Controller Unleashed

    Thu 11 Jul 2024 @ 10:00 AM (BST)

    CheckMates Live London
    CheckMates Events