You may find that you have reached the logical limitations of your physical ASA. The hardware is fine, plenty of resources to go around, but the problem is that you need more firewalls. Good news everybody! You can split a physical ASA into virtual contexts. Even with an extra licensing costs, this is cheaper than buying more hardware.

This is called multiple mode. The normal ASA mode is called single mode.

There’s a few reasons that you may consider deploying contexts. One of the biggest these days is to support multi-tenancy in the data centre. Each customer can have their own ASA context, without the need to buy more hardware. Or perhaps you manage a campus with many business units. Each BU has its own administrators, and it’s easier for them to have their own firewalls. This may be better than coordinating across each BU for change management.

And of course, contexts allow granular control of physical resources. Each context shares the physical resources of the ASA. Make sure the ‘important’ contexts get the resources they need with resource policies.

When using contexts, there is one special system context, and one or more normal contexts. The system context, or System Execution Space, is the ‘base’ context. This manages and allocates resources to the other contexts. The system is a bit like a hypervisor in a logical sense, as it is the base platform for the other contexts.

The system ‘owns’ the physical interfaces. They have basic configuration applied, such as etherchannel and VLAN settings. Interfaces are then allocated to one or more contexts. The system does not have any interfaces allocated to itself. This is because does not process traffic itself. The only exception to this is when using failover. In this case, the system uses dedicated interfaces for failover traffic.

When creating a new context, the system creates a new configuration file. The administrator can choose the filename and location. The configuration file can be stored locally, or on a remote FTP server. The system’s running config is visible as normal (with show running-config). This does not show the mode, single or multiple, that the ASA is currently using. To see this, issue the show mode command.

Normal firewall configuration happens in the normal context. In most cases, each context is completely independent of every other context. One exception is the interfaces, which are initially configured in the system. Another is BGP. The BGP AS number must be defined in the system context before a regular context can use it. This means that there is only one ASN for all contexts.

The system does not use data interfaces for itself. This means it is unable to contact any AAA services such as RADIUS or TACACS+. For this reason, there are no AAA commands in the system context. Instead, authentication uses a local database for logins. If you connect to the ASA from the physical console port, you will connect to the system context. From there, you can enter any other context. When entering another context, you will connect as the enable_15 user. This is because the system has full control. If required, you can then change users with the login command. Any context can be accessed directly with telnet, SSH, or the ASDM.

Occasionally, the system does need access to the network. For example, when it does an update, or sending logs to a syslog server. When this happens, it uses a special context called the Admin Context. The admin context is a normal context that can perform special administrative functions. There must be one admin context.

By default, the first context becomes the admin context. This context’s configuration file is admin.cfg, and is on local storage. The admin context config must be on local disk.

If needed, any other context can be the admin context. This may add confusion, as the name of the default context is ‘admin’, but it may not hold the admin role.

Aside from the limitations above, the admin context is just like any other context. An administrator of the admin context has permissions to access any other context. So remember, great power comes with great responsibility.

Contexts can be Cascaded. This is when you place one context in front of another. An example of this is using an edge firewall, in front of an inside firewall. In this case, the inside interface of one context is the outside interface of the next context. It is important that MAC addresses are unique, to process traffic correctly.

There is a limitation of cascading contexts. Currently, there is no support for IPv6 routing across the contexts.

Have you ever used active/active high availability on the ASA? If so, you’ll be aware that you need to enable multiple-context mode. Ever wondered why? When running in active/active mode, each ASA in the pair creates two contexts. One is active and one is passive. If both units are up, each will host one active context, which splits the load across the two. If a unit fails, the remaining one will make it’s passive unit active. Basically, active/active HA is running two active/standby contexts.

Most of the current ASA X-series support multiple contexts. There are two exceptions. The 5506-X does not support multi-contexts at all. The 5512-X does support multiple contexts, but only when using security plus licensing. The ASAv’s do not support multiple contexts, as they are already virtualised.

All other ASA X-series come with a 2-context license. The Firepower appliances, when running the ASA image, come with a 10 context license. Additional licenses can be used to add more contexts. Refer to Cisco’s documentation to see which licenses are supported on each model.

Multi-context mode does have a dark side… There are several features which are unsupported or limited. At the time of writing (v9.6), this includes:

• RIP
• OSPFv3 (OSPFv2 is supported)
• Multicast routing (multicast traffic is fine)
• Threat detection
• Unified communications
• QoS

VPN Remote Access (RA) support with contexts was introduced in v9.5, but with many limitations.

If you intend to use contexts, check the Cisco documentation for your version. See what that version supports, and if there are any limitations.

When a packet arrives at an interface, the ASA classifies it, so it can deliver it to the correct context. An interface may be physical, or a sub-interface based on VLAN.

If the interface is only assigned to one context, this classification is easy. This is often the case when a context is in transparent-mode. An interface can only be assigned to a single transparent-mode context. When using routed-mode, an single interface can be allocated to one or more contexts.

When assigning an interface to more than one context, classification is more tricky. The first attempt at classifying traffic uses the MAC address. This requires a unique MAC address for each interface. The MAC can be manually configured, automatically generated, or left as default. If neither of these options are used, the MAC of the physical interface is used. Auto generation creates the MAC prefix from the last two bytes of the physical interface.

As shown above, sometimes there is no unique MAC address for the interface. In this case, packet classification uses mapped NAT addresses. This is not recommended, as there may be cases where traffic does not get translated. If there’s asymmetric traffic flow, traffic may arrive on the wrong interface.

Traffic classification happens before the main packet flow. That is, the ASA classifies a packet before it checks if it is part of an existing connection.

When a multicast frame arrives at an interface, the ASA duplicates it and sends it to each context. For management traffic, classification uses the interface’s IP address. The routing table is not used for packet classification.

In the default configuration, all contexts have unlimited access to system resources. This can be changes by creating Resource Classes. A resource class defines how much of specific system resources a context can have.

There is a default class. By default, it will allow unlimited access to all resources except for VPN. To allow VPN access, define a new class, or edit the default class. A context may have only one class assigned to it. If a particular limit is not set in a class, it will inherit the value from the default class.

Limits may be set based on a percentage of the system limit, or absolute values may be set. Over-subscription is allowed. For example, a class may allow 20% of a particular resource. That class may be assigned to six contexts. The result is the allocation of 120% of that resource.