What i'm unsure about is if there will need to be other config changes needed to transition into a multiple context mode? Since this ASA pair is in production I was hoping for a direct migration to multiple context mode.
Config summary
I have made the transition from single context to multiple context mode several times on running firewall pairs. You are correct that multiple context mode creates the following contexts by default:
- system context
- admin context
After you configure mode multiple
in single-context mode, the running configuration is saved as old_running.cfg
on the flash disk (ref this CCO doc).
Features / Licensing:
If you can't test the exact changes on the same model of ASA ahead of time, the safest thing to do is asking for a maintenance window; feature support changes when you go into multiple context mode.
Also, depending on how many contexts you create, you may run into licensing issues. I had to convert a single layer2 firewall into multiple contexts (per-Vlan firewalls); this meant buying another 10-context license from Cisco because you don't get many licenses by default. Also, vlan mapping was a big issue to work around... ymmv.
Side question: Would it be possible to do this migration in stages on the ASA pair to avoid needing to reboot both at the same time?
Breaking a redundant pair
Yes, but as Ricky said you should just take half the pair down. Disconnect uplinks from the standby, and remove the redundancy config; then, migrate the standby unit first. When the standby comes up in multiple context mode, switch to the system context (changeto system
) and:
- create a new context in system context config mode:
context FOO
- assign a dedicated config location:
config-url disk0:FOO.cfg
- assign interfaces to the context: i.e.
allocate GigabitEthernet0/1
Now changeto context FOO
to start configuring. It is best to be on the console when you migrate. If interface names don't change between single and multiple context mode, you can copy / paste the config directly into the new context... be aware that some things (i.e. ssh timeout settings) go into the admin context and still others in the system context. It's not hard to work out after you get started... context-sensitive ?
help alerts you to which pieces need to be in a given context.
After you have the former standby turned up, you cut services over to it and migrate the former primary. Redundancy still works in multiple context mode, but you must configure the state synchronization link(s) in the system context.