ClusterXL shows Active Attention / Interface Active Check Error
VendorCheck Point
PlatformSPLAT
VersionR65 NGX
Firewalls - Checkpoint
Tuesday, 23 February 2010 13:21

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

1          192.168.12.1   100%            active attention
2 (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)

root@firewall # cphaprob list

Built-in Devices:

Device Name: Interface Active Check
Current state: problem

Registered Devices:

Device Name: Synchronization
Registration number: 0
Timeout: none
Current state: OK
Time since last report: 241598 sec

Device Name: Filter
Registration number: 1
Timeout: none
Current state: OK
Time since last report: 241598 sec

Device Name: fwd
Registration number: 2
Timeout: 2 sec
Current state: OK
Time since last report: 1 sec

Device Name: cphad
Registration number: 3
Timeout: 2 sec
Current state: OK
Time since last report: 1 sec

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

Device Name: Interface Active Check
 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:

root@firewall # cphaprob -a if
Required interfaces: 6
Required secured interfaces: 1

eth4       UP              sync(secured), unique,  multicast
eth0       UP              non sync(non secured), shared,  multicast
eth1       Inbound: DOWN (241522 secs)  Outbound: DOWN (241523 secs)  non sync(non secured), shared,  multicast
eth10      UP              non sync(non secured), shared,  multicast
eth11      Disconnected                  non sync(non secured), unique,  broadcast
eth2       UP              non sync(non secured), unique,  multicast
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.

root@firewall # cat $FWDIR/conf/discntd.if
eth1
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.

 



Related Articles
 
We have 26 guests online