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

ElasticXL and VSNext CoreXL question

Hello,

We have a pair of 2 9100 devices configured in ElasticXL and with VSNext enabled. We're just running 2 Virtual System in these appliances. 

The 9100 devices have 8 CPU Cores with CoreXL being distributed 2 for SND and 6 to FW workers.

Since this is ElasticXL and when we run "cphaprob state" we have the ACTIVE(P)/ACTIVE result, how can I read this in terms of the CoreXL? So, do we have just 8 CPU Cores, considering just a single machine of the ElasticXL cluster, or we have 16 CPU Cores?

Regarding the distribution of the CoreXL instances, I was thinking in something like this:

  • 2 Cores => SND
  • 1 Core => VS0
  • 4 Cores => VS1
  • 1 Core =>VS2

Is this distribution make sense for you? Should I consider for the 16 CPUs? Or maybe I should only consider 16 CPUs if I had a third 9100? What is your opinion on this?

Please be aware that this is not yet in prod environment. We're still preparing the final topology, before we start the migration.

Thanks in advance.

Kind regards.

0 Kudos
1 Solution

Accepted Solutions
emmap
MVP Gold CHKP MVP Gold CHKP
MVP Gold CHKP

Your CoreXL per VS configuration a 'per SGM' configuration, so you should be planning based on 8 CPU cores. Hence, your proposed distribution sounds fine to start with. If you find that VS2 needs an extra thread it's OK to just add one there without lowering the VS1 configuration, as they are user mode threads and can happily share cores with the presumably minimally used VS0 thread - just don't go too far with this. 

View solution in original post

10 Replies
emmap
MVP Gold CHKP MVP Gold CHKP
MVP Gold CHKP

Your CoreXL per VS configuration a 'per SGM' configuration, so you should be planning based on 8 CPU cores. Hence, your proposed distribution sounds fine to start with. If you find that VS2 needs an extra thread it's OK to just add one there without lowering the VS1 configuration, as they are user mode threads and can happily share cores with the presumably minimally used VS0 thread - just don't go too far with this. 

Oryx
Collaborator

Hi.

Thanks for your opinion. I think it does not differ to much from what I was expecting. 

Regarding VS0, it will only be for Management purposes of the ElasticXL cluster. So I think is more than enough for it

Kind regards

0 Kudos
emmap
MVP Gold CHKP MVP Gold CHKP
MVP Gold CHKP

Yes, typically VS0 is fine with just the 1 thread.

0 Kudos
Oryx
Collaborator

Hi again,

Sorry, but since my last update, I had a colleague of mine deploying another VSNext Cluster and we've had some information from our Check Point Sales Engineer that is quite confusing. I would like to have your thoughs on that. So, basically he told us the following:

  1. The VS0 count for the number of licenses. So we've bought a license for 2 Virtual Systems. In the old ways (VSLS on R81.20, for example), that would mean VS0 and two additional VS, for example VS1 and VS2. It's the same for VSNext? Or the VS0 is now counted as a VS on the license and should be used not only for management?
  2. Regarding the CoreXL distribution, the recommendation on VSLS was to assign the number of Cores on Smart Console for each Virtual System, saving 1 for VS0, and use CoreXL Dynamic Balancing for the platform to manage by herself which of the Cores were assigned to the Virtual Systems. Like I've referred previously, a Check Point Sales Engineer told us that in VSNext we should not change the default value assigned to each Virtual System, when we created them, since now that is completely managed by the CoreXL Dynamic Balancing. Do you have any thoughts on this?

I must confess that for me bot of those notes are not resonating very well on my head, but I would like to have your opinion if it's possible. 

Kind regards.

 

 

0 Kudos
emmap
MVP Gold CHKP MVP Gold CHKP
MVP Gold CHKP

1. My understanding is that the licensing hasn't changed with VSNext, so VS0 is not counted as a VS when adding VS licenses to a gateway. I would generally defer to the sales team when it comes to licensing though. 

2. Dynamic Balancing does not change the CoreXL per VS configuration for each virtual system, it only changes the allocation of SND vs CoreXL pool cores on the gateway. So you do have to configure the CXL/VS settings. In Legacy VSX we do that in SmartConsole, for VSNext we do it on the gateways. So, don't change the CoreXL configuration inside the 'cpconfig' menu on the gateways, but do configure the CoreXL per VS configuration on each Virtual System. 

0 Kudos
Oryx
Collaborator

Should I run cpconfig on VS0 and disable the CoreXL or not? That was what I did in VSLS deployments, sine VS0 was only for Management of the VSX Cluster. 

0 Kudos
Oryx
Collaborator

Regarding the licenses, this is the output on Smart Console.

Captura de ecrã 2025-11-12 100839.png

Which don't make sense for me, since the end customer have bought 2 Virtual Systems Licenses. 

 

0 Kudos
Oryx
Collaborator

Captura de ecrã 2025-11-12 113144.png

The * is pretty much the confirmation that VS0 is only for management but counts for the VS number license. 

0 Kudos
Chris_Atkinson
MVP Gold CHKP MVP Gold CHKP
MVP Gold CHKP

This is how it works for the _base_ license if you have for example a VS10 add-on license it is VS0 + 10.

CCSM R77/R80/ELITE
Oryx
Collaborator

Hi Chris,

Thanks for your confirmation. I was not aware of this.

Regards

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events