- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
Hi everyone,
We are facing a strange issue in one of our cluster. After adding a new interface in the cluster, the unique address of the other member showed in cphaprob state is flapping. the address is constantly changing if I'm watching cphaprob state between all the interfaces addresses (sync address too).
However, the cluster is working fine. (no failover)
On member 1 I have this type :
1 (local) 'SYNC ADDRESS' 100% Active
2 'OTHER INTERFACE ADDRESS' 0% Standby
And on member 2 :
1 'OTHER INTERFACE ADDRESS' 100% Active
2 (local) 'SYNC ADDRESS' 0% Standby
The cphaprob -a if is good (all interfaces UP), I'm in Broadcast CCP due to TP switches.
netstat -in shows no error at all.
The strange thing is that if I remove the new interface from topology, the cluster is back to normal. I already contacted Checkpoint regarding this issue and they gave me the sk43984 but it's not helping me.
Thanks for your time,
Hi everyone,
We finally solved the issue today.
The issue was quite simple in fact. As the checkpoint is on a TP site, we do not have the hand on the switches.
They finally found that the new interface recently added to the topology were in the same VLAN as the sync interface. So the broadcast domains were the same which causes all the troubles in the display and some failover too !
Thanks for your help guys.
There are multiple steps in the SK.
Which ones did you try and what results did you find?
Please make sure sync network is completely isolated from the production networks. It seems you are receiving a "wrong" CCP frame on sync interface from time to time.
Dameon Welch Abernathy the issue so far is cosmetic, so the regular ClusterXL troubleshooting might not yield a result here, unless there is a fail-over situation.
I would advise an extensive ClusterXL debug, but that is for a Support Engineer on the case to decide
Hi Valeri and Dameon,
First of all, thanks for your time.
@Daemon, on the SK I did the folllowing :
Step 1 : 0% loss and less than 1ms latency
Step 2 : already did
Step 3 : Two Pingable hosts
Step 4 : In R77.30, it's already configured
Step 5 : Same as step 4
Step 6 is not relevant for me
Step 7 : CPU is stable
Step 8 : I prefer to do this in mainteance window,
Step 9 : same as step 8
@Valeri,
Unfortunately, I don't have the hand on the network equipement on site, but they assure that all the interfaces are isolated properly.
I'm in discussion with a Checkpoint Engineer actually, I'm trying to negotiate a maintenance window with the TP, he wants to debug by himself on the gateways.
Hi everyone,
We finally solved the issue today.
The issue was quite simple in fact. As the checkpoint is on a TP site, we do not have the hand on the switches.
They finally found that the new interface recently added to the topology were in the same VLAN as the sync interface. So the broadcast domains were the same which causes all the troubles in the display and some failover too !
Thanks for your help guys.
That will definitely do it.
Thanks for updating us.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 19 | |
| 17 | |
| 14 | |
| 8 | |
| 7 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 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 cloudsTue 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