Central license open platform cluster hardware upgrade primary

[Adam276]

When upgrading hardware with central licensing on open platform, How do you deal with the upgrading the final primary system hardware during the upgrade in a way that you can fully test the secondary and still be able to have the management access the primary to remove the license on the primary after the secondary is verified working as expected?

I have seen steps where you issue a 'cpstop' command on the primary to make the upgraded secondary go active.  Wouldn't that break communications between management and the primary in a way that the management wouldn't be able to remove the license from the primary when it is time to upgrade the primary hardware?  I wouldn't want to remove the license from the primary until after the secondary is verified working so that a fail-over back to working state would be as quick as possible if secondary doesn't work.

Would clusterXL_admin down be better to use when switching to the secondary so that the primary would still be able to communicate with the management?  Or is it ok/safe to issue a cpstart on the primary after the secondary has taken over?  A note that the primary will still be on R80.10 and the secondary will be on R81.20 (in case that matters with the cpstart).

[G_W_Albrecht]

When installing on a new hardware, you automatically have the PnP license (14 days afaik) on it.  If you install config from backup this usually includes the license. Also, if you have the module/management portions of the license, you could install the module (GW) part manually (e.g. from CLI or WebGUI).

sk107042: ClusterXL upgrade methods and paths

R81.20 Installation and Upgrade Guide - Upgrade Methods

[Chris_Atkinson]

Is there some part of the license process that you're trying to avoid for some reason i.e. reactivation via UC?

1. Depends on the topology of the management interface is it clustered or private

2. Leveraging eval licenses temporarily is an option 

3. Licenses can be removed locally

[Adam276]

Chris,
The problem that I see is that the normal processes that are explained in the forums for hardware changes for as little downtime as possible involves running cpstop on the primary at some point where you make the secondary active.  If I do that, I assume management will not be able to detach (check back in) the central license from the old primary hardware when it is time to upgrade the primary hardware (after an hour or two of testing).  So management at that point will think it is still attached and maybe not allow me to reattach it again to the same object when I put the new hardware in place without detaching the old central primary license through SmartUpdate.

I am not trying to bypass anything.  I am just trying to get the license on the new primary hardware during the hardware upgrade process after the secondary has been upgraded.  The secondary is easy as I can detach that before I start the upgrade while the old secondary is still in cpstart state.  I will have the primary to failover to if the secondary fails so I don't want to detach any licenses or modify the primary in any way before the secondary has proven in good working state.

The primary will be in cpstop state though so the management will still think the central license is still attached (checked out) to the old primary when I remove it and put the new primary in place.  The management needs to know that the gateway central license it is no longer attached(checked out) to the old primary so that I can reattach it to the same object when new firewall is in place and SIC reset.  Is this figured out automatically somehow and will allow me to reattach it again to the same object that management thinks it has already been attached to?

Is there some mechanism for central licenses (attached to management IP) where the management will see that it has been attached in management but the gateway doesn't have it and allow it to attach it again or is there some other way to force detach the license in management so that it can then be reattached to the same object?


Albrecht,
Thanks for info but I didn't see any information about changing to new hardware and dealing with central licenses during the hardware upgrade process in those documents.

Everything I have read including on this forum has mentioned that you must use management to install central licenses on gateways (restoring from backups are an exception for like hardware). I use SmartUpdate for that.  This is going to new hardware (much newer) so the normal webui backup wouldn't work from what I have read and I am also transitioning to a new version at the same time so it the new hardware was installed from scratch with the new version.

The 14 day trial license has expired already, but even if I reinstall and it wasn't expired, that would only be temporary if the management has checked out the license already to the old hardware and thinks it is still attached when it really isn't (hardware was replaced)..

Thanks for the feedback on this.  Maybe there is some automatic stuff that happens in this scenario where management thinks a central gateway license is attached to a gateway but it isn't actually attached on the hardware itself (hardware replaced) so that it marks it as not checked out to that gateway anymore and allows you to reattach it or reattaches it automatically if it is checked out but not actually on the hardware.  I am being cautious as I haven't found anything that hints at that.

For regular licenses that are not central and don't require management to attach them, it is much easier I would think but for central licenses, management (SmartUpdate) has to check out and check in the licenses to know what they are attached to so that you can't attach a license twice.

[Adam276]

Is the answer to this to detach (check back in) the license using SmartUpdate when new hardware on the primary is put in place after establishing SIC?  Did Checkpoint plan for this and it would be corrected (checked back in) after that and then allow reattaching?  It would fail I would assume though because the license doesn't actually exist on the new hardware.  Maybe that is a problem.

[Chris_Atkinson]

CLI commands e.g. "cplic put" can be used locally on the gateway itself where the scenario requires it. 

Also 30-day eval licenses are available via self-service subject to acceptable use conditions:

https://usercenter.checkpoint.com/ucapps/prodeval

[Adam276]

Thanks but everything I have read indicates that cplic put for central licenses only works from the management server and can't be done from the local gateway itself.  I assume this is because the IP address for the license is the management server so maybe something special happens on the gateway itself to allow the management IP in the license to be valid instead of it's external IP when the license is attached from management.  An example mentioning that central licensing can only be attached from the management.
https://community.checkpoint.com/t5/Security-Gateways/Central-License-CLI-Security-Gateway/td-p/2981...

Are you saying though that it will actually work?  The IP in the license would be the management and not the external IP of the firewall.

What would be the procedure for central licensing (license contains IP of management) if you had a gateway failure and the backups were not working for example?  You would have to setup a new firewall from scratch.  The management would think the license is already attached (checked out) to the firewall, but you have put in a new firewall so it doesn't have the new license yet.  Would cplic put still work or would it give an error because the management thinks it is already attached? It actually isn't though because it is new hardware.  Maybe once SIC is established, pushing the license again manually form command line on the management to the remote gateway  would fix the mismatch and put the license on the remote gateway?  There must be a procedure for this scenario I would think.

[Bob_Zimmerman]

You can just use 'cphastop'. That stops all clustering, but leaves CPD, the firewall, and so on all running normally.

'cpstop && cpstart' would also work. When a cluster member comes online, it checks for CCP from an existing cluster member before deciding what state it should assume. If it detects a cluster with the same ID (and if you use the same objects, it will have the same ID) but running a different version, it will go to Ready rather than Active/Standby/Active Attention/Down/whatever else. A member in Ready state will become Active if it stops hearing the CCP traffic.

[Adam276]

Thanks for all the help and info on this.

Yea,  I am upgrading gateway hardware and software major versions at the same time for these central licensed firewalls.

That is good to know that the cphastop on the primary would not cause any issues with switching to the secondary.  I would have e expected it to work but was not sure since everything I read for hardware upgrades was to use cpstop.  I was worried during a major version upgrade and hardware upgrade there was some other thing that wouldn't allow it to switch or cause problems causing it to fail back.

Ideally what I would like to have is both the new and old hardware with the real license on it so that there are no other needed steps to put the license back on the old firewall in case of problems.  That is where I was hoping to find a working process to push the license to a new firewall even though management thinks it is already assigned to the same firewall object (but there is new hardware in place setup from scratch).  I would then have simpler steps as I could just switch back to the old hardware and it would have the license still on it.  This would be similar scenario with the management like I listed above where you have to replace a central licensed gateway where the backups are not working, etc.  Management thinks it has already attached and checked out the license to the gateway object but the new hardware doesn't have it yet.