R82 - ElasticXL 3920 Appliance - Member Join Issue

[reybanger]

Hello Checkmates,

Looking for help with ElasticXL Member Addition.

Did anyone face an issue where a member would not want to join the ElasticXL Cluster?

I have dedicated VLAN for Internet 
I have dedicated VLAN for management

3920 came with R82.10, on which I have installed JHF Take 22 and then R82.10 Take 464, to enable ElasticXL on 3920. 
I did the same on my secondary - booted, cancelled first time wizard, installed JHF Take 22, installed R82.10 Take 464 (which is super confusing btw.) 

I have directly connected appliances on eth9 SFP port (I read in other topic, that Sync on 3920 uses that...) 

tcpdumping on sync, as eth9 is no longer visible in the interfaces list... 

gateway-s01-01 member tcp dump on sync:
tcpdump -i Sync | grep 192.0.2.255
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on Sync, link-type EN10MB (Ethernet), capture size 262144 bytes
13:46:49.288944 IP 1_01.omnivision > 192.0.2.255.omnivision: UDP, length 1035
13:46:59.295933 IP 1_01.omnivision > 192.0.2.255.omnivision: UDP, length 1035

gateway I want to join to cluster:
07:48:17.475000 IP (tos 0x0, ttl 64, id 38173, offset 0, flags [DF], proto UDP (17), length 1014)
192.0.2.254.omnivision > 192.0.2.255.omnivision: [udp sum ok] UDP, length 986
07:48:27.475341 IP (tos 0x0, ttl 64, id 38723, offset 0, flags [DF], proto UDP (17), length 1014)
192.0.2.254.omnivision > 192.0.2.255.omnivision: [udp sum ok] UDP, length 986
07:48:37.475736 IP (tos 0x0, ttl 64, id 39023, offset 0, flags [DF], proto UDP (17), length 1014)
192.0.2.254.omnivision > 192.0.2.255.omnivision: [udp sum ok] UDP, length 986

So looks like both gateway wants to send broadcast... but they do not see each other. 

Interfaces on member A:
15: eth1-Sync: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master Sync state UP qlen 2048
link/ether 00:1c:7f:cb:77:d8 brd ff:ff:ff:ff:ff:ff
25: Sync: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:1c:7f:cb:77:d8 brd ff:ff:ff:ff:ff:ff
inet 192.0.2.1/24 brd 192.0.2.255 scope global Sync
valid_lft forever preferred_lft forever

Member B:
15: eth9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 2048
link/ether 00:1c:7f:cb:77:56 brd ff:ff:ff:ff:ff:ff
inet 192.0.2.254/24 brd 192.0.2.255 scope global eth9
valid_lft forever preferred_lft forever

Any advice would be appreciated 🙂

Thank you in advance

Security Gateways 

[CaseyB]

These are the steps I took to get ElasticXL working on 3920 appliances.

• Clean install of R82.10 Take 464 via ISOmorphic Tool (both appliances).
• Verify Member 2 boots to the first-time setup wizard and power off.
• Build the ElasticXL gateway in Smart Console, make sure the hardware is set to ElasticXL:
  • elastic-xl-sms.png
• Configure everything on Member 1, establish SIC, get topology, push policy.
  • In my build the only interfaces I configured were eth1(internal), and eth5(wan), as I used the default for MGMT and Sync will configure itself.
• Cable Member 1 & 2 together using eth9 (SFP port) - it has to be eth9 - don't forget you might need to flip the fiber pairs if you do not get a link later in the configuration.
• Power on Member 2.
• Give it like 5 minutes to boot, check "Cluster Management" via Gaia GUI on Member 1.
• Should see a new pending gateway.
• Build cluster.
• Profit.

[reybanger]

Will try Clean Install with ISOMorphic and try again. 
Seems a little bit weird that there is no connectivity on the SYNC port between the two in my setup, maybe the upgrades indeed broke it. 

Thank you! 

[reybanger · Accepted solution]

It seems I had an issue with my SFPs.

I was using copper modules and noticed many errors on eth9 on the gateway I wanted to join to the cluster. Since I had already replaced the cable during earlier tshooting, I wasn’t expecting a Layer 1 issue, but it seems the gateway simply didn’t like the SFP plug itself. (Lights were blinking just fine on the SFP ports). 

After switching from copper to fiber SFPs, I was able to see the gateway in "Pending gateways," even with the 2-step upgrade. It also appears that cancelling the wizard and configuring the external interface via the CLI to download updates does not break the process. Just required one additional reboot after installing Take464, that makes 3 reboots in total. 

Cheers!

[freshwater84]

Hi Casey,

Thanks for that good information, I would have run into a big problem otherwise.

The only thing: We have Smart1-Cloud (MaaS) as a management. The Problem is: To get an Authentication Token, we have to build the object in Smart1-Cloud Web Console - but there is no ClusterXL Option available - just in Smart1Console. How can we connect the first Cluster XL member to Smart1-Cloud then?

[Chris_Atkinson]

To clarify the process here doesn't work for you?

https://sc1.checkpoint.com/documents/Infinity_Portal/WebAdminGuides/EN/Check-Point-SmartCloud-Admin-... 

[freshwater84]

Hi Chris,

Not really, as the process under "Connecting a Cluster" regards to a normal ClusterXL cluster, and not to ElasticXL
What applies for a new 3920 Elastic XL Cluster here?

[Chris_Atkinson]

Oh sorry you wrote ClusterXL above hence the confusion. 

Suspect it will align to the Maestro process in the same guide but will request the documentation be clarified accordingly. 

[freshwater84]

I'm so sorry, you are right. I meant ElasticXL. Okay, so it's the Maestro Process. Everything clear, thank you!

[Steffen_Appel]

Beside from your Copper/Fibre issue, for me it only worked onced I reimageed the 3920s with T464.