3900 Gateways: ElasticXL

[KS50]

Does Checkpoint happen to have an ETA when ElasticXL will be supported on the 3900 series of appliances?

[CaseyB]

I asked our SE about that; I was told it will be supported when R82.10 goes to GA for all devices.

This is in my Smart Console, so I'd say "soon".

[KS50]

I've heard "Soon" for a few months now too.

Really don't want to configure new gateways as ClusterXL and then have to rebuild / reconfigure them as ElasticXL (Even if/when Checkpoint releases a conversion tool), as the move to ElasticXL will mean new Port Channels (Which wouldn't exist in a ClusterXL deployment).

Also hoping that the Sync interface can be chosen from any of the interfaces and doesn't need to be a specific one, not knowing how this can/will be selectable during deployment makes me wonder if I gamble correctly and choose a port that can be used as the Sync interface for ElasticXL.

[Bob_Zimmerman]

Just make everything (including sync) bonds from the start. Bonds can have a single member interface and don't need to talk any particular protocol (so no special action is needed on the attached devices). They separate your physical interface names from the logical interface names. It makes replacing the hardware later (with different hardware, ElasticXL, or whatever) so much easier.

[CaseyB]

I am in the same boat, waiting to build ElasticXL before deploying. *thumbs twiddling*

[emmap]

What do you mean it will 'need new port channels'? That doesn't need to be the case.

[KS50]

Not worth the time, effort, and overhead to get changes approved to touch the Data Center core switches (Managed by the networking team) to create and then adjust EtherChannels that are part of a vPC during a limited change season. 

[Bob_Zimmerman]

That's the cool thing about bond methods other than 802.3ad: for a single interface, the other side doesn't have to do anything different at all.

add bonding group 5
set bonding group 5 mode active-backup
add bonding group 5 interface eth5

Now you use bond5 on the firewall instead of eth5, and you can change which physical interface backs bond5 later. So if you find ElasticXL wants to use eth5 for sync, you just do something like this:

add bonding group 5 interface eth8
delete bonding group 5 interface eth5

and move the cable on the firewall. Now eth5 is free to be the sync interface. Subinterfaces on the firewall will all reference the bond instead of eth5, so you don't need to make any changes to them. Cluster VIPs also reference the bond, so again, no changes. If you move to different hardware later which doesn't have an eth5 or an eth8, you just change the config to reference eth1-07 or enx78e7d1ea46da or whatever the new name is.

From the outside, it all looks like you're using the interfaces directly. The switch team doesn't need to do anything different at all until you want to add more than one link.

[KS50]

Totally, for sure (for the Sync interface, I get it, makes sense)

However, for the data connections, 802.3AD is necessary.

[Bob_Zimmerman]

But that wouldn't necessarily involve any new bonds. If you want to use 802.3ad with ElasticXL, you presumably also want to use it with ClusterXL. The ElasticXL magg1 and Sync bonds use non-802.3ad modes by default. As a result, as long as you use bonds for all your other interfaces, you shouldn't need the switch side to do anything different if you change the cluster to ElasticXL later.

[emmap]

Yea, in both CXL and EXL the bonds are local to the gateway. There doesn't need to be any difference at the network side of things.

[Alex-]

A big caveat with 802.3ad is how the network side configures their settings or the system/OS it is. On the Check Point side, there's not much advanced/extended configuration readily available. But I've seen implementations where an OS upgrade of gateways would cause a recomputation of the MAC address of the bond interface. TAC would says it's the network, the network would say it's the firewall. With 802.3AD, I always check L2 addresses after upgrade before the failover to the upgraded unit.

[CarlitosDiaz]

Hi! Any update on this?

[_Val_]

According to sk183199, at this moment, ElasticXL is not yet supported with the 3900 series. We are working to add this support, but it is not yet there. 

[CaseyB · Accepted solution]

Looks like ElasticXL has been approved in GA!

[CarlitosDiaz]

I can confirm that it's available and working perfect. 

[Bob_Zimmerman]

Just got confirmation from my company's support reps that the 3920 and 3950 also support ElasticXL with R82.10 take 464. Neither has an interface named Sync. Apparently the 3920 uses eth9 (SFP), and the 3950 uses eth11 (the NBASE-T interface above the interface named Mgmt).

You can always move those interfaces out of the Sync and magg1 bonds later to use them for through-traffic.

[CaseyB]

Do you know how to get ElasticXL working on a 3920 if you don't have SFPs for eth9?

[Bob_Zimmerman]

Good question! Not sure. I don't have one yet to try.

I think on the first member, you would set it up with no sync link, then add the interface you want to use to the bond, and remove the SFP interface. Subsequent members should copy that down over the management link.

[KS50]

According to TAC. No.  (At least on a 3950, assuming the same goes for a 3920), you still need to build the ElasticXL cluster before you can make any changes to the Sync Port.

Question to TAC:
Is there any way to configure FW2 (That has been defaulted) to use eth2 as the Sync interface without first needing to have it cabled directly to eth11, discovered by the SMO, configured, and then reconfigured to use the new Sync interface (eth2)?

TAC Response:
"The issue with the 3950 and ElasticXL sync interface is being addressed by R&D and will be implemented in R82.20. The workaround I have provided is the only way to change the sync interface."

That workaround is as follows:

This only changes the port that Sync can use:

-add all SGMs to the security group
-gclish
-add bonding group 1024 interface <interface_name_customer_wants_to_use_as_sync>
-delete bonding group 1024 interface eth1-Sync <enter>
-save config
-then reboot every SGM, start with the SMO, then reboot every other SGM, until every SGM is rebooted there will be issues with sync

This allows you to use eth11 again:

In order to change the name from eth1-Sync back to eth11 please follow these steps:

-cp /etc/udev/rules.d/00-BT-92-00.rules /etc/udev/rules.d/00-BT-92-00.rules_ORIG
-vi /etc/udev/rules.d/00-BT-92-00.rules
-change the line that end with "NAME="eth1-Sync" to be "eth11"
-save and exit vi
-reboot the SGM, this will need to be done on each SGM

[CaseyB]

I ended up finding some SFPs and ElasticXL is working at intended with eth9 as the Sync interface.