Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Romaric_DUCLOUX
Participant
Jump to solution

HA Sync Address flapping in a cluster

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,

1 Solution

Accepted Solutions
Romaric_DUCLOUX
Participant

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.

View solution in original post

0 Kudos
5 Replies
PhoneBoy
Admin
Admin

There are multiple steps in the SK.

Which ones did you try and what results did you find?

0 Kudos
_Val_
Admin
Admin

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

0 Kudos
Romaric_DUCLOUX
Participant

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.

0 Kudos
Romaric_DUCLOUX
Participant

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.

0 Kudos
PhoneBoy
Admin
Admin

That will definitely do it.

Thanks for updating us.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events