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

Upgrading COREs license.

Hello all,
there is Check Point R80.10 cluster (Open Server). We are upgrading licenses because expired.
New licenses are for 8 COREs; old/current one are for 4 COREs.

We installed licenses from Management on two nodes and rebooted the standby node. Now, running the cphaprob stat command on rebooted node I get:

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

Number Unique Address Assigned Load State

1 (local) 10.10.50.1 0% Ready

Ready state reason: another member was detected with a lower number of CoreXL instances.

How can we complete the operation without causing service disruption ?

Thank you,
Luca

 

 

 

0 Kudos
2 Solutions

Accepted Solutions
Timothy_Hall
Legend Legend
Legend

There isn't a disruption, the active member is still up and passing traffic.  The member with the new license can see the active member has a different configuration and is ready to take over once it goes away.  The cluster members are not currently synchronized at this point, so to blunt the effect of a non-stateful failover I'd recommend unchecking "Drop out of state TCP packets" in the global properties before doing this.

Simply update the license on the currently-active member and reboot it, as soon as it drops from the network the member in "Ready" state will take over as active.  After booting back up the cluster should go back to active/standby.  Generally changing the core split (in your case due to a license change) should be treated as a version upgrade, see this document for more info:  Best Practices - Cluster Connectivity Upgrade (CU)

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com

View solution in original post

0 Kudos
Maarten_Sjouw
Champion
Champion
In the Overview page, even if you have 20 cores, it will still only show the highest used 3 cores. When you go to the CPU page you will see that all Cores are in use.
Regards, Maarten

View solution in original post

4 Replies
Timothy_Hall
Legend Legend
Legend

There isn't a disruption, the active member is still up and passing traffic.  The member with the new license can see the active member has a different configuration and is ready to take over once it goes away.  The cluster members are not currently synchronized at this point, so to blunt the effect of a non-stateful failover I'd recommend unchecking "Drop out of state TCP packets" in the global properties before doing this.

Simply update the license on the currently-active member and reboot it, as soon as it drops from the network the member in "Ready" state will take over as active.  After booting back up the cluster should go back to active/standby.  Generally changing the core split (in your case due to a license change) should be treated as a version upgrade, see this document for more info:  Best Practices - Cluster Connectivity Upgrade (CU)

 

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
lucafabbri365
Collaborator

Hello Timothy,
thank you for your reply.

Basically we run cpstop from the "Active" member. After few seconds the "Ready" becomes active, and then we rebooted the other node (that was previously active). So a simply reboot could resolve the issue. We didn't touch "Drop out of state TCP packets" option that is/was configured as below:

Global Properties.PNG

Just a quick question (even if out of this post): we updated licenses from 4 COREs to 8 COREs. All is working fine now but if I run "cpview", I see only 3 CPUs:

cpview.PNG

Can you explain me why ? Are they referred to SND ?
This is the output of fw ctl affinity -l -r command:

CPU 0: eth6 eth7 eth0
CPU 1:
CPU 2: fw_5
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 3: fw_4
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 4: fw_3
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 5: fw_2
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 6: fw_1
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 7: fw_0
usrchkd pepd rtmd vpnd in.msd pdpd fwpushd in.acapd rad fwd mpdaemon lpd cpd cprid
CPU 8:
CPU 9:
CPU 10:
CPU 11:
CPU 12:
CPU 13:
CPU 14:
CPU 15:
All:
The current license permits the use of CPUs 0, 1, 2, 3, 4, 5, 6, 7 only.

Thank you,
Luca

0 Kudos
Maarten_Sjouw
Champion
Champion
In the Overview page, even if you have 20 cores, it will still only show the highest used 3 cores. When you go to the CPU page you will see that all Cores are in use.
Regards, Maarten
Compugraf_Supor
Explorer

@Timothy_Hall , @Maarten_Sjouw , @lucafabbri365 

I have a question envolving licenses and CoreXL.

Today I have a gateway licensed for 4 cores and I want to enable it for 12 Cores. 

If I buy a new CPSG for 8 Cores will the Gateway and SmartUpdate accept a second license for this gateway ?

Will it enable 4, 8 or 12 Cores ? 

Is it Ok according to license agreement ?

Once I have attached 2 trial licenses for a gateways and it enabled 16 cores. I don´t know if is is specific for trails and if it is ok for license agreement. 

 

Regards

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events