- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
10 December @ 5pm CET / 11am ET
Improve Your Security Posture with
Threat Prevention and Policy Insights
Overlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
At the beginning, CP_B is the active and CP_A is the backup, after executing clusterXL_admin down,clusterXL_admin up on CP_B, the clients to access the server's business are all disconnected, and then executing clusterXL_admin down,clusterXL_admin up on CP_A, the clients to access the server's business are also disconnected. admin up on CP_A, the client to access the server is also disconnected. After looking at the messages, the status of HA is normal in both switchovers and there is also traffic to the firewall.
The topology diagram is as below:
That is possible for services that are not synchronized on the cluster. If connections are not set to keep data or rematch they will be disconnected. To check and synchronize a service, double click it => Advanced => Sync on cluster.
The increased amount of connections reflect the high load on both members.
Would further investigate the issue related to system load.
High load could impact cluster functionality.
You can decide for every service if and how to sync between cluster nodes.
I would definitely open TAC case to investigate this further. Just generate cpinfo files, as well as /var/log/messages*
Andy
Thanks for your reply! I have exported the cpinf file the day after the failure. However, I see on the messages file that the firewall status is normal after switching active and standby twice.
Is clustering working right?
Please send below:
cphaprob state
cphaprob -a if
cphaprob roles
cphaprob -i list
cphaprob -l list
cphaprob syncstat
Andy
Maybe the network devices do not learn the ARP change of the VIP fast enough.
You can see if traffic still flowing on the GW after you run clusterXL_admin down
vmac might help if this is the case.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 25 | |
| 20 | |
| 8 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 5 | |
| 4 | |
| 4 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY