- CheckMates
- :
- Products
- :
- General Topics
- :
- R82 - ElasticXL
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
R82 - ElasticXL
ElasticXL is a new cluster technology that enables simplified operation with a single management object with automatic configuration and software synchronisation between all cluster members.
ElasticXL is expected to be delivered with R82 or later versions. ElasticXL is based on similar technology to Maestro, but without MHOs. It is based on Check Point's SP versions for a scalable platform that allows you to increase the performance of the security gateways almost linearly.
This is achieved naturally by load balancing between individual gateways that operate in a cluster as a single entity.
This new cluster technology will some of the Maestro featchers such as SMO (Singel Management Object) use.
A ElasticX gateway will work as a pivot member and act simelar as a MHO's in a Maestro environment and simultaneously takes on the role of SMO.
The pivot member takes over the network connection and controls the ARP requests in the network. The pivot member distributes the connections via a distribution matrix to the connected member in the security group similar to a Maestro environment.
Same as the Maestro environments, the familiar SP commands will also be available here and there will also be a gclish. The management traffic will be handled by the SMO (pivot member).
Installation process:
1) The gateways are installed as usual via the First Configuration Wizard. ElasticXL" is now selected instead of "ClusterXL" on the product page.
2) After that, the SIC to the first gateway (pivot member) will be established single gateway (not as a cluster object). Afterwards, the policy can be installed.
3) In the following step the next gateways can be added by (host name, serial number).
Here you can find detailed installation information about ElasticXL:
Install ElasticXL Cluster
>>> Please note that this information is not yet an official statement from Check Point and may change at any time. <<<
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Don't be so sure 😉
I maintained a DEC firewall in 1995...don't remember which one it was.
Quite a big gateway to protect an ISDN line for Internet.
I also did a couple of installs of TIS Gauntlet before I got exposed to Check Point FireWall-1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maybe embarrassing to admit, but the only thing I remember as a kid back in eastern Europe was commodore 64 😂😂😂
I still recall very first computer we ever owned, had whooping 64K of ram and 128 MBs hdd 🙂
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
... Even before that there was a DECnet firewall but we won't go there because I guess there is nobody here who goes that far back 😉
Don't bet on it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello -- I'm digging into this more with imminent release of R82_EA.
Any ideas on the hardware requirements for the Pivot member? I suggest it won't need to be same specs as the adjacent gateways that will end up handing the connections and persistent sessions.
Should we assume that day one that all nodes of an ElasticXL cluster will need to be same model, but this may change for future? I'm thinking through the sales conversations about "a new clustering technology that allows you -- Mr Customer -- to leverage investment in gateways day one. However, you'll now need to buy THREE instead of TWO gateways ... and they'll need to be same model".
This could get expensive.
Thanks --
ref
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Same model is probably a safe assumption for ElasticXL in R82, at least initially.
One gateway will be the SMO (gets policy from management) and distribute to other gateways like Maestro does today.
I don’t believe a gateway will be a “pivot member” similar to how ClusterXL Active/Active clustering works in unicast mode today, though there is a correction layer that ensures the same gateway gets all the traffic for a connection (again, similar to Maestro).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If we can do a mixed cluster, that would be a huge game changer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, you cannot mix different appliances, not even with ElasticXL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Will Quantum Spark Appliances be supported?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I dont believe those appliances will be supported.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This feature will require R82 and Quantum Spark appliances will not receive this release until sometime after it is released for regular Quantum gateways.
Whether it will support ElasticXL for Quantum Spark is unknown at this time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK - thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing.
CCIE #58769 | PCNSE | CCSE | CISSP | PMP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, I'm interesting in what clustering technology is ElasticXL (Active/Active or Active/Standby)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe its load sharing principle, as its based on Maestro.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, not like Maestro, as it has neither up/down links, nor a load balancer.
ElasticXL is an iteration of a pivot-based load-sharing, pretty similar to the Unicast Load Sharing mode of the classic ClusterXL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Right. I meant more like Maestro as far as load sharing.
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Maestro uses actual hardware (the orchestrator) for Load Balancing; ElasticXL does not.
I would, therefore, expect the performance to be similar to ClusterXL Load Sharing.
However, you get all the other benefits of Maestro (SMO, better API support, etc).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, I have some misunderstanding regarding ElasticXL as a new clustering technology in R82.
Is this clustering technology intended as a replacement for ClusterXL in the future? If answer is yes, is it applicable on all ClusterXL modes (High Availability, Load Sharing Multicast, Load Sharing Unicast, Active-Active),
For example, we have a many sites with two gateways configured as ClusterXL High Availability (one gateway is active, second one is standby). What about ElasticXl in this design as you know in ElasticXL all gateways are active. Does it have some limitations if we compare ElasticXL and ClusterXL High Availability. Is it better to use ElasticXL regarding ClusterXL High Availability?
Best regards
Milan Babic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What is new in ElasticXL, is provisioning and cluster management, with Maestro-like SMO.
Under the hood, however, ElasticXL is using the unicast Load sharing (pivot mode) you already know from ClusterXL. EXL support up to three members per site, and can be implemented in a dual-site setup. In this case, with just a single member per site deployed, you will have your classic HA pair.
ElasticXL is not intended to replace the classic ClusterXL at this point, but it has some advantages when it comes to deployment and operations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are certain clustering situations which ElasticXL will probably never be able to handle. For example, I don't see any way there could ever be a "full HA" (both management HA and firewall HA on a single pair of devices; popular for small deployments) cluster with ElasticXL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yeah, I doubt ElasticXL will ever support this use case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think last time I had seen someone use full HA was 6-7 years ago...I have to say, that setup is great when it works, but once it breaks, o boy : - )
Andy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, I understand but still loking for some answers.
Can I find somewhere matrix of compatibility between ClusterXL HA and ElasticXL? What is supported on one clustering technology and not supported on other. For example (NAT, IPsec VPN with 3rd party gateways, Remote Access VPN), is it all supported on ElasticXL? There is no a lot of documentation regarding ElasticXL.
Imagine that you want to configure a new cluster of two gateways. What would you choose ClusterXL or ElasticXL?
Best regards,
Milan Babic
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I keep consulting Copilot AI lately for these things and I think this answer is really good. See if it helps.
Andy
Pozdrav : - )
********************
Certainly! Here are the key differences between ClusterXL and ElasticXL:
ClusterXL:
-
Architecture:
- Traditional clustering technology.
- Supports up to 5 Cluster Members.
- Handles both traffic and state synchronization.
- Interfaces are treated as Critical Devices.
- Supports Load Sharing and High Availability modes.
-
Configuration:
- Requires manual configuration for each cluster member.
- Uses Cluster Control Protocol (CCP) for synchronization.
-
Management:
- Each cluster member is managed individually.
- Requires manual intervention for adding or removing members.
-
Performance:
- Performance can degrade with more than 4 Cluster Members in Load Sharing mode due to Delta Sync traffic.
ElasticXL:
-
Architecture:
- New clustering technology with simplified operations.
- Supports up to 3 ElasticXL Cluster Members per site and 6 in total.
- Single Management Object (SMO) for the entire cluster.
- Automatic synchronization of configuration and software packages from the SMO.
-
Configuration:
- Only the first Security Appliance (SMO) needs to be configured manually.
- Additional members automatically clone the configuration and software from the SMO.
- Supports automatic configuration of the internal synchronization network.
-
Management:
- Managed through a Global Gaia Portal and Global Gaia Clish.
- Allows adding and removing members on-the-fly.
- Supports Gaia RESTful API for management.
-
Performance:
- Efficient scale architecture with better performance and administrator experience.
- Supports only the "General" Distribution Mode for traffic assignment.
-
Additional Features:
- Dual Site support.
- Automatic assignment of unicast MAC Addresses to data interfaces.
- Hidden bond interfaces for management and synchronization to prevent changes.
Summary Table:
Feature | ClusterXL | ElasticXL |
---|---|---|
Architecture | Traditional clustering | New clustering technology |
Max Members | Up to 5 | Up to 6 (3 per site) |
Configuration | Manual for each member | Automatic cloning from SMO |
Management | Individual management | Single Management Object (SMO) |
Performance | Degrades with >4 members in Load Sharing | Efficient scale architecture |
Synchronization | Uses CCP | Automatic internal sync network |
Additional Features | - | Dual Site support, RESTful API |
For more detailed information, you can refer to the respective administration guides for ClusterXL and ElasticXL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ElasticXL limitations are actually listed among R82 limitations: https://support.checkpoint.com/results/sk/sk181128
All features you mentioned are supported with ElasticXL. Once again, from a clustering perspective, ElasticXL is a Unicast LS cluster. The differences are mostly about installation, provisioning, and management of a cluster/ SMO object.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks a lot for explanation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Review the Known Limitations for R82, specifically the following two sections: ElasticXL and Maestro/Scalable Platforms (which ElasticXL is an implementation of).
The only place where ClusterXL has to be used, to the best of my knowledge, is a "Full HA" configuration (management + gateway on both cluster members).
For an HA-only cluster (no load sharing) you have to set up ElasticXL as "Dual Site" where each site has a single member.
Otherwise, I can't think of a reason one should choose ClusterXL over ElasticXL (beyond familiarity with ClusterXL).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are a few more limitations compared to vanilla ClusterXL:
- Central licensing isn't possible with ElasticXL, since the management sees all members as one "device"
- Branded servers can't fetch their own licenses with ElasticXL (not sure why this is)
- ElasticXL doesn't support open servers
- ElasticXL only supports KPPAK, so no HyperFlow
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ElasticXL should work with Open Servers similar to how you can make it work with VMs.
I believe both will be supported in the near future.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
KSFW is the limitation for Hyperflow as I understood not KPPAK so shouldn't be a problem.
Refer: sk167052, sk178070
R82 - ElasticXL
ElasticXL is a new cluster technology that enables simplified operation with a single management object with automatic configuration and software synchronisation between all cluster members.
ElasticXL is expected to be delivered with R82 or later versions. ElasticXL is based on similar technology to Maestro, but without MHOs. It is based on Check Point's SP versions for a scalable platform that allows you to increase the performance of the security gateways almost linearly.
This is achieved naturally by load balancing between individual gateways that operate in a cluster as a single entity.
This new cluster technology will some of the Maestro featchers such as SMO (Singel Management Object) use.
A ElasticX gateway will work as a pivot member and act simelar as a MHO's in a Maestro environment and simultaneously takes on the role of SMO.
The pivot member takes over the network connection and controls the ARP requests in the network. The pivot member distributes the connections via a distribution matrix to the connected member in the security group similar to a Maestro environment.
Same as the Maestro environments, the familiar SP commands will also be available h