HA Clusters

The High Availability (HA) feature provides hardware redundancy for Clavister NetShield Firewall installations. HA works by adding a back-up slave Clavister NetShield Firewall to an existing master firewall.

The master and slave are connected together and make up a logical HA Cluster. One of the units in a cluster will be active when the other unit is inactive and on standby. The master and slave are also referred to as cluster peers or nodes.

Initially, the cluster slave will be inactive and will only monitor the activity of the master, mirroring the master's internal state as closely as possible. If the slave detects that the master has a malfunction, an HA failover takes place and the slave becomes active, assuming processing responsibility for all traffic.

If the master later becomes operative again, the slave will continue to be active but the master will now monitor and mirror the slave with failover only taking place if the slave malfunctions. This is sometimes known as an active-passive cluster implementation.

The Master and Active Units

When reading this section, it should be kept in mind that the master unit in a cluster is not always the same as the active unit in a cluster.

The active unit is the firewall that is actually processing all traffic at a given point in time. This could be the slave after a failover has occurred.

Connecting Together Cluster Interfaces

Interface pairs should be connected together via switches. Note that inter-device communication is not routable. For supported virtual environments, interface connection is described in detail in the HA section of the separate cOS Stream Virtual Series Getting Started Guide

Note that there should be identical logical naming of the interfaces in each pair.

The Sync Interface

In a cluster, the master and slave must be directly connected to each other by the connection known as the Sync interface. The purpose of the Sync interface is to carry state synchronization traffic between the HA cluster peers and the interface should therefore not be used for normal traffic.

The information transferred over the Sync interface includes state information for the following:

In addition, because the configurations of the HA peers must be aligned, their configurations are also sent over the Sync interface.

A matching interface pair on the master and the slave should be dedicated for this purpose, so that the link carries only synchronization traffic. These interfaces need to be connected to each other via a common network segment that is fully separated from other traffic. This can be accomplished by, for example, using a crossover cable or a dedicated switch. In a virtual environment, a dedicated virtual switch can be used for this purpose.

For security reasons and to avoid HA performance problems, connection of Sync interfaces via a shared switch that is also carrying other traffic is not recommended. Such a setup is only acceptable if the switch ports used for sync traffic are isolated from other ports by using VLAN separation or similar.

Setting Up the Sync Interface

To set up the Sync interface, the HAType property of an interface's EthernetInterface object must be set to the value Sync as shown in the example CLI below:

System:/> set Interface EthernetInterface if1 HAType=Sync

By default, the type defaults to Critical.

Cluster Heartbeats

Special Ethernet frames, known as heartbeats, are continually sent by cOS Stream between the peers in the cluster across the Sync interface and any other interfaces which have their HAType property set to Critical (the default HAType value is Critical). Heartbeats are sent in both directions so that the passive peer knows about the health of the active peer and the active knows about the passive.

Any interfaces which have an HAType value of NonCritical in the configuration do not have heartbeats sent over them and will not cause an HA failover if they fail. Failure of a Sync or Critical interface will cause a failover to occur once cOS Stream confirms the failure.

The heartbeat mechanism is discussed further in Section 22.2, HA Mechanisms.

Cluster Management and Configuration Synchronization

When changing the configuration of one cluster peer, changes are automatically duplicated on the other peer provided that the property AutoSyncCfg in the cluster HighAvailability object is enabled (by default, it is enabled).

When the AutoSyncCfg property is enabled, it is recommended to make configuration changes on the inactive cluster peer since this will result in only a single failover as the two peers synchronize after changes are activated. Changing the active peer will result in two failovers.

The AutoSyncCfg setting is disabled with the following command and this must be applied separately to each peer in the cluster:

System:/> set HighAvailability AutoSyncCfg=No

Once this setting is disabled, each cluster peer configuration must be changed separately via a separate management interface since changes on one device will not be automatically copied to the other.

If required, it is possible to use the following command to manually force the sending of the configuration on a cluster peer to the other peer so they are synchronized:

System:/> ha -sendconf

To manually force a peer to synchronize by retrieving the configuration from the other cluster peer, use the following command:

System:/> ha -receiveconf

Load-sharing

HA clusters do not provide load-sharing since only one unit will be active while the other is inactive and only two Clavister NetShield Firewalls, the master and the slave, can exist in a single cluster. The only processing role that the inactive unit plays is to mirror the state of the active unit and to take over all traffic processing after a failover if it determines that the active unit has failed.

Hardware Duplication

An HA cluster can only be set up between two Clavister NetShield Firewalls. As the internal operation of different manufacturer's software is completely dissimilar, there is no common method available to communicating state information to a dissimilar device.

It is strongly recommended that the Clavister NetShield Firewalls used in an HA cluster have identical processing platforms. In a virtual environment this means that the Clavister NetShield Firewalls have identical resources allocated to them. Where applicable, they must also have identical firewall licenses which allow identical capabilities, including the ability to run in an HA cluster.

Extending Redundancy

Implementing an HA Cluster will eliminate one of the points of failure in a network. Routers, switches and Internet connections can remain as potential points of failure and redundancy for these should also be considered.

Setup with IPv6

HA clusters can be set up using IPv4 or IPv6 addresses or in combination with IPv4. With IPv6, the principles of a shared IP address are the same but instead of ARP, IPv6 mechanisms are used.

HA can be set up using IPv6 addresses exclusively. There is no necessity to include IPv4 as part of cluster setup.