Cisco ASA Failover – How to Manage Cisco ASA Context in Active/Active Failover

A reload is only required when changing encryption features or downgrading a permanent license. You shouldn't have to break your failover pair either. For a failover pair running >8.3(1), you only need a context license on the primary, and the secondary will inherit. Context licenses applied to both units in a failover pair will combine.

DISCLAIMER: This is a really bad idea. The ASA platform is designed to be one system, with hardware redundancy. Therefore, you should ensure that the config always stays in sync, which ensures that the state tables always stay in sync, which ensures that everything works the way it is intended to.

But for the sake of education, you could do something foolish. This would likely not be supported by TAC. Technically, you can modify the config on the standby unit, then do a failover to it. When a failover occurs, the newly-active unit does not bulk sync its config or its state to the formerly-active unit. (Meaning, it does not suddenly bring the formerly-active unit up to date.) It does, however, sync updates if you modify something while running on the newly-active unit. The changes you made while standby are not synced, but the changes you make while primary are synced.

Moving on, if you like the result of the failover, then you can do a no failover and failover on the formerly-active unit (or do a write standby on the newly-active), which will then trigger a bulk sync and bring its config completely up to date. Alternatively, if you were not happy with the result of the failover, then you could fail back to the formerly-active unit, where the previous config was still running. Then, of course, you should do a no failover and failover on the unit that you messed up to bring its config back into line with the way it used to be.

Having said all this, I'm betting there are good many situations where you could cause some bad things to happen. Modifying interfaces, I bet is one scenario--if the two have different interfaces and are sending state updates to one another, something could cause some corruption, or a crash.

So, this is meant to teach you how failover works, not to teach you how to rig something up with bubble gum and duct tape. You should always make changes on the active unit. If you aren't comfortable because you can't fail back, then find someone who can help you create a backout plan, or find someone who has the skill to get you successfully through the changes you need to make.