 fails, the standby ASA takes over. If the failed ASA comes back online, it does not automatically resume its role as the active ASA. Cisco's documentation states that there is "no reason to switch active and standby roles" in this circumstance. While I would have preferred a preempt ability similar to that used in HSRP, Cisco didn't invite me to write the failover code. To force a standby ASA to become active, issue the no failover active command on the active ASA, or the failover active command on the standby ASA: ASA-5540# failover active Switching to Active Assuming a successful failover, the primary ASA should now be the active ASA once again. Configuring Failover-Active/Active When you're using active/standby failover with multiple contexts, all contexts are ac- tive on the active ASA. You can think of active/standby failover with multiple contexts like the setup shown in Figure 28-13. Primary ASA Firewall Secondary ASA Firewall Figure 28-13. Active/standby failover with multiple contexts Failover When I first heard the term active/active, I got excited that Cisco had finally incorpo- rated functionality similar to Checkpoint's clustering technology, where multiple phys- ical firewalls can act as a single logical unit, thus distributing the load among them. I was disappointed to learn that this is not the case. As I was performing the final edits for this chapter, representatives at Cisco told me that Cisco is announcing true Checkpoint-esque active/ active failover in an upcoming version of code. Unfortunately, it was not available for me to test before this book went to print. The term active/active, while technically accurate, is a bit of a marketing term. Active/ active mode on a multicontext ASA does not work the way a Checkpoint firewall cluster works. The ASAs are not a cluster, and they do not both forward packets for all contexts. When I hear a term like active/active, I expect all contexts to be active on both firewalls like the setup shown in Figure 28-14. Primary ASA Firewall Secondary ASA Firew