Chapter 8 High Availability

This chapter describes high availability (HA). It contains information on:

• "HA Policy"

• "HA Network Connections and Failovers"

• "Configuring HA"

• "Administering HA"

High Availability (HA)

High Availability (HA) allows you to deploy groups of Screens together in situations where the connection between a protected inside network and a insecure outside network is critical. At any time, one member of the HA cluster is the active Screen. It performs packet filtering, network address translation, logging, and encryption or decryption of packets travelling between the inside and outside networks. The other members of the HA cluster, the passive Screens, receive the same packets and perform the same calculations as the active Screen, and mirror the state of the active Screen, but they do not forward traffic.

HA Policy

When you set up an HA cluster, you designate one Screen as its primary HA Screen. It is configured with the policy's configuration objects, including named screen objects, like address or services with attributes that include these settings, and policy rules that the HA cluster will use. When you activate a policy, the policy's rules are copied from the primary HA Screen to the secondary Screens in the HA cluster.

Solaris settings, such as network interfaces and routing configuration, are not copied from the primary Screen and must be identical on all the Screens in the HA cluster.

---

Caution -

Because the HA cluster transmits secret keys and policies in the clear over the dedicated HA network, keep the HA network physically secure.

---

The IP addresses of the HA interfaces for each member of the HA cluster on the for dedicated network connections must be unique. Assign all HA Screens the same IP addresses on their filtering interfaces. FIGURE 8-1 shows a network protected by two Screens in an HA cluster. Each Screen in the HA cluster connects to the external and internal networks through Ethernet hubs, which pass the same signals to all members of the HA cluster at the same time. Each HA Screen, therefore, sees the same traffic, ensuring that passive Screens can duplicate the state of the packet filter engine should the active Screen fail.

Figure 8-1 Network With HA Cluster of Screens

HA Network Connections and Failovers

Once the HA cluster is running, the active and passive Screens poll each other every few seconds to verify connectivity and status. If the active Screen fails or becomes unavailable, the passive Screen that has been running the longest takes over as the active Screen within 15 seconds. During this time (before the passive Screen takes over), no traffic will go through the HA cluster.

HA is designed to maintain the great majority of network connections. In the case of a reboot (an orderly shutdown), the active Screen being rebooted notifies the passive Screens, and the appropriate passive Screen takes over as the active Screen without loss of connections. Because the passive Screens do not forward, reject, or log packets, the load on passive Screens is less than the load on the active Screen. Consequently, load-induced faults that affect the active Screen are unlikely to affect the passive Screens.

Failover can disrupt these connections:

• Continued connections, for protocols that keep state (memory), such as TCP connections.

• Stateful connections, such as FTP, NFS, NIS, and RPC.

These connections can be lost under any of the following conditions:

• The Screen taking over filtering does not have all the same state information when the failover condition occurs.

• Rarely, a connection through the HA cluster uses dynamic NAT and two or more connections have identical destination addresses, destination ports, or source ports.

HA automatically disconnects if it is only running on one machine, allowing it to act like a standard Screen.

You can configure Screen as part of an HA cluster during installation. Alternatively, you can configure HA settings through the command line, as described in Appendix B, Command-Line Reference.

Configuring HA

High Availability has the following limitations:

• HA does not work on machines running the Solaris 7 operating environment for the Intel Platform.

• Screens in an HA cluster do not exchange state information, they accumulate state independently by processing the same packets. For optimal performance, whenever possible, an HA cluster should comprise systems of equal size (same CPU speed, and memory size). A slower Screen in passive mode can fall behind in processing and eventually fail to have the same state as the active Screen.

• To reinstate a repaired Screen, install it as a secondary Screen and add it to the cluster.

You do not have to switch back to the original Screen except when its abilities or speeds are better. If they are, you can force the faster machine to take over as the active Screen, or wait until both machines have the same state (eventually the out-of-sync connections will time-out and become synchronized) and force the failover.

• Secrets are sent in the clear on the dedicated HA network to facilitate administrative communication within the HA cluster. Reserving the HA interface as a separate network from other traffic helps prevent discovery of the Screen's private certificates.

• Each Screen in an HA cluster must have a unique node name and a unique IP address on the dedicated HA network. All other aspects of the Solaris system configurations must be identical on all Screens in the HA cluster. This includes the configuration of all network interfaces (other than the HA interface).

• HA does not work well with proxies because proxy state tables are not present on all HA machines.

• HA Screens must be connected to each other through a shared network (such as a 10BaseT or 100BaseT hub) and not through a switched network (such as an Ethernet switch) because it will send each packet to only one HA Screen, rather than to all of them.

• HA cannot be used on networks that use media other than Ethernet, such as FDDI, Token-Ring, or ATM.

• Because passive HA hosts do not generate traffic (other than automatic administrative traffic, such as HA administration and HA heartbeat), you cannot use telnet for connecting to passive HA Screens. You can use telnet for communicating with an active HA Screen only.

• The HA cluster decides internally which member will be the active Screen.

Administering HA

If the HA cluster has an ADMIN interface, you can use the IP address of the ADMIN interface to administer the Screen. The ADMIN interface must be on the primary Screen. This is the normal setup for stealth mode and is the best way to set up routing mode as well.

If the HA cluster does not have an ADMIN interface, the Administration Station needs to connect to a unique IP address to determine which Screen is the primary and which is the secondary. The filtering interfaces share the same IP address in routing mode or have no IP address in stealth mode. The only interface with a unique IP address is the HA interface. You must connect to the HA interface of the primary Screen for administration.

The configuration information is only stored on the primary Screen. If, therefore, with remote administration, you want to change the configuration, you must connect to the primary Screen using an ADMIN interface or the HA interface. The primary does not have to be the active Screen. A passive Screen still receives and transmits administration traffic.

If the address for HA interfaces on the dedicated network connecting the HA Screens are unregistered, you can still administer the primary Screen. The Administration Station has a route to the HA interface of the primary Screen because the HA cluster and the Administration Station are both connected to the network for which the Screens are filtering traffic and can, therefore, communicate with each other. Problems occur when the Administration Station cannot connect directly to one of the Screen's filtering interfaces and the packets from the Administration Station must be routed to the Screen. In this case the routers in between must also know about the unregistered HA interfaces.