replacing appliances in a SecurityGroup with newer hardware

[Wolfgang]

Following sk162373 - Quantum Maestro supported combinations of mix-and-match appliances it's possible to mix different appliances for migration.

"Quantum Maestro supports all other combinations for migration purposes. For example, suppose you would like to replace a 6500 Security Appliance model with a 16200 Security Appliance model: In this scenario, you can include the two Security Appliance models in the same Security Group, allow it to clone the configuration to the 16200 Security Appliance model, remove the 6500 Security Appliance model, and continue to work with the 16200 Security Appliance model only. This migration procedure should include CXL / SND cores configuration and adjustment on new Security Appliances models, which requires downtime because of the reboot. As a result, you must do the migration during a maintenance window."

But now we are on the way doing such migration and have some problems. Often we got an advice from TAC not
adding the appliances to the old SG, creating a new SG with the new appliances should be the way. But this will
result in a needed longer maintenance schedule and much more work to do.
And this will be contrary to the scalability of Maestro.

As an example we want to replace 6600 with 9300 and 16600 with 9700.

Any experience with that or any suggestions ?

[AkosBakos]

Hi @Wolfgang 

We do have experience with the change (CP6500 -> CP9300):

A short summary of the chnage: 

• removed the 2 old SGMs from site A
• put the new SGM to site A
• Came up in down state (it took ~10 minutes)
• #cphaprob synscat showed policy installation error
  • realized that the original lic expired - we knew that therefore created EVAL earlier-  and the EVAL license has just expired - (that1s the fun fact) 
    • we assume that because of the lack of valid lic (in this situation only InitialPolicy was availabe on the SGM) the SGM couldn't pull from its own lic from the usercenter (the initialPolicy didn't allower the traffic to usercenter)
• We created a new EVAL for the new SGM
• install the lic with cplic put
• rebooted the SGM, then it came up in Active state
• install the necessary jumbo take 
• than manual failover to the new SGM

The arrange of the other three SGMs into Security Group were easy after this experience.

Cleaunup: we remoed all EVAL licenses from the SGM-s g_cplic del <signature>

If you have question, and if you want, contact me in private, or drop an update here.

Here is the tread: https://community.checkpoint.com/t5/General-Topics/MAESTRO-SGM-change/m-p/233169#M38960

Akos

[emmap]

I've done it recently, I found it easier to add a new one, patch it up to required JHF level, remove all the old ones, then add the remaining new ones with auto-clone enabled, then check/enable dynamic balancing as required. 

[Wolfgang]

@emmap that's what we expected. We can add the 9700 to the SGM with 16600 but nothing happened and the appliance does not reboot to join the SG. SGM is shown as member of the SG, not seen in Cluster state, no error in messages. If we remove the 9700 from the SGM the mini reset is run, the appliance reboots and is back online again as unattached.

[emmap]

I've heard of that happening, you can try rebooting the SMO SGM while it's waiting to add, I've heard of that helping, or even I've heard it just starts after 2 hours. I had it happen to me but it was the second new SGM, so I went to what I said above and removed all the old ones before auto-cloning it into the group, which worked fine. The slient_install log file showed nothing useful unfortunately, I don't know what causes the issue.