Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
JMarkus
Explorer

Elastic XL and sync interface

Hello Checkmates,

as far as I have seen the sync interface to be used when you setup a elastic XL cluster is only the one called "sync".

What if I dont want to use this one ? A simple reason for this: I need a fiber interface and not a copper.

According to some lab I did, it does not work. You can setup your first member SMO, change the bond 1024 with the sync interface you want to use. But then the second member freshly imaged, without first time wizard done, will never be visible (the interface I want to use for sync are connected together of course).

Ok, you can first setup your cluster with the dedicated "sync" interface, and change it after and it is working. But this is a workaround, not a solution. What is you want to add some additional members later ? Or do a RMA ? 

Regards

 

0 Kudos
4 Replies
ZaferGr
Participant
Participant

Hello,

 

It was easy to perform the operation you mentioned in Maestro or a regular cluster.


For ElasticXL, it might make more sense to set up bonding.
The sync IP address is defined by default. “ElasticXL Cluster automatically configures the IP address of the sync network to 192.0.2.0/24.”

I also recommend reviewing this support article:
https://support.checkpoint.com/results/sk/sk183513

0 Kudos
JMarkus
Explorer

Your sk does not help. I am talking of same 9xxx appliances in R82.10.

Sync interface is by default a bond, the bond group 1024 where it puts the physical interface named "sync" (renamed eth1-Sync).

Once you have setup your cluster with the sync interface, you can modify the bond 1024 and put what you want, change for a fiber interface, change the mode from HA to LACP. It works, I tested.

My issue is that I want a new member (new or RMA) uses directly my sync setup (not the interface named sync).

The R82.10 Scalable Platforms Administration Guide says this:

"The "Sync" ports of all ElasticXL Cluster Members in the same ElasticXL Cluster must connect to the same Layer 2 broadcast domain (a dedicated Layer 2 switch, or a dedicated VLAN)."

Do we really have this limitation that we can only use the sync port ? What if I dont have copper ports on my switches ? 

Also with ElasticXL you have the "site" notion, it means distant sites. When you have distant sites it is connected by fibers, "always".

 

 

 

 

0 Kudos
ZaferGr
Participant
Participant

Hello Markus

I couldn't find an official statement addressing this request. Perhaps there are some gaps in this area because it's a new technology.

If this request is to be implemented, it will likely be resolved with a patch file.

 

Let's keep each other updated

0 Kudos
Bob_Zimmerman
MVP Gold
MVP Gold

To cleanly provision new members, you must use the interface named Sync or Sync1 (on boxes like the 19000 line which have more than one). The easiest way to ensure this is to have a mostly-copper switch used just for provisioning with the copper ports to the members of a given cluster on the same VLAN as that cluster's real sync interfaces. Connect the interface named Sync to that switch, then when members clone the Lightshot from the pivot and revert to it, the real members of bond 1024 will be added to it and set up. Somewhat inconvenient, but you need copper ports for the LOM anyway, so this is just a few more. You will almost certainly need console access to the new member to deal with sk184626, (the default Lightshot LV doesn't expand quickly enough, causing joins to fail) so it's not as zero-touch as originally advertised.

If this definitely isn't an option, you won't be able to provision new members seamlessly, but you can use the process for open servers in sk183513 to manually manipulate the interface naming to make any interface 'eth1-Sync' for the purposes of joining the cluster. It takes some manual futzing, but it's not especially complex, particularly since you probably need the console access for the Lightshot LV thing anyway.

You said "the interface I want to use for sync are connected together of course". Do you mean via a direct fiber connection with no switch between them? If so, that's a bad idea. The supported topologies for the synchronization network all have a switch in them.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events