High Availability has the following limitations:
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. You can force the faster system to take over as the active Screen, or wait until both systems have the same state (eventually the statetables of the out-of-sync Screens will time-out and become synchronized) .
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).
Proxies connect directly to the active Screen. These proxy connections will not be on the new active Screen if the previously-active Screen fails.
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 a switched network will send each packet to only one HA Screen, rather than to all of them.
SunScreen HA in routing mode does not support FDDI, token ring, ATM, Gigabit Ethernet, or failover of IKE-based IPsec connections.
Because passive HA Screens 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 the active HA Screen only.
The HA cluster decides internally which member will be the active Screen. If the active Screen fails, the secondary Screen that has been running the longest becomes active.