Checkpoint Cluster setup

============= ClusterXL HA========

2 modes:

HA (active standby)

Load sharing / Load Balancing (active active) -- unicast or multicast

virtual IP address

state synchronization -- full vs delta

CCP - Cluster control protocol over all interfaces

Cluster status:

active

standby

down

active attention

ready

initializing

ClusterXL inactive or machine is down

1. During the GW installation, choose ClusterXL as cluster type

2. After both GW are installed, in SmartConsole, add a new cluster

3. Add cluster member

4. Both GW are added

5. Configure cluster

6. Create cluster IP for each data interface.

7. Create HA interface on both GW.

8. Re-fetch network interfaces with topology

9. Review and adjust log setting.

10. Cluster status are red, after install policy will be turned to green.

---------------------------

Check HA status

old command:

cphaprob [state]

gw-3> show cluster state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 (local) 192.168.254.86 100% ACTIVE CP-3

2 192.168.254.87 0% STANDBY CP-4

Active PNOTEs: None

Last member state change event:

Event Code: CLUS-114904

State change: ACTIVE(!) -> ACTIVE

Reason for state change: Reason for ACTIVE! alert has been resolved

Event time: Fri Jan 26 10:03:36 2024

Cluster failover count:

Failover counter: 0

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-3>

---

gw-4> show cluster state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 192.168.254.86 100% ACTIVE CP-3

2 (local) 192.168.254.87 0% STANDBY CP-4

Active PNOTEs: None

Last member state change event:

Event Code: CLUS-114802

State change: DOWN -> STANDBY

Reason for state change: There is already an ACTIVE member in the cluster (member 1)

Event time: Fri Jan 26 10:03:36 2024

Cluster failover count:

Failover counter: 0

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-4>

----

Manual bring a member cluster down

gw-3> set cluster member admin

Use the Critical Device 'admin_down' to manually set / unset the member state to / from DOWN.

For more information, see ClusterXL Administration Guide.

gw-3> set cluster member admin down

This command does not survive reboot. To make the change permanent, run either the 'set cluster member admin {down|up} permanent' command in Gaia Clish, or the 'clusterXL_admin {down|up} -p' command in Expert mode

Setting member to administratively down state ...

Member current state is DOWN

gw-3>

gw-3> show cluster state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 (local) 192.168.254.86 0% DOWN CP-3

2 192.168.254.87 100% ACTIVE CP-4

Active PNOTEs: ADMIN

Last member state change event:

Event Code: CLUS-111400

State change: ACTIVE -> DOWN

Reason for state change: ADMIN_DOWN PNOTE

Event time: Fri Jan 26 10:18:16 2024

Last cluster failover event:

Transition to new ACTIVE: Member 1 -> Member 2

Reason: ADMIN_DOWN PNOTE

Event time: Fri Jan 26 10:18:16 2024

Cluster failover count:

Failover counter: 1

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-3>

Bring member back to cluster

gw-3> set cluster member admin up

Setting member to normal operation ...

Member current state is STANDBY

gw-3>

gw-3> show cluster state

Cluster Mode: High Availability (Active Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 (local) 192.168.254.86 0% STANDBY CP-3

2 192.168.254.87 100% ACTIVE CP-4

Active PNOTEs: None

Last member state change event:

Event Code: CLUS-114802

State change: DOWN -> STANDBY

Reason for state change: There is already an ACTIVE member in the cluster (member 2)

Event time: Fri Jan 26 10:22:43 2024

Last cluster failover event:

Transition to new ACTIVE: Member 1 -> Member 2

Reason: ADMIN_DOWN PNOTE

Event time: Fri Jan 26 10:18:16 2024

Cluster failover count:

Failover counter: 1

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-3>

Or command in Export mode

Usage: clusterXL_admin <up|down>

Failover from GUI

cluster member on the top has high priority

This setting determine if make the high priority member active

After Install Policy

gw-3> show cluster state

Cluster Mode: High Availability (Primary Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 (local) 192.168.254.86 100% ACTIVE CP-3

2 192.168.254.87 0% STANDBY CP-4

Active PNOTEs: None

Last member state change event:

Event Code: CLUS-114104

State change: INIT -> ACTIVE

Reason for state change: Member state has been changed due to higher priority of local cluster member in PRIMARY-UP cluster

Event time: Fri Jan 26 10:28:57 2024

Last cluster failover event:

Transition to new ACTIVE: Member 2 -> Member 1

Reason: Member state has been changed due to restart of the Cluster module

Event time: Fri Jan 26 10:28:57 2024

Cluster failover count:

Failover counter: 2

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-3>

gw-4> show cluster state

Cluster Mode: High Availability (Primary Up) with IGMP Membership

ID Unique Address Assigned Load State Name

1 192.168.254.86 100% ACTIVE CP-3

2 (local) 192.168.254.87 0% STANDBY CP-4

Active PNOTEs: None

Last member state change event:

Event Code: CLUS-114802

State change: INIT -> STANDBY

Reason for state change: There is already an ACTIVE member in the cluster (member 1)

Event time: Fri Jan 26 10:28:57 2024

Last cluster failover event:

Transition to new ACTIVE: Member 2 -> Member 1

Reason: Member state has been changed due to restart of the Cluster module

Event time: Fri Jan 26 10:28:57 2024

Cluster failover count:

Failover counter: 2

Time of counter reset: Thu Jan 25 17:17:38 2024 (reboot)

gw-4>

GUI Logs:

Queries > System, or type:Control in search box

Active Up

ClusterXL in High Availability mode that was configured as Maintain current active Cluster Member in the cluster object in SmartConsole:

Primary Up

ClusterXL in High Availability mode that was configured as Switch to higher priority Cluster Member in the cluster object in SmartConsole:

===========VRRP============

Check Point sees VRRP as a 3rd party cluster protocol. Check Points applications, such as SmartView Monitor, might not always shows correct values when using 3rd party solutions

Monitored Circuit/Simplified VRRP - All the VRRP interfaces automatically monitor other VRRP interfaces.
Advanced VRRP - Every VRRP interface must be explicitly configured to monitor every other VRRP interface.

VRRP Term	ClusterXL Term	Definition
VRRP Cluster	Cluster	A group of Security Gateways that provides redundancy.
VRRP Router	Member	A Security Gateway using the VRRP protocol that is a member of one or more Virtual Router. In this guide, a VRRP Router is commonly called a Security Gateway.
Master	Active	The Security Gateway (Security Gateway) that handles traffic to and from a Virtual Router. The Master is the Security Gateway with the highest priority in a group. The Master inspects traffic and enforces the security policy.
Backup	Standby	A redundant Security Gateway (Security Gateway) that is available to take over for the Master in the event of a failure.
VRID	Cluster name	Unique Virtual Router identifier The VRID is the also last byte of the MAC address.
VIP	Cluster Virtual IP address	Virtual IP address assigned to a Virtual Router. VIPs are routable from internal and/or external network resources. The VIP is called Backup Address in the Gaia Portal.
VMAC	VMAC	Virtual MAC address assigned to a Virtual Router.
VRRP Transition	Failover	Automatic change over to a backup Security Gateway when the primary Security Gateway fails or is unavailable. The term 'failover' is used frequently in this guide.