Multiple context mode turns a single Cisco ASA into a hypervisor for several virtual firewalls. Each context has its own configuration, interfaces, ACLs, NAT rules, routing table, and even its own administrators. The classic use cases are service providers (one customer per context), enterprises with strict network segmentation (separate contexts per business unit or per regulatory boundary), and data centers running tenant isolation in hardware. This article covers what multi-context mode is, what it costs, how the system / admin / user-context split works, and the specific configuration you write to enable it. The lab examples are reference-only because switching the live PingLabz ASA Reference Lab to multi-context would destroy the entire single-context running config we built across Sessions 1-3.
This is a Fundamentals article in the Cisco ASA cluster. If you are deciding whether multi-context fits your environment, the punchline is that it usually does not - most enterprises use separate physical firewalls or virtual ASAv instances on a hypervisor instead. Read on for when multi-context is still the right answer.
What Multi-Context Mode Is (and Is Not)
| Yes | No |
|---|---|
| Multiple independent firewalls on one chassis | Multiple Cisco software images running side-by-side |
| Each context with its own admin, config, interfaces | Each context with its own kernel or platform |
| Routed or transparent per-context (your choice) | Mixed firewall-mode in transparent contexts that share an interface |
| Resource quotas via class definitions | Hard isolation between contexts at the hypervisor level |
| Storage of per-context config in flash or off-box | Separate licensing per context (ASA license is per-chassis) |
The mental model: imagine the ASA's data plane as one switching fabric, divided into N virtual firewalls, each with its own forwarding table and policy plane. The hardware is shared; the configuration and the policy are isolated.
The Three Context Types
Every multi-context ASA has three kinds of contexts:
| Type | Role | How many |
|---|---|---|
| System | The execution space that boots the box, defines all other contexts, allocates interfaces and resources. Has no traffic-forwarding policy of its own. | Exactly 1 (built-in) |
| Admin | One user-context designated as the management entry point. Logging in to the box on the management interface lands you in the admin context. | Exactly 1 (you designate) |
| User context | The actual virtual firewalls. Each has its own config, interfaces, policy. | 1 to 250 depending on platform license |
The admin context is also a user context for forwarding purposes - it can have data interfaces, ACLs, NAT, the works - but it is the one you SSH into to manage the box. From the admin context you run changeto context NAME to drop into another user context's CLI for ad-hoc work.
What You Give Up
Multi-context mode does not support every feature single-context does. The list of unsupported features changes per release; check the configuration guide for your target version, but as of recent ASA software:
- Dynamic routing protocols are supported but are licensed per-context (some early releases had it as system-only).
- VPN was historically not supported in multi-context; recent releases support site-to-site VPN per context, but remote-access VPN (AnyConnect) is more limited.
- Threat detection is limited.
- QoS is configured per-context but the underlying queues are platform-wide.
- Multicast routing is not supported (only stub multicast forwarding).
The biggest practical loss for a perimeter firewall is the historic VPN restriction. Confirm against the release notes before committing to multi-context for a VPN-heavy use case.
Enabling Multi-Context Mode (Destructive)
The single command that enables it:
ciscoasa# changeto context system ! (in case you are not in system context)
ciscoasa(config)# mode multiple
WARNING: This command will change the behavior of the device
WARNING: This command will initiate a Reboot
Proceed with change mode? [confirm]
Convert the system configuration? [confirm]
The old running configuration file will be written to flash
The admin context configuration will be written to flash
The new running configuration file was written to flash
Security context mode: multiple
*** --- SHUTDOWN NOW ---
... [reload] ...
Two important notes from that warning. First, the box reloads. Second, the existing single-context config is converted: a slimmed-down system config (defining basic chassis-level stuff) and an admin context that inherits most of the rest. The conversion is best-effort and rarely produces a working multi-context layout straight away; expect to rework the config after the conversion.
The reverse (mode single) is also destructive: every user context is dropped, and the box reloads to single-context mode. Treat the mode change as a one-way commitment for production purposes.
In the System Context: Define Resources and Contexts
The system context is where you define interfaces, allocate them to contexts, and create the contexts themselves.
! From the system context:
ASA-MULTI(config)# admin-context ADMIN-CTX
ASA-MULTI(config)# context ADMIN-CTX
ASA-MULTI(config-ctx)# config-url disk0:/admin-ctx.cfg
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/0
ASA-MULTI(config-ctx)# allocate-interface Management0/0
!
ASA-MULTI(config)# context CUSTOMER-A
ASA-MULTI(config-ctx)# description Tenant A perimeter firewall
ASA-MULTI(config-ctx)# config-url disk0:/customer-a.cfg
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/1
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/2
!
ASA-MULTI(config)# context CUSTOMER-B
ASA-MULTI(config-ctx)# description Tenant B perimeter firewall
ASA-MULTI(config-ctx)# config-url disk0:/customer-b.cfg
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/3
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/4
Walkthrough: admin-context ADMIN-CTX picks which named context plays the admin role. context NAME creates a new context. config-url points at the on-flash file that holds that context's config (or a remote URL like ftp://). allocate-interface hands a physical interface (or a subinterface, or a port-channel) to the context. From this point, the context can use that interface as if it were the only firewall on the box.
Subinterface allocation is also supported, which is the high-density model:
ASA-MULTI(config)# context CUSTOMER-A
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/0.10
ASA-MULTI(config-ctx)# allocate-interface GigabitEthernet0/0.20
Customer A gets two VLAN-tagged subinterfaces on the shared physical Gi0/0; customer B gets two different VLANs on the same physical interface. The chassis runs one trunk to a common upstream switch and the multi-context model isolates each customer at Layer 3.
Shared interfaces (one physical interface allocated to multiple contexts at the same time) are also supported in routed mode but require careful packet-classifier configuration. Stick with non-shared interface allocation unless you have a specific reason and have read the platform-specific multi-context docs.
Inside a User Context
Once the context exists and has interfaces allocated, drop into it and configure as if it were a normal ASA:
ASA-MULTI# changeto context CUSTOMER-A
ASA-MULTI/CUSTOMER-A# configure terminal
ASA-MULTI/CUSTOMER-A(config)# hostname CUSTOMER-A
CUSTOMER-A(config)# interface GigabitEthernet0/1
CUSTOMER-A(config-if)# nameif outside
CUSTOMER-A(config-if)# security-level 0
CUSTOMER-A(config-if)# ip address 198.51.100.10 255.255.255.0
CUSTOMER-A(config-if)# no shutdown
CUSTOMER-A(config)# interface GigabitEthernet0/2
CUSTOMER-A(config-if)# nameif inside
CUSTOMER-A(config-if)# security-level 100
CUSTOMER-A(config-if)# ip address 10.30.0.1 255.255.255.0
CUSTOMER-A(config-if)# no shutdown
CUSTOMER-A(config)# route outside 0.0.0.0 0.0.0.0 198.51.100.1 1
CUSTOMER-A(config)# write memory
Within a user context, every command works the way it does in a single-context ASA. NAT, ACL, VPN (where supported), inspection - everything. The prompt prefix ASA-MULTI/CUSTOMER-A# reminds you which context you are in.
Return to the system context with changeto system.
Resource Classes
Without limits, one rogue context can exhaust the box's conn table or NAT pool. Define resource classes from the system context and assign each user context to one:
! From system:
ASA-MULTI(config)# class GOLD-CLASS
ASA-MULTI(config-class)# limit-resource conns 200000
ASA-MULTI(config-class)# limit-resource xlates 100000
ASA-MULTI(config-class)# limit-resource hosts 50000
ASA-MULTI(config-class)# limit-resource asdm 10
ASA-MULTI(config-class)# limit-resource ssh 10
!
ASA-MULTI(config)# class SILVER-CLASS
ASA-MULTI(config-class)# limit-resource conns 50000
ASA-MULTI(config-class)# limit-resource xlates 25000
ASA-MULTI(config-class)# limit-resource hosts 10000
!
ASA-MULTI(config)# context CUSTOMER-A
ASA-MULTI(config-ctx)# member GOLD-CLASS
ASA-MULTI(config)# context CUSTOMER-B
ASA-MULTI(config-ctx)# member SILVER-CLASS
Each context's traffic is now capped at its class's limits. show resource usage in the system context tells you per-context utilization vs cap.
Reference Show Output
From a Cisco-published multi-context reference:
ASA-MULTI# show context
Context Name Class Interfaces Mode URL
*ADMIN-CTX default GigabitEthernet0/0, Routed disk0:/admin-ctx.cfg
Management0/0
CUSTOMER-A GOLD GigabitEthernet0/1, Routed disk0:/customer-a.cfg
GigabitEthernet0/2
CUSTOMER-B SILVER GigabitEthernet0/3, Routed disk0:/customer-b.cfg
GigabitEthernet0/4
Total active Security Contexts: 3
The asterisk on ADMIN-CTX marks the admin context. Total active contexts is 3 (one admin + two customer); platform license caps would limit this to 2, 5, 20, 50, 100, 250 etc. depending on the chassis tier.
ASA-MULTI# show resource usage context CUSTOMER-A
CPU usage 5 sec, 1 min, 5 min: 12.5%, 13.1%, 13.0%
Used Total %Use Limit Class
Conns 42184 n/a 21% 200000 GOLD
Xlates 18430 n/a 18% 100000 GOLD
Hosts 4221 n/a 8% 50000 GOLD
SSH 2 n/a 20% 10 GOLD
ASDM 1 n/a 10% 10 GOLD
Customer A is using 21% of its conn cap and 18% of its xlate cap. Steady-state utilization in healthy ranges. If "Used" approached the limit, customer A traffic would start getting denied at the resource layer (separate from any policy denial), and you would either bump the class or move customer A to GOLD-PLUS.
Failover Across Contexts
Failover in multi-context mode is configured at the system context and applies across all contexts. The two units must run the same number and shape of contexts; configurations replicate from active to standby per-context. The failover commands themselves (failover lan unit primary, etc.) are system-context-only.
One mode-specific subtlety: active/active failover (where the active role is split per-context, half the contexts run on unit A and the other half on unit B) is only supported in multi-context mode. It is one of the few hard reasons to choose multi-context: when you want to use both physical units actively rather than the active/standby pattern documented in active/standby failover.
When Multi-Context Fits, and When It Does Not
Fits when:
- You are a service provider running tenant isolation in shared hardware.
- You have hard regulatory boundaries (PCI, government tenant separation) and the audit framework wants firewall isolation in addition to logical separation.
- You want active/active failover (each unit actively forwards for some contexts while standing by for others).
- You have a high-density data center with limited rack space and many small firewall responsibilities to consolidate.
Does not fit when:
- You need full RA VPN per business unit (historic limit; check the release notes).
- Your fleet is hybrid with FTD: FTD has a similar feature called Multi-Instance, but it is not the same as ASA multi-context, and migrating between the two is non-trivial.
- You can solve the same problem with separate physical or virtual ASA instances and the operational complexity of multi-context is hard to justify.
For most enterprises, separate ASAv virtual instances on a hypervisor (or separate hardware ASAs in remote sites) win on operational simplicity even at the cost of more boxes.
Key Takeaways
Multi-context mode partitions a single Cisco ASA into multiple virtual firewalls, each with its own configuration, interfaces, and admin scope. The system context defines the contexts and allocates resources; the admin context is the management entry point; user contexts run the actual firewall policy. Switching between single and multi-context is destructive (the box reloads and the existing config is converted on a best-effort basis), so plan a maintenance window and a config rebuild rather than treating it as a config tweak.
Resource classes are mandatory in any production multi-context deployment to prevent one context from starving the others. Active/active failover is one of the few features unique to multi-context. Most enterprises end up using ASAv virtual instances or separate physical units rather than multi-context; multi-context is the right answer for service providers and shared-hardware tenant isolation but rarely for a typical enterprise edge.
Next: Migration Considerations from ASA to Secure Firewall (FTD) covers how to move from ASA software to FTD and what does and does not migrate cleanly. The full reading order is on the Cisco ASA pillar.
