Difference between revisions of "Cphaprob stat active / attention status"

Latest revision as of 18:30, 27 February 2013

problem description

ClusterXL shows Active Attention / Interface Active Check Error Vendor Check Point Platform SPLAT Version R65 NGX Firewalls - Checkpoint Tuesday, 23 February 2010 13:21 Share on emailShare on printShare on deliciousShare on twitterShare on diggShare on stumbleuponShare on facebook

This article will provide the required troubleshooting steps for resolving the issue of the "Interface Active Check" error within ClusterXL.

First of all you spot there is an error within ClusterXL using the following command,

root@firewall # cphaprob stat

Cluster Mode:   Legacy High Availability (Active Up)

Number     Unique Address  Assigned Load   State

192.168.12.1 100%            active attention
(local)  192.168.12.2   0%              down

Confirming the issue

To pinpoint which part of the ClusterXL Check Point is not happy with run the following command. (This will list all the ClusterXL components and there status`s)

01.root@firewall # cphaprob list
02. 
03.Built-in Devices:
04. 
05.Device Name: Interface Active Check
06.Current state: problem
07. 
08.Registered Devices:
09. 
10.Device Name: Synchronization
11.Registration number: 0
12.Timeout: none
13.Current state: OK
14.Time since last report: 241598 sec
15. 
16.Device Name: Filter
17.Registration number: 1
18.Timeout: none
19.Current state: OK
20.Time since last report: 241598 sec
21. 
22.Device Name: fwd
23.Registration number: 2
24.Timeout: 2 sec
25.Current state: OK
26.Time since last report: 1 sec
27. 
28.Device Name: cphad
29.Registration number: 3
30.Timeout: 2 sec
31.Current state: OK
32.Time since last report: 1 sec 

From this you can see that the issue is based on the Interface Checking,

1.Device Name: Interface Active Check 2.Current state: problem

Checking the Monitored Interfaces

Now that we see the error we will need to look a bit closer at the state of the interfaces:

01.root@firewall # cphaprob -a if
02.Required interfaces: 6
03.Required secured interfaces: 1
04. 
05.eth4       UP              sync(secured), unique,  multicast
06.eth0       UP              non sync(non secured), shared,  multicast
07.eth1       Inbound: DOWN (241522 secs)  Outbound: DOWN (241523 secs)  non sync(non secured), shared,  multicast
08.eth10      UP              non sync(non secured), shared,  multicast
09.eth11      Disconnected                  non sync(non secured), unique,  broadcast
10.eth2       UP              non sync(non secured), unique,  multicast
11.eth3       UP              non sync(non secured), shared,  multicast

We can see here that eth1 is still being monitored but is showing as down. When I connect to the other cluster node I see that eth1 is also showing down.

Solution

So in order to ensure that Check Point completely ignores this interface we will need to add this interface to the file "$FWDIR/conf/discntd.if". Below shows you how the file should look once we add eth1 to it.

1.root@firewall # cat $FWDIR/conf/discntd.if 2.eth1 3.eth11

Once you have changed this file on both nodes, re-push the policy and the ClusterXL status should be back to Active/Standy and the output of "cphaprob list" should show no errors.

If it appears that this hasnt resolved the issue run a `cphaprob -a if` and confirm that this interface is now showing as disconnected. If the output of `cphaprob stat` is still not showing active/standby run a `cpstop && cpstart` on each node which then should resolve the problem.

This occurred on R75.40 splat. Was fixed after a reboot of each node.