Checkpoint Maestro VSNext CoreXL FWL Instances

[Sorin_Gogean]

Hello everyone,

Now that we clarified the SIC issue we were having for some time (Thank you  @Gennady  and @emmap for the resolution) we migrated the first DataCenter 2 weeks ago. 

Everything works fine on the vFW we have created on the 3 x SG9400 cluster as per below insights snapshot:

Now, on the question I have. 

When I created the VS FW, I have set 16 CoreXL Firewall instances. This we can validate with "fw ctl multik stat":

[Expert@XXXX-SGFW01-s01-01:0]# vsenv 4
Context is set to Virtual Gateway XXXX-vFW01 (ID 4).
[Expert@XXXX-SGFW01-s01-01:4]# fw ctl multik stat
ID | Active | CPU | Connections | Peak
-----------------------------------------------
0 | Yes | 2-19 | 3816 | 6554
1 | Yes | 2-19 | 3763 | 6815
2 | Yes | 2-19 | 3879 | 6728
3 | Yes | 2-19 | 3814 | 6751
4 | Yes | 2-19 | 3876 | 6677
5 | Yes | 2-19 | 3934 | 6688
6 | Yes | 2-19 | 3850 | 6701
7 | Yes | 2-19 | 3803 | 6666
8 | Yes | 2-19 | 3833 | 6776
9 | Yes | 2-19 | 3817 | 6759
10 | Yes | 2-19 | 3805 | 6684
11 | Yes | 2-19 | 3822 | 6681
12 | Yes | 2-19 | 3873 | 6721
13 | Yes | 2-19 | 3780 | 6759
14 | Yes | 2-19 | 3827 | 6718
15 | Yes | 2-19 | 3818 | 6765
[Expert@XXXX-SGFW01-s01-01:4]#

But if we check the insights screenshot, we can see FW/SND as 18/2 . Why is that since we set it 16 ?
Is it OK to consider the number of CoreXL's like an reservation, but then why we see on Insights higher numbers than what we set?  Why are those not matching?

Aside of that, this VS FW is for Internet and DMZ and it would not go over 5Gbps in the next years. So now that I think of, setting 16 CoreXL's it's over-subscription .

On this 3 x SG9400 cluster, we'll have to add an 2nd VS, for traffic that will be served by 2 x 100Gb links from DC Distribution to our DC ACI. In other words we're looking into firewalling out WHOLE Data Center traffic.

So if I have set 16 CoreXL's on the first one, what is the remaining horsepower that I could set on the new VS ?

Also I was thinking of lowering the 16 CoreXL to 12 or 10 - as i was getting recommendations initially when we were looking for the OLD 15600 cluster replacement.

Some research/AI pointed me to this resource and it seems that I can use the command below, still is unclear if I have to restart things, or do in in a specific order.
"set vsnext corexl-instances virtual-gateway <VS_ID> ipv4-instances 10 wait-for-task true"

I'll see and validate this in our Singapore cluster, and see there how it will this behave, but I wanted some other opinions. 


Let me know if there are other things I need to clarify and I will gladly respond.

Thank you,

[Bob_Zimmerman]

CoreXL on VSX is a little weird. You have the hardware thread pool, which is the 18/2 you see. This represents the resources available on the box.

You also have the number of workers each VS is allowed to use, which is the 16 you configured. This is meant as a bulkhead so a volumetric DoS against one VS can only break traffic through that VS. The way you adjust this is to use gclish to run 'set vsnext corexl-instances virtual-gateway <VS_ID> ipv4-instances <##>', and it involves a hard outage for the VS.

The 9400 has 14 cores, and only six are performance cores. Hyperthreads are slower than efficiency cores, and efficiency cores are slower than performance cores. I personally wouldn't use more than eight CoreXL instances total split between your VSs.

[emmap]

To add to Bob's post: The CoreXL/VS that you configure for VSs is an amount of user mode threads for the FWK process for that VS. These usermode threads will request CPU time from the CoreXL pool (the 18 cores in your config) when they need to do work. The Linux process scheduler will manage this for you, there is no requirement to statically allocate specific threads to specific cores. The core split between SND and CoreXL pools will be dynamically managed by the Dynamic Balancing mechanism, ensuring that low level packet processing (SND/SXL) and inspection processing (CoreXL) don't interfere with each other and have enough CPU cores to do what they need to do.

As the VS FWK threads are user mode processes, it's fine to oversubscribe somewhat for amount of threads vs amount of available CPU cores.. but only to a point. HCP for example will through a warning when you are under- or over-subscribed - less total threads than cores available (thus throttling potential performance) or more than 2x threads than cores available (potentially choking out the system). So you can go over the cores available, but don't overdo it.

Lastly, I know you know this but for anyone else reading - CoreXL per VS is a per-SGM configuration in a Scalable Platform deployment. So don't go configuring it thinking that it's a single total spread across all cores in all SGMs.