Cluster state Active-Down

[Daniel85]

Hello everyone, I recently started configuring Check Point Security Gateways.

I don't have much experience with this, so I'm turning to this forum for some guidance. I received a clustered device from a client, and after checking its status, I found it was in an Active > Down state.

After some investigation, I discovered that two interfaces were removed and migrated to a core switch, but these interfaces weren't removed from the cluster. I believe this is the reason for the current status.

I've seen that I need to follow SK57100. One of the steps mentions that I should access the manager server, put my interfaces into passive mode, and delete the virtual IPs. In the current state of my device, are the policies still being installed on the secondary device?

Or do I absolutely have to reconnect the previously removed connections and then perform the process mentioned in SK57100?

[_Val_]

Look at the output of "cphaprob stat" command.

Most probably it is about interfaces removed, but it might be something else.

If it is indeed about interface probing, do the following:

1. On both cluster members, disable disconnected interfaces.

2. On your Security Manager, edit the cluster object, adjust the topology, and push policy to the cluster.

If you perform both steps correctly, the cluster should go to Active-Standby. Production traffic should not be affected in the process.

[Martijn]

Hi,

With 'cphaprob -a list' you can check why the cluster is in this state. But as Val already mentioned, the missing interfaces are likely the cause.

The interfaces in the SmartConsole cluster object must represent the IP interfaces within the Gaia OS.
So if they are removed in the OS, you should remove them from the cluster object also.

The steps described by Val are the ones to take.

Let us know how it goes.

Martijn

[Daniel85]

Thank you so much for taking the time to help and share your knowledge with a newbie. I'll try what you suggested next Monday. When I run cphaprob -a , I get that the problem is due to local probing.

That's why I focused on fixing the issue with the interfaces that are being monitored.

That's why I'm focusing on fixing the issue with the monitored interfaces.
My main question, as I mentioned to Bob, is whether the configuration is still replicated on both devices in that state,
since I can only install them using the option I mentioned.

[Bob_Zimmerman]

There are a few cluster member statuses to be aware of:

• Active - The cluster member doesn't see any problems, and it is passing traffic.
• Standby - The cluster member doesn't see any problems, and it's not passing traffic.
• Active(!) or Active Attention - The cluster member sees a problem, but it thinks it's the healthiest member, so it's passing traffic.
• Down - The cluster member sees a problem, and it is not passing traffic.
• Lost - Only appears for a non-local cluster member which the local cluster member no longer sees (e.g, while the other member is rebooting).
• Ready - Seen during upgrades. The member is up and able to pass traffic, but it saw another cluster running a different version with the same cluster ID on the wire. The member will not pass traffic until it stops seeing control traffic from the members on the other version.
• Init - The cluster processes are starting; the member will not process traffic.

Note that a totally failed cluster member doesn't show as Down, it shows as Lost. A Down member is still partially functional, and can go to Active(!) if there's no healthier member in the cluster. As long as you don't get an error when pushing policy, the policy changes are making it to both members.

As for removing interfaces which are no longer connected, you can just delete them from the object in SmartConsole, push policy (this is where the cluster will stop monitoring them, so it should go back to Active/Standby), then delete them on the command line.

[Daniel85]

My question is related to whether the policies are actually being sent to both members in that state: Active(!) - Down. When I try to install the policy, I need to disable the option "For gateway clusters, if installation on a cluster member fails, do not install on that cluster." If I don't do it this way, I get a policy installation error.
Even after doing this, are the policies still installed on both members?
Sorry for so many questions, but I'm coming from working with other firewalls and I'm not yet fully familiar with Check Point.

[Bob_Zimmerman]

Unchecking that box is specifically telling the system "Let me install on only one member of the cluster". The box should always be checked except during a manual upgrade, or potentially when recovering from a disaster.

Even with the box unchecked, you should still get an error on one member telling you policy could not be installed on it.

[the_rock]

Hi,

If you could send us the output of below 5 commands from both members, would certainly give us a better idea how to fix the issue.

cphaprob state

cphaprob -a if

cphaprob syncstat

cphaprob -i list

cphaprob -l list