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

Oracle Cloudguard upgrade from 80.40

Hi,

 

Is there a guide or steps to follow  for upgrading OCI Cloudguard from R80.40 to R81.10? Already checked sk162365 .

 

Thanks

0 Kudos
2 Solutions

Accepted Solutions
avivs
Employee Alumnus
Employee Alumnus

With In-place upgrade not supported on Oracle, the only option for upgrading the version of the gateway is to deploy a new gateway.

View solution in original post

Jeff_Engel
Employee
Employee

Hi @fpaez ,

Apologies for not seeing this post sooner!  Here are the steps I have used for this procedure(also should not require new public IPs):

1.) Document all VCNs/subnets/etc for the current Standby member

                eth0 >

                eth1 >

                VCN >

                Frontend subnet >

                Backend subnet >

2.) Document all Gaia static routes

3.) Stop the Standby member

4.) Create new R80.40(or whatever the relevant target version is) firewall instance using upgraded shapes with same amount of OCPU's as existing and use Hardware-assisted SRIOV/VFIO networking

5.) Create backend interface and attach to appropriate VCN/subnet...check Gaia to make sure backend real IP is set on eth1...might need to be done manually

6.) Complete first-time configuration and apply same jumbo hotfix(if needed) as installed on Active cluster member

7.) Ensure that CoreXL instances match on both cluster members...update and reboot if needed

8.) Re-apply static routes to new firewall instance

9.) Add new firewall instance OCID to the proper OCI Dynamic Group so that cluster API calls will continue to work

10.) In SmartConsole, reset SIC on existing Standby member object and update IP address to match newly built firewall

11.) Establish SIC

12.) Update cluster topology - Network Management > Get Interfaces with Topology...ensure new firewall instance IP's are reflected

13.) Push policy and verify cluster state

14.) During maintenance window, test a failover

15.) Detach/attach licenses as needed

16.) Repeat above steps for remaining cluster member

 

Also recommend talking to your local Oracle engineer and Check Point architect.  Please reach out if you need further assistance or have questions.

Best Regards,

Jeff

View solution in original post

(1)
6 Replies
PhoneBoy
Admin
Admin

You can’t do an in-place upgrade on Oracle yet to the best of my knowledge.
Which means doing an advanced upgrade for the management, which is covered in the Install/Upgrade guide.

avivs
Employee Alumnus
Employee Alumnus

Supported platforms, versions & configuration for in-place upgrade in CloudGuard products is described in sk177714 - CloudGuard for Public Cloud In-Place upgrade packages.

 

At the moment, only Azure & AWS are supported.

ishuyell
Participant
Participant

Yes, I understand that. I  was looking for a guide to upgrade the gateway and not  for in-place upgrade.

0 Kudos
avivs
Employee Alumnus
Employee Alumnus

With In-place upgrade not supported on Oracle, the only option for upgrading the version of the gateway is to deploy a new gateway.

fpaez
Explorer

Hi,

I understand that we have to deploy new gateways, but this involves creating new public IPs, and new floating IPs for failovers, we know how to manage Check Point but cloud providers have their own procedures to move resources between VMs and I think the idea of the question in this post is to have the correct procedure to do that for OCI Cloud, for other cloud providers (AWS, Azure) the procedure is very clear  and you can replicate it on a lab, and we want to do the same on OCI. In my case, we need to upgrade from R80 to R81.10

Best regards,

RFP

0 Kudos
Jeff_Engel
Employee
Employee

Hi @fpaez ,

Apologies for not seeing this post sooner!  Here are the steps I have used for this procedure(also should not require new public IPs):

1.) Document all VCNs/subnets/etc for the current Standby member

                eth0 >

                eth1 >

                VCN >

                Frontend subnet >

                Backend subnet >

2.) Document all Gaia static routes

3.) Stop the Standby member

4.) Create new R80.40(or whatever the relevant target version is) firewall instance using upgraded shapes with same amount of OCPU's as existing and use Hardware-assisted SRIOV/VFIO networking

5.) Create backend interface and attach to appropriate VCN/subnet...check Gaia to make sure backend real IP is set on eth1...might need to be done manually

6.) Complete first-time configuration and apply same jumbo hotfix(if needed) as installed on Active cluster member

7.) Ensure that CoreXL instances match on both cluster members...update and reboot if needed

8.) Re-apply static routes to new firewall instance

9.) Add new firewall instance OCID to the proper OCI Dynamic Group so that cluster API calls will continue to work

10.) In SmartConsole, reset SIC on existing Standby member object and update IP address to match newly built firewall

11.) Establish SIC

12.) Update cluster topology - Network Management > Get Interfaces with Topology...ensure new firewall instance IP's are reflected

13.) Push policy and verify cluster state

14.) During maintenance window, test a failover

15.) Detach/attach licenses as needed

16.) Repeat above steps for remaining cluster member

 

Also recommend talking to your local Oracle engineer and Check Point architect.  Please reach out if you need further assistance or have questions.

Best Regards,

Jeff

(1)

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.