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.