Best-Practice Routing and LACP Design Between Check Point ElasticXL and Palo Alto Active/Active Fire

[yeruel]

Hello Check Point Community,

We are designing a high-availability, high-throughput connection between a Check Point Quantum 29200 ElasticXL Security Group and a Palo Alto firewall cluster operating in Active/Active mode.

The proposed topology is as follows:

• Two Check Point Quantum 29200 appliances operating as an ElasticXL Security Group with SMO.
• Two Palo Alto firewalls operating in Active/Active HA mode.
• Four physical 10-Gbps interconnections in a full-mesh topology:
  • Check Point Member 1 to Palo Alto Firewall 1
  • Check Point Member 1 to Palo Alto Firewall 2
  • Check Point Member 2 to Palo Alto Firewall 1
  • Check Point Member 2 to Palo Alto Firewall 2
• Each Palo Alto firewall uses an Aggregate Ethernet interface, and each Check Point member uses a Bond interface.

We would appreciate guidance on the following points:

1. What is the recommended Layer 3 routing design between the Check Point ElasticXL Security Group and the Palo Alto Active/Active cluster?
2. Is dynamic routing recommended for this design? If yes, which protocol is preferred—eBGP or OSPF—and what is the recommended peering model?
3. Should routing adjacencies be established per physical member/link, or should the design use a shared virtual IP/interface approach?
4. For the four 10-Gbps links, is LACP recommended between the Check Point Bond interfaces and Palo Alto Aggregate Ethernet interfaces?
5. If LACP is used, can a Check Point ElasticXL Security Group safely form an LACP bundle with an Active/Active Palo Alto pair across both firewall members, or should each Check Point member connect only to a corresponding Palo Alto member using separate Layer 3 routed links?
6. What design is recommended to prevent asymmetric routing and session synchronization issues, considering that both firewall platforms are operating in active-active/load-sharing modes?
7. Are there any Check Point ElasticXL limitations or best-practice documents relevant to this cross-connected topology?
8. What if I used for static routing between both connection while LACP keeping 

A conceptual topology diagram is attached. We would appreciate any validated deployment experience, configuration examples, and official best-practice references.

[emmap]

You need to put a switch between them, EXL won't work without a switching layer. As far as routing is concerned, design it as if the EXL cluster is a single layer 3 node on the network - the config you put on there is sync'd between members and each interface only has 1 IP regardless of how many members are in the cluster. The LACP bonds created are unique per member though they'll sync that config too, so your switch has to present one bond per member. 

[israelfds95]

hi @yeruel 

This is a very interesting design. ElasticXL is still a relatively new technology, and honestly, I have never deployed ElasticXL in production, especially in a topology like this. However, based on my experience with Check Point, the documentation, and some research, I'll try to help. I also think this would be a great case to document and share back with the community once implemented.

My first concern is the proposed topology. I would not recommend connecting the ElasticXL Security Group (or any Check Point firewall) directly to the Palo Alto Active/Active pair using cross-connected LACP as shown. Firewalls are Layer 3 devices, not switches, and should not be expected to provide MC-LAG functionality or advanced switching functionalities. I would recommend that you introduce a redundant switch pair between both platforms (CheckPoint and Palo Alto) and perform Layer 3 routing between the firewalls.

My thoughts on your questions:

• Routing design: Layer 3 transit networks through a redundant switch pair.
• Dynamic routing: Yes, I would recommend it.
• eBGP or OSPF? I would lean toward eBGP because it provides better routing policy and control between two different firewall platforms.
• Peering model: I would configure routing using the logical ElasticXL interfaces rather than treating each physical member as an independent router.
• LACP: Yes, but only with a single logical LACP peer. Based on the proposed topology, I would not build a single LACP bundle across both Palo Alto firewalls.
• Static routing: It can work, but it does not solve the Layer 2/LACP design concern.
• Asymmetric routing: Start with a preferred path and validate failover first. Consider ECMP/load sharing only after the design is stable.

Finally, because this is a cross-vendor architecture involving a relatively new platform like ElasticXL, my recommendation would be to engage your Check Point Account Manager and request assistance from Professional Services. They can validate the design, confirm what is officially supported, and help with the implementation if needed. I would recommend doing the same with the Palo Alto team.

Good luck, and please come back and share the final design. I think many people in the community would benefit from seeing a real-world ElasticXL deployment like this.

Good links to review: 

R82 ScalablePlatforms admin guide > ElasticXL
https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_ScalablePlatforms_AdminGuide/Conte...

ElasticXL supported combinations of hardware platforms in R82 and higher
https://support.checkpoint.com/results/sk/sk183513

R82 Gaia Advanced Routing Administration Guide
https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_Gaia_Advanced_Routing_AdminGuide/C...

[Bob_Zimmerman]

For question 5, ElasticXL members definitely can't negotiate as a single LACP endpoint. I don't think Palo Alto supports that either.

The links from ElasticXL to Palo Alto would both have the same IP on the ElasticXL side. Pretty sure this won't work unless you have switches in the middle handling the pathing for the ElasticXL side.