Support Center > Search Results > SecureKnowledge Details
Status of HA cluster Standby member is changed to Down due to FIB pnote and then back to Standby
Symptoms
  • SmartView Tracker occasionally shows that Standby member changes its state to Down due to FIB pnote and then back to Standby.

    Example:
    cluster_info: (ClusterXL) member 2 (10.0.0.2) is down (Problem Notification on member 2 (10.0.0.2) detected a problem (FIB).).
    cluster_info: (ClusterXL) member 2 (10.0.0.2) is up (Problem Notification on member 2 (10.0.0.2) status OK (FIB).).
    cluster_info: (ClusterXL) member 2 (10.0.0.2) is up.
    cluster_info: (ClusterXL) member 2 (10.0.0.2) is standby.
Cause

This behavior is by design. The Standby member needs to update its routing table by requesting the most recent routing information from the Active member.

When the state of Standby member changes from Standby to Active and then back to Standby, or from Standby to Down and then back to Standby, the Standby member needs to make sure that it has the most recent routing information.

Standby member (having GateD daemon in Slave state) obtains the most recent routing information by querying the Active member (having GateD daemon in Master state).

In order to avoid a collision between an automatic update via FIB and this manual update, the Standby member de-activates the FIBMGRD, and this in turn causes the kernel to report a Problem state on FIB pnote.

By design, when a pnote reports a problem, a cluster member changes its state to Down.

After the most recent routing information is obtained from Active member (after the last route is read), the Standby member re-activates the FIB, and this in turn causes the kernel to report OK status on FIB pnote.

As a result, the Standby member goes back up to Standby state.

The whole process usually takes several (3-5) seconds.


Solution
Note: To view this solution you need to Sign In .