Failed to upgrade from SmartConsole

[CP-NDA]

Hi,

I want to use the central upgrade for the first time in SmartConsole. The upgrade will be from R81.10 to R81.20 lates HFA

In SmartConsole when choosing a Gateway > Actions > Upgrade Version I have the following error

Failed to search for package Blink_image_1.1_Check_Point_R81.20_T631_JHF_T41_SecurityGateway.tgz on the Check Point Download Center. Reason: Unknown Error.

I then tried to import a package in the repository from cloud and get the following error

I've internet connectivity from the Management & SmartConsole: https://support.checkpoint.com/results/sk/sk83520

How can I troubleshoot the package download ? Is this download initiated by the Management ou the SmartConsole ?

Thank you

[Boaz_Orshav]

Hi

  First of all "Unknown error" is never a good option so once we get the logs I'll try to find the best error that should be issued.

  Secondly regarding your question - on your first attempt the Smart Console "asks" the Gateway to install the recommended package so the Gateway tries to download the package from the cloud and fails.

  The second attempt was to download to the repository which is placed on the Management machine so the Management is initiating this action (and not the Smart Console)

  To solve it I will appreciate if you can run (expert mode on Management machine) "collect_logs.bash" and send me the resulted tgz file to boazo@checkpoint.com

  As a work around you can download the package from the SK and then upload it to the Package Repository locally

Thanks

Boaz

[CP-NDA]

Thank you ! Sent via email 

Unfortunately it means that with this Workaround all GW will download the file from the Management. We would prefer from cloud for performance reason (65 GW to upgrade)

[the_rock]

I know there would be lots of people who will disagree with what I will say, but personally, I NEVER do any upgrades from smart console. I find its very unreliable (based on my lab tests) and doing it old school way from web GUI is what I always stick with and works totally fine.

Best,

Andy

[NetAdminFTW]

Hey Andy,

Can you list the "old school way" steps regarding cluster upgrade? Specifically hotfix patching?

[the_rock]

Super easy. ALWAYS do these steps on whichever one is backup member first, which can be verified by cphaprob state or cphaprob roles commands.

-log into web UI, status and actions, confirm right jumbo

-right click, verify

-if all green, just hit install

-wait until reoots, run cphaprob state to make sure it still shows backup and and also cpinfo -y fw1 to confirm new jumbo

-do same steps on master, and once rebooted, it would show as backup member and to fail back (if you like), run clusterXL_admin down; clusterXL_admin up on first member (original backup)

-install policy

Thats it 🙂

Andy

[NetAdminFTW]

Thanks for the comment.

Regarding the last step, I run both clusterXL_admin commands on the original backup? Or do I need to run admin_down on the original backup and admin_up on the original active?

[the_rock]

You do it EXACTLY how I did it below (from my lab example) and if you get worried/concerned/confused or all 3, ping me and we can do remote.

Andy

****************************************************

Send automatic password
Access denied
admin@172.16.10.247's password:
Last login: Tue Jul 2 10:07:02 2024 from 100.65.16.1
[Expert@CP-FW-02:0]# cphaprob roles

ID Role

1 Non-Master
2 (local) Master

[Expert@CP-FW-02:0]# cphaprob state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 169.254.0.112 0% STANDBY CP-FW-01
2 (local) 169.254.0.111 100% ACTIVE CP-FW-02

Active PNOTEs: None

Last member state change event:
Event Code: CLUS-114904
State change: ACTIVE(!) -> ACTIVE
Reason for state change: Reason for ACTIVE! alert has been resolved
Event time: Mon Jul 1 17:15:47 2024

Last cluster failover event:
Transition to new ACTIVE: Member 1 -> Member 2
Reason: ADMIN_DOWN PNOTE
Event time: Mon Jul 1 16:47:00 2024

Cluster failover count:
Failover counter: 3
Time of counter reset: Thu Jun 27 20:23:48 2024 (reboot)

[Expert@CP-FW-02:0]# clusterXL_admin down;clusterXL_admin up
This command does not survive reboot. To make the change permanent, run either the 'set cluster member admin {down|up} permanent' command in Gaia Clish, or the 'clusterXL_admin {down|up} -p' command in Expert mode
Setting member to administratively down state ...
Member current state is DOWN
This command does not survive reboot. To make the change permanent, run either the 'set cluster member admin {down|up} permanent' command in Gaia Clish, or the 'clusterXL_admin {down|up} -p' command in Expert mode
Setting member to normal operation ...
Member current state is STANDBY
[Expert@CP-FW-02:0]# cphaprob state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 169.254.0.112 100% ACTIVE CP-FW-01
2 (local) 169.254.0.111 0% STANDBY CP-FW-02

Active PNOTEs: None

Last member state change event:
Event Code: CLUS-114802
State change: DOWN -> STANDBY
Reason for state change: There is already an ACTIVE member in the cluster (member 1)
Event time: Wed Jul 3 08:35:00 2024

Last cluster failover event:
Transition to new ACTIVE: Member 2 -> Member 1
Reason: ADMIN_DOWN PNOTE
Event time: Wed Jul 3 08:34:59 2024

Cluster failover count:
Failover counter: 4
Time of counter reset: Thu Jun 27 20:23:48 2024 (reboot)

[Expert@CP-FW-02:0]#

*****************************************************

[NetAdminFTW]

Thanks a lot for this. I now got it.

[the_rock]

Did it work?

[NetAdminFTW]

I did the upgrade using SmartConsole, but I used your example in order to failover back to the original active member. Thanks!

[the_rock]

Good job!

[Robin_H]

Any updates on this? I have the same issue.

[the_rock]

I recently used this method for jumbo update on R81.20 and was fine. Whats version you are upgrading from and to?

Andy

[Robin_H]

R81.10 Take 130 to R81.10 Take 139

[Amir_Senn]

I think that CPUSE might provide more detailed error. Perhaps you can use it on a single GW and use verify on the package. If you have a lot of GWs this worth a shot.