Product Documentation

Cluster and Node States

Oct 19, 2016

For a cluster to be functional, a majority of the nodes (n/2 + 1) must be operationally active (operational state is ACTIVE). Check table below.


From NetScaler release 10.5, you can configure the cluster to be functional even when the majority criteria is not satisfied. This configuration must be performed when creating a cluster.

The following table describes the states of a cluster node:

Type Possible values Description

Admin state


Specifies the responsibility of the node within the cluster setup. You can set the admin state to be one of the following:

  • PASSIVE (default state). These nodes are in sync with the cluster, but do not serve any traffic. You must explicitly change its state to one of the other admin states, to make it ready to play a more active role. In passive admin state, the node becomes Inactive without clearing the existing TCP connections. If the existing connections are not closed properly, all connections on client side or server side disconnect or fail. To avoid this, we must reset all existing connections on the inactive node. 
  • ACTIVE. These nodes are in sync with the cluster and serve traffic that reaches the cluster. Check operational state for information on when this node can serve traffic.
  • SPARE. These nodes act as backup nodes for the cluster. Spare nodes are always in sync with the cluster, but do not serve any traffic till one of the ACTIVE (admin state) nodes becomes unavailable. When this happens, the admin state of this node continues to be SPARE, but its operational state changes to ACTIVE.

    Note: The preemption parameter that is specified on a cluster instance, indicates whether the SPARE node remains operationally active even when a ACTIVE (admin state) node becomes available.

    • If preemption is disabled, the spare node continues to serve traffic even if a node in ACTIVE admin state comes back online. 
    • If preemption is enabled, when a node in ACTIVE admin state comes back online, it preempts the spare node and starts serving traffic. The spare node goes back to inactive state.



Indicates whether the cluster node can successfully handle traffic by checking for the following criteria for the node:

  • The interfaces are up and enabled.
  • The SSL cards are available.
  • The cluster synchronization operation is enabled and completed.
  • The backplane interface is up and enabled.
  • The CLAG member(s) are up.

Based on the above criteria, the health of a node can be:

  • UP. When all the criteria are satisfied.
  • NOT UP. When any one of the criteria is not satisfied.
  • UNKNOWN. When the node cannot receive heartbeats from other nodes.

Operational state


Indicates that the node can serve traffic. The operational state of a node is determined by a combination of the admin state and the health of the node.

  • ACTIVE. When the health of the node is UP and one of the following is true:

    • Node in ACTIVE admin state.
    • Node in SPARE admin state and node is being used as backup.
  • INACTIVE. In the following cases: 

    • Node in PASSIVE admin state, regardless of the health.
    • Node in ACTIVE admin state and health is NOT UP.
    • Node in SPARE admin state and node is not being used as backup.
  • UNKNOWN. When the node cannot receive heartbeats from other nodes.
Review the ns.log file, error counters, and the output of the "show cluster node" command, to help determine the exact reason for a node to be in INACTIVE and UNKNOWN state.