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.