Maestro SGM Hardware upgrade 6000 to 9000

[Maheshreddy]

I recently came some thread and found it extremely insightful—thank you for sharing your experience.

I’m currently managing a Maestro setup with:

• 2 Maestro Orchestrators on R81.10

• 1 Security Group with 3x 6600 SGMs, all running R81.10 JHF 110

We are planning to replace the 6600 SGMs with 9300 appliances, which come preloaded with R81.20.

I have a couple of questions based on everyone experiences

1. Did you upgrade your Maestro Orchestrators and existing SGMs to R81.20 before introducing the new 9300 SGMs?

2. If all components (Maestro + existing SGMs + 9300) were already on R81.20, were you able to add the 9300 appliances directly into the Security Group without issues?

Any insights or best practices from your upgrade process would be greatly appreciated.

Mahesh

[emmap]

If you want to migrate your existing SG config to the 9300s, you must upgrade the MHOs and existing SGMs to R81.20 first. Then you can add the 9300s to the security group and remove the 6600s. 

[Martijn]

Mahesh,

You need to upgrade to R81.20 before adding the 9300 appliances to the Security Group. But keep in mind the combination 6600 and 9300 is supported only for migration. Not for a long term production environment.

sk162373 - Quantum Maestro supported combinations of mix-and-match appliances

The 9300 appliances can be added to the Security Group and will become active, but I will advice a maintenance window.

You have to look at the CoreXL configuration of the 6600 appliances to know how the 9300 will behave. The 9300 will use the same number of Firewall Workers (if possible) as the 6600 when joining. You may need to change this after the migration is completed and you may experience interruptions. Or maybe Dynamic Balancing is already enabled on your setup.

You can choose to set the 9300 down on the first join so you can install the latest hotfix and check everything before making the 9300 active:

#set chassis high-availability down_on_join 1

And do not use the Auto-Clone feature.

#set smo image auto-clone state off


Please also check:

sk182838 - Maestro - migration of Security Group Member from the old line of Check Point appliances ...

Regards,
Martijn

[Maheshreddy]

AFter upgrading to R81.20 and I am able to add 9300 to security group but its not coming as active. Working with checkpoint to fix the issue now and may be we are ending up with RnD. Just an FYI we tried to migrate from 6500 to 9300.

[Nir_Shamir]

usually the new SGM can't fetch and install the policy because of licensing issues or missing updatable objects DB.

[CKing]

We saw a similar issue in our lab (we've got our first migration attempt this weekend)

We had Take105 on the existing appliances, and had to install Take105 on the 9300 before it would show active.

Because it doesn't come up properly, we couldn't just copy the JHFA from the active member. We had to SSH from the orchestrator using the CIN network (198.51.10x.x ranges) onto the new 9300. Once on the 9300, we then killed the cpha_blade_config process to stop the reboot loop. 

We then copied the JHFA to one of the MHOs and used scp to copy from the MHO to the 9300 via the CIN network. We could then install the JHFA on the 9300 and after the post-install reboot it comes up. (subject to licenses being applied)

[Maheshreddy]

So after installing the hotfix how did you add 9300 to security group to become active?

Along with that how did you kill cpha_blade_Config process?

[CKing]

After installing the hotfix, it was just a case of ensuring the correct license was installed on the 9300. We followed the "Part 2 - Install the license on a specific Security Group Member that is not the SMO" from the admin guide.

To kill the process, once you've managed to SSH onto the new SGM from an Orchestrator via the CIN network you need to run the following to get the process ID and kill it

# Identify the process ID of the cpha_blade_config process
[Expert@LAB-SG-ch02-01:0]# ps aux | grep cpha
admin 13236 0.0 0.0 2648 576 pts/2 S+ 13:58 0:00 grep --color=auto cpha
admin 26625 0.0 0.0 6540 4380 ? S 13:55 0:00 /bin/sh /opt/CPsmo-R81.20/bin/cpha_blade_config post_fwstart

# Kill the Process
[Expert@LAB-SG-ch02-01:0]# kill 26625

[Maheshreddy]

WHile removing 6500 after 9300's are in cluster. Did you find any packet drops or outage?

[CKing]

None that any of our monitoring or applications noticed. The behaviour is similar to either adding/removing members normally or doing a g_clusterXL_admin down if you're a dual site setup. 

If you have a couple of spare old SGMs, I'd highly recommend building a test security group and running through the process start to finish. Really helped our team get the confidence we needed by seeing it in a controlled environment