ElasticXL on 9100 and 9700 Appliances

[Yasushi_Kono1]

Hi fellow Check Point Experts,

I have got a customer who is planning to implement R82 Check Point ElasticXL.

They are having deployed the aforementioned appliances and wanted to interconnect two sites. The dedicated Sync port is not applicable for them since it is copper, and they want to configure SFP instead.

Is there a file like /etc/sp_core/conf/vm_mapping.csv for VMware to re-designate an interface for Sync? Can you specify a Bond interface (e.g. Bond1) to re-design it as Sync?

Thanks a lot for your assistance!

Kind regards,

Yasushi

[PhoneBoy]

Paging @ShaiF 

[Bob_Zimmerman · Accepted solution]

When you set up ElasticXL, the interface named Sync is renamed to eth1-Sync, a new bond named Sync is created, and the interface named eth1-Sync is added to this bond. All you need to do is add the fiber interface(s) to the bond and remove the copper interface from the bond. It's bonding group 1024:

[Expert@DallasticXL-s01-01:0]# gclish -c "show configuration" | grep 1024   
add bonding group 1024 
set bonding group 1024 mode active-backup 
set bonding group 1024 primary eth1-Sync 
set bonding group 1024 xmit-hash-policy layer2 
add bonding group 1024 interface eth1-Sync 
add bonding group 1024 
set bonding group 1024 mode active-backup 
set bonding group 1024 primary eth1-Sync 
set bonding group 1024 xmit-hash-policy layer2 
add bonding group 1024 interface eth1-Sync 

[APopisteru]

This might become interesting if, after changing the SMO as describe above, one will try to add a new SGM without tinkering with the factory configuration, because exl_detectiond.py is looking for the interface named Sync to start in client mode, with the communication process bound to the sync-ip (the (in)famous line if __machine_info.sync_ifn != 'Sync' and not __machine_info.is_vmware and not __machine_info.is_kvm:), so one might need to change the interface naming in /etc/udev/rules.d/00-ME*.rules on the SGM to be joined to EXL.

Personally I will build the EXL cluster in a staging area using the default factory configuration and copper Sync interfaces and allocate SFP slot(s) as described above after having the provisional configuration fully functional.

[Yasushi_Kono1]

Hi Bob,
thanks a lot for your reply! Great job!!

[Yasushi_Kono1]

One question arose: Is it on purpose to use the same sequence of commands twice? I understand that the bonding group has an ID of 1024 and its name is eth1-Sync. However, the sequenced does not reflect the process of adding other interfaces into that bonding group, is it?

Thanks again for your reply!

[Yasushi_Kono1]

Could you use the following syntax for adding additional interfaces into the existing bonding group?

add bonding group 1024

set bonding group 1024 mode active-backup

set bonding group 1024 interface eth11

set bonding group 1024 interface eth12

But, if the name of the Bond Interface is expected to be Sync, can you specify that name for the bond interface?

[Bob_Zimmerman · Accepted solution]

Neither the 9100 nor the 9700 has interfaces named eth11 or eth12. The onboard SFP+ slots on the 9700 seem to be eth1 through eth4, so the commands in gclish would be:

add bonding group 1024 interface eth1
set bonding group 1024 primary eth1
add bonding group 1024 interface eth3
delete bonding group 1024 interface eth1-Sync
save config

Edit: I forgot to set the primary interface before trying to remove eth1-Sync.

[Bob_Zimmerman]

gclish runs commands on all members of a cloning group. That's one of the technologies underpinning maestro and ElasticXL. My cluster has two members, so you see the output twice.