Configure PIX Security Appliance Failover
Active/active failover

Previously, under the Active/Standby failover model, only one PIX Security Appliance could be actively processing user traffic while the other unit acted as a hot standby, and prepared to take over if the active unit failed. Cisco PIX and ASA security appliances software release 7.0 adds the capability of active/active failover. When two devices are configured to function in active/active failover, both units can actively process traffic while at the same time serving as a back up for their peer unit.

The active/active failover feature leverages the virtual context feature. In the example in Figure , there are two PIX Security Appliances configured for active/active failover, Unit A and Unit B. Each PIX is partitioned into two contexts, ctx1 and ctx2. In the two unit active/active scenario, under normal conditions, there is one active context and one standby context per unit. In Unit A, ctx1 is active and passing traffic. Ctx1 in Unit B is in standby state. In Unit B, ctx2 is active and passing traffic while ctx2 in Unit A is in standby state. Under normal conditions, each unit handles 50% of the traffic. The PIX active/active cluster itself does not perform load balancing. It is the administrator’s responsibility to engineer the network to route 50% of the traffic to each unit. This can be accomplished either statically or with the use of an upstream router to do load balancing on the traffic.

In Figure , Unit A ctx1 was active while ctx2 was standby. Unit B ctx1 was standby while ctx2 was active. Active/active failover logic enables each PIX Security Appliance to determine whether a failure is a context-based or unit-based failure. If an active context fails, the active context transitions to a failed state. In the peer PIX, the standby context changes from standby to active. For example in Figure , if Unit A interface e0 fails, the Unit A can determine the failure is a context based failure. The Unit A can place ctx1 in a failed state. Unit A can communicate with Unit B the change in state of ctx1. Unit B can change the state of its ctx1 to active. After the state change, both contexts on Unit B are active and passing traffic. Failover can be context-based or unit-based. When a failure affects the whole unit, the peer unit can take over by activating any standby contexts and start processing 100% of the traffic.