Two cores and CoreXL and SecureXL with R80.20

[Don_Paterson]

With R80.20 now running the fast path through the software rather than at L2 does this mean better or worse performance would be expected on for example a 4200 appliance?

In that example should a customer consider R80.10 over R80.20 to get better acceleration?

Last question: If QoS was used then which would be better, R80.10 or R80.20?

Asking because of the major changes in R80.20

Thanks,

Don

[HeikoAnkenbrand]

Hi @Don_Paterson 

R80.20 and above:
- SecureXL has been significantly revised in R80.20. It now works in user space. This has also led to some changes in "fw monitor"
- There are new fw monitor chain (SecureXL) objects that do not run in the virtual machine.
- Now SecureXL works in user space. The SecureXL driver takes a certain amount of kernel memory per core and that was adding up to more kernel memory than Intel/Linux was allowing.
- SecureXL supportes now Async SecureXL with Falcon cards
- That's new in acceleration high level architecture (SecureXL on Acceleration Card): Streaming over SecureXL, Lite Parsers, Scalable SecureXL, Acceleration stickiness

R80.30 and above:
- In R80.30+, you can also allocate a core for management traffic if you have 8 or more cores licensed, but this is not the default.
- Active streaming for https with full SNI support.

More read here R80.x Security Gateway Architecture (Logical Packet Flow)

or here: R80.x Architecture and Performance Tuning - Link Collection

I would use R80.30 with QoS. I think you'll get the better SecureXL acceleration features with R80.20 and above. In R80.10 and above the QoS acceleration is enabled by default.

R80.30 is supported for the following appliances 23900, 23800, 23500, 21800, 21700, 21600, 21400, 15600, 15400, 13800, 13500, 12600, 12400, 12200, 6800, 6500, 5900, 5800, 5600, 5400, 5200, 5100, 4800, 4600, 4400, 4200, 3200, 3100, 2200.

The memory on 4200 appliance is more problematic with many enabled blades and with two cores you have few tuning options.

[Don_Paterson]

Heiko,

In your packet flow thread and diagram there is nothing to show the QXL "path" or detail its architecture or the machanics of it, is there?

This sentence might benefit from a longer explanation. It doesn't seem to clearly define what QXL does or at least any detail of how it does it.

"QXL - Technology name for combination of SecureXL and QoS (R77.10 and above).This has no direct association with PXL. It is used exclusively for QoS. But also here it is possible to use the QoS path in combination with PSL."

When you say "I think you'll get the better SecureXL acceleration features with R80.20 and above.", are you generalising or are you considering the two core system, the weaker 4200 dual-core appliance for example?

Could it be possible that a dual core, in some cases, could be better off with R80.10 and the older SXL architecture when compared to the R80.20 + user based SXL?

Don

[PhoneBoy]

Just a small modification: SecureXL still very much operates in kernel space.
The decision whether or not to accelerate is handled a bit differently.
Some details in this thread: https://community.checkpoint.com/t5/Access-Control-Products/R80-20-SecureXL-User-Space/m-p/53805#M21...

[Timothy_Hall]

The inner workings for R80.20+ SecureXL are still in the process of being revealed since I haven't got an answer to my questions in this thread yet:

https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/R80-30-Packet-Processing-Achieving-...

Because the 4200 is a 2-core box with limited resources, I doubt the version and subsequent changes in R80.20+ will matter a great deal in your case.  The minimum memory requirement of 4GB RAM did not change between R80.10 and R80.20, and the 4200 has 4GB of RAM so you should be OK there.

The default split of SND/IRQ vs. Firewall workers on a 2-core box is 2/2, and even prior to R80.20 I recommended baselining your CPU load and performance with that default 2/2 split, disabling CoreXL via cpconfig to produce a 1/1 split, then checking CPU load and performance again for a 2-core box.  Depending on how much of your traffic is accelerated and the amount of operations occurring in process/user space, moving to a 1/1 split by disabling CoreXL may hurt or it may help.  Even if you have run this test before, I'd recommend doing it again due to the changes in R80.20+ SecureXL as you may get different results.

There were some changes in the QoS-related paths in R80.20 SecureXL (from QXL to QoS inbound & QoS outbound) but I don't think that will matter much.  You should only be using the QoS blade if you need bandwidth guarantees, WFQ, DiffServ or LLQ; if you are just doing limits I'd strongly recommend utilizing the APCL/URLF Limit actions and disabling the QoS blade.

[Don_Paterson]

Thanks Tim, thanks Heiko,

That pretty much confirms what I had thought. It's not optimal with two cores (and 4GB) but with a bit of monitoring and analysis there may be options for tuning. Also the use of QoS should be reviewed to determine if it is required.

Unfortunately its not easy to jump between versions (R80.10, .20 and .30) just to see/test how each one behaves in the customer solution. In this case I say that because of the significant changes between each of the three latest versions and how it could have different affects on the performance.

So ideally CP can share what they think is optimal for a two core solution considering the three versions and the differences.

That is relevant because the 4200 (and many other two core solutions) are out there with 3 years of life left in them (at least) and customers cannot always refresh the hardware quickly and easily, in the real world.

For reference, here are some of the notes I made:

SecureXL would indeed need to be turned off in cpconfig if QoS was enabled. In R77 QoS is also not compatible with CoreXL and that would explain that being turned off permanently too.

If QoS is not needed the. CoreXL and SecureXL may assist with accelerating the traffic throughput on the 4200.

Did you see the lifecycle page for that appliance? It's an older appliance now, relatively speaking.

It has three years of life left but only one where software releases are supported for it.

https://www.checkpoint.com/support-services/support-life-cycle-policy/

The CoreXL for dual core is not ideal but at least uses both cores and SecureXL can work with it two.

The default is to have two kernel instances but the two CPU cores also support the SND software instance.

That does mean more power across the interfaces for dealing with traffic coming in for rulebase matching or acceleration.

Maybe it can take R80.20 and that could help but it's a big difference for SecureXL, which has the fast path in the software from R80.20 (and not in layer 2). But maybe that would  mean R80.10 would be better to offer CoreXL with QoS.

I don't have experience with that set up and could lab test it (in a VM).

Otherwise a hardware refresh would of course allow for R80.20 or R80.30 to shine.

https://sc1.checkpoint.com/documents/R80.10/WebAdminGuides/EN/CP_R80.10_PerformanceTuning_AdminGuide...

"The SND is responsible for:

Processing incoming traffic from the network interfaces

Securely accelerating authorized packets (if Performance Pack is running)

Distributing non-accelerated packets among kernel instances."

"... However, it is necessary for the SND and an instance to share a core when using a machine with exactly two cores."

[Timothy_Hall]

> So ideally CP can share what they think is optimal for a two core solution considering the three versions and the differences.

> That is relevant because the 4200 (and many other two core solutions) are out there with 3 years of life left in them (at least) and customers cannot always refresh the hardware quickly and easily, in the real world.

It is not really possible to create a general recommendation like this for a 2-core firewall.  There are simply too many variables including which blades are enabled, how you have them configured (particularly IPS and the rest of Threat Prevention), and purpose of the firewall (outbound Internet access, inbound DMZ connections, and/or Site-to-site/Remote Access VPN endpoint to name just a few).  So that is where the recommendation to try a 1/1 split with CoreXL disabled on a 2-core firewall came from in my book. 

If you'd like to provide the outputs from the "Super Seven" commands on your current R80.10 firewall, I can take an educated guess at trying to predict if R80.20 will substantially improve performance.

Not including embedded Gaia boxes like the 1400 series, Check Point no longer sells firewall appliances that have just 2 cores so the "rock and a hard place" that 2-core firewalls find themselves in is slowly going away.

[HeikoAnkenbrand]

I agree here with @Timothy_Hall 

I would test both 1/1 and 2/2.  Depending on which and how many blades you have turned on, you may get different performance  results.