First time clustering HA on SMB

[Askey_oot]

Hello!

I am preparing to create a cluster of two Quantum Spark 2000 devices with the same installed firmware 81.10.17. Currently, while comparing various entries in different official documentation or video tutorials, I have questions that I cannot answer myself.

The first Spark 2000 device, designated as Primary, has been operating in production for a long time (let's assume more than several months). Some time ago, I unpacked the second Spark 2000 device, activated the licenses, and updated the firmware to version 81.10.17. I would like to prepare it for connection in an HA configuration using the dedicated LAN2/SYNC interface. Do I need to import the same configuration from the primary device to the secondary device, or do I only need to configure the LAN and VLAN interfaces on the secondary device and nothing else?

Another question concerns clustering LAN and VLAN interfaces. I have a trunk connected to the primary device on port X1 and a VLAN configured with ID 10 and its addressing is 192.168.1.0/24 with default gateway 192.168.1.1. When I use Wizard in GUI web mdoe, in the Cluster IP address field, I enter 192.168.1.1 as the VIP gateway for client stations, and from the pool, I additionally designate two highest addresses: 192.168.1.252 for the primary X1 interface and 192.168.1.253 for the secondary device's X1 interface. Is this the correct configuration? Does it make sense to cluster each individual VLAN, or is it sufficient to cluster the physical trunk interface and monitor it? Or maybe it's enough to only monitor the VLANs?

Example:

 

The final question concerns the addressing for the clustered WAN interface for internet access. Let's assume I only have one WAN interface, and its true public one IP address received from the operator is 200.110.100.44/32. When configuring this interface in HA using the Wizard, in the Cluster IP address field I enter the true address 200.110.100.44, while in the primary and secondary physical IP fields I enter fictitious addresses, e.g., 223.0.113.1 and 223.0.113.2. Is this a correct assumption that should be made here?

Example

Thank you very much for any suggestions 🙂

[the_rock]

Maybe better to confirm with TAC to be 100% sure, though Im positive someone here will know. FWIW, here is what AI gave...

***********************

Excellent and very thoughtful questions — you’re clearly preparing this Spark 2000 HA setup properly. Let’s go through each part carefully because the SMB clustering (HA) behavior on Quantum Spark 1500–2000 series (R81.10.17) differs slightly from standard Gaia clusters.

---

🧩 1️⃣ Do you need to clone/import configuration to the secondary?

No, you do not manually import or duplicate the full configuration.

When you create an HA pair on SMB appliances:

• The Primary unit is considered the configuration master.

• The Secondary unit will synchronize all settings automatically once HA is established and synchronization completes.

So, what you should do on the Secondary before starting the HA Wizard:

✅ Steps:

1. Reset to factory defaults (to avoid residual settings).

2. Assign only:

   • Management IP (temporarily, on LAN or WAN so you can access the WebUI).

   • The same firmware version as the Primary (you already did this).

3. Run the High Availability Wizard and choose Secondary.

   • During the wizard, specify the same Sync interface (e.g. LAN2/SYNC).

   • The wizard will detect the Primary and pull the configuration once the sync starts.

So you don’t manually configure LAN/VLANs on the secondary — they are replicated after sync.

---

🌐 2️⃣ LAN / VLAN clustering design (VIPs)

Let’s analyze your example:

Role	Interface	IP	Comment
Cluster VIP	VLAN 10 (on X1 trunk)	192.168.1.1	Virtual IP used by clients as gateway
Primary member	VLAN 10	192.168.1.252	Local IP of member A
Secondary member	VLAN 10	192.168.1.253	Local IP of member B

✅ Yes — that is exactly correct.
This is how HA interfaces are designed on SMB:

• Each interface in the cluster has three IPs: one virtual (VIP) + one per member.

• The VIP is the gateway seen by your LAN clients.

Monitoring and VLANs

You can:

• Either cluster the trunk port itself (e.g. X1) and include all VLANs under it.

• Or cluster individual VLAN interfaces (e.g. X1.10, X1.20, etc.) depending on how your design looks.

✅ Best practice:
Cluster each VLAN interface if you’re using multiple VLANs, so that the HA mechanism can track them individually.
The physical trunk (X1) doesn’t need its own cluster IP if you only use VLAN-tagged subinterfaces — it’s just the carrier.

If you have only one VLAN, your current setup (X1 trunk + VLAN10) is perfect.

---

🌍 3️⃣ WAN interface and public IPs

This part is the most commonly misunderstood, so let’s clear it up precisely.

You said:

Only one true public IP 200.110.100.44/32
In the Wizard, I enter VIP = 200.110.100.44, and physicals 223.0.113.1 / 223.0.113.2.

✅ Yes — that’s correct and required.

Here’s why:

• The VIP (200.110.100.44) is the address the Internet “sees” and your ISP routes to.

• Each cluster member still needs its own local unique IP on that interface for internal HA communication (health checks, sync tracking, etc.).

• These “member” IPs (223.0.113.1 / 223.0.113.2 in your example) are not used externally and can be any RFC5737 test addresses or even private ones if the link partner doesn’t care (but it’s cleaner to stay in the same subnet if the ISP allows /29).

💡 If you truly have a /32 (single IP only), you can assign the “real” address only to the VIP and assign fictitious /29-style IPs as members, exactly as you described. This is the recommended workaround in Check Point’s SMB HA documentation.

---

🧭 4️⃣ TL;DR Summary

Task	What to Do
Secondary setup	Factory default → same firmware → run HA Wizard as Secondary
Config sync	Automatic from Primary via SYNC interface
VLANs	Define VIP + Primary + Secondary IPs per VLAN (clustered VLANs, not just trunk)
WAN / Public IP	Use real public IP as VIP, fictitious ones for members (if only one real IP available)
Cluster Sync	Use dedicated LAN2/SYNC interface (make sure it’s isolated from production traffic)

---

🧱 5️⃣ Bonus Tips

• Ensure both devices have identical license sets (same services, same contract) — otherwise sync may fail.

• After forming the cluster, go to Device > High Availability > Status — ensure it shows “Active/Standby (synchronized)”.

• You can test failover safely with Device > High Availability > Force Failover.

• Don’t forget to adjust any DHCP, VPN, or static routes that reference the interface IPs — always point to the Cluster VIP.

---