Chapter 22: Contexts

This chapter will introduce you to the concept of contexts and the advantages they give you in deploying a wide diversity of security policies. The topics in this chapter include

• Introducing contexts, including their uses and components

• Switching to multiple mode and setting up contexts

• Managing your contexts

Context Overview

A context is basically a virtual firewall; however, contexts are not the same as VMware—with VMware, you can have multiple operating systems running on the same computer. With contexts, each context uses the same operating system and ASDM image. However, each context can have its own security policies and its own set of administrators to manage the context. The following sections will introduce the licensing, use, restrictions, and implementation of contexts.

Licensing

Not every security appliance supports contexts. The PIX 515 and higher and the ASA 5510 and higher support contexts. And for the appliances that do support contexts, you get two contexts for free by default; if you want more contexts, you’ll have to buy the appropriate license. There are four license levels for purchasing security contexts—5, 10, 20, and 50—as well as upgrade licenses to upgrade from one number to another.

With the 5510, you need the Security Plus license to use contexts, and the 5510 supports a maximum of five contexts. The 5520 supports a maximum of 20 contexts, and the higher-end ASAs support up to 50 contexts. The PIX 515 and 515E support up to 5 contexts, and the 525 and 535 support up to 50 contexts. I discuss how to upgrade the license key on the appliances in Chapter 26.

Context Uses

Contexts can be used for a variety of situations; however, I’ve seen them most commonly used in these three:

• Active/active failover

• ISP and co-location/hosting companies that host services requiring firewall functions

• Companies needing more than one firewall in the same physical location

Failover and Contexts

Failover is a Cisco-proprietary feature that allows two appliances to provide firewall redundancy for connections flowing through them. In active/standby failover, only one appliance can forward traffic at a time. In active/active failover, both appliances can simultaneously forward traffic, allowing you to implement load balancing. Active/active failover requires the use of contexts: one context for each logical flow of traffic. Failover is discussed in Chapter 23.

ISPs and Contexts

Many ISPs and hosting or co-location companies host services for companies, and one of the options they can provide and/or sell their customers is firewall services. Prior to contexts, a provider would have to purchase many firewalls to implement the policies for the companies it was hosting services for. With contexts, you can purchase one firewall and configure up to 50 contexts—50 virtual firewalls, where a virtual firewall would handle traffic for a single company! This is a much more cost-effective approach compared with purchasing a physical firewall per hosted company—this is especially true in co-location/hosting companies, where your billing is based on rack space, power consumption, heat output, and bandwidth utilization.

Companies and Contexts

Contexts can even be used within a company infrastructure. Imagine you have two departments in one building, where each department wants its own firewall because of security issues. You could purchase two firewalls, but a more economical approach would be to buy one appliance and set up two contexts, where each department could only access and manage its respective context and its security policies.

Context Restrictions

Even though contexts allow you to create more firewalls on your appliance, they do have their downside: not all appliance features are supported when using contexts. Here is a list of features unsupported on the appliances when you’ve implemented contexts on them:

• Dynamic routing protocols (unicast and multicast) are unsupported: you must use static routes.

• No VPN type—IPSec, L2TP, or WebVPN—is supported.

• Threat detection is unsupported.

Other than these restrictions, all other appliance features are supported. For example, if you had the need, you could set up one context to run in routed mode and another in transparent mode; you could set up address translation in one context, and use a different address translation policy in a second context; you could have the IPS card for the ASAs process traffic for two contexts, but not a third context; you could have different filtering and inspection policies for the different contexts; and I could go on and on with the flexibility of implementing policies with contexts.

Context Implementation

By default when you receive your appliance from Cisco and boot it up, the appliance is running in single mode. In single mode, the appliance acts as a stand-alone firewall. To use contexts (assuming you have the appropriate licensing on the appliance), you have to switch to multiple mode. As you will see later in the “Switching to Multiple Mode” section, you have the option of importing the appliance stand-alone (single mode) configuration into a context.

System Area

When you boot up in multiple mode from the CLI, you are taken into the system area. The system area is used to configure the physical properties of the interfaces, create VLANs for trunking, create resource classes to restrict the context system resource usage, and initially to create the contexts themselves. You can also password-protect the system area to restrict access to it, as well as other administrative functions. In other words, the system area is where you configure system resources that affect the security appliance as a whole; however, the individual security policies are configured within the contexts themselves. The system area doesn’t count as a context itself and thus doesn’t affect your licensing.

Context Properties

A context must have a name, interfaces allocated to it, and a configuration file to store the security policies and configurations of the actual context itself. One context must be denoted as the administrative context. This context is used by the system area to communicate with external devices, like an FTP server, to back up the system area configuration file, to upgrade the appliance operating system or ASDM image, or to send syslog messages associated with the system area to a syslog server. Other than this special function, the administrative context can be used for normal data functions. When the appliance boots up, it automatically creates one context, called the admin context, which defaults to being the administrative context. Any context can be the administrative context; so if you don’t like the name “admin” for the context, you can delete it and create a context with a different name that will perform the administrative context functions. However, one of the contexts on your appliance must be the administrative context.

Note

By default an administrator who has access to the administrative context can switch to the system area unless you restrict this. However, non-administrative contexts do not have access to the system area.

Context Chaining

The appliances support chaining, sometimes referred to as cascading, of contexts. With chaining, one context is logically connected to another, where a packet can come in one physical interface to one context, where policies are applied to the packet, and then forwarded to a second (or more) context for more policies to be applied, before the packet physically leaves the appliance.

Figure 22-1 illustrates chaining. In this figure, the Internet context has two interfaces associated with it: G0/0 is connected to the Internet, and G0/1.10 is in VLAN 10. The Admin context has two interfaces: G0/1.10 is in VLAN 10, and G0/1.20 is in VLAN 20. The CTX1 context has two interfaces: G0/1.10 is in VLAN 10, and G0/1.30 is in VLAN 30. Notice that all three contexts share the same logical interface, which interconnects them.

Figure 22-1: Context chaining

Note

When chaining contexts, a VLAN interface must be shared among the contexts. Basically you’re creating the illusion that a logical segment is interconnecting the contexts. Given this, even though the same interface is being shared, each context will have to have a different MAC address for that interface, making it appear that the shared interface really appears as multiple, logical interfaces to each context that is chained. I highly recommend for security purposes that if the shared interface is physically connected to a switch, you do not place any other device in this VLAN.

Traffic Classification

One of the features of contexts, as you saw in the last section, is that multiple contexts can share the same interface—physical or VLAN subinterfaces. If you don’t share interfaces across contexts, then it is very easy for the appliance to classify what context should handle an inbound packet, since only one context is associated with the respective interface.

Note

A packet entering an interface without a context associated with it will be dropped.

If you are sharing a physical or VLAN subinterface between two or more contexts, however, the appliance must somehow determine which context should process an inbound packet on the shared interface. When determining what context should process an inbound packet on a shared interface, the appliance can look at the destination MAC address in the Ethernet frame and/or the translation rules and translation entries in the xlate table. When using MAC addresses to determine what context should handle an inbound packet, each context will have to use a different MAC address for the shared interface. As you will see later in the “Creating Contexts” section, you can have the appliance automatically create unique MAC addresses for the interfaces, or you can manually do this by going into the context itself and changing the MAC address for the shared interface. Translation rules are used when the MAC addresses are duplicated across contexts. I recommend, even if you are using translation rules, that you ensure the shared interfaces have unique MAC addresses, though. The one translation policy the appliance cannot use for context matching a packet is the nat 0 commands, since they only specify the source, and not the destination, interface involved.

Note

You might assume that if each context has unique IP addressing, the appliance would use the routing table to match up a packet to the correct context; however, this is not the case. Only MAC addresses and translation rules are used to match a packet to a context when interfaces are shared.

Context Mode

This section will cover how to implement contexts on your appliance: switching from single to multiple mode, creating contexts, and restricting resources the contexts can use.

Switching to Multiple Mode

The mode multiple command is used to switch from single to multiple mode. Here’s an example of the use of this command:

ciscoasa# 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 disk0
The admin context configuration will be written to disk0
The new running configuration file was written to disk0
Security context mode: multiple
<--output omitted-->

To switch to multiple mode, the appliance will have to reboot itself. This process is one of the few instances where your current configuration is automatically backed up to flash in case you don’t like contexts and want to switch back to single mode. The file is called “old_running.cfg.” You also have the option of importing your existing configuration into the automatically created admin context; if you don’t choose the import option, the appliance will reset itself to the factory defaults once it boots up. Upon rebooting, the appliance takes you into the system area automatically.

In the system area, use the show mode command to verify the mode in which your appliance is running. Here’s an example:

ciscoasa# show mode
Security context mode: multiple

Note

To switch back to single mode, use the mode single command in the system area.

System Area Configuration

Upon rebooting from single to multiple mode, you are taken into the system area if you happen to be using the console. The system area is primarily used to manage the appliance itself, whereas contexts are used to move traffic through the appliance. From the system area you can perform the following tasks:

• Control management access to the system area.

• Assign physical properties to interfaces.

• Create logical VLAN subinterfaces.

• Set up active/active failover.

• Create and manage contexts.

• Upgrade the OS and ASDM images.

• Create resource classes to limit the resources a context(s) uses.

When you’re in the system area, there is no method of moving traffic between interfaces that are not associated with a context(s); to move traffic between interfaces, the interfaces must be associated with a context(s). Likewise, you can’t set up policies for traffic; again, this is done within the contexts themselves, like setting up ACLs, translation policies, Module Policy Framework (MPF) policies, and so on.

Designating the Administrative Context

By default the appliance automatically creates a context, called admin, when switching to multiple mode. This context is designated as the administrative context. As I mentioned earlier, the administrative context is the context the system area uses when it needs to communicate with devices beyond the appliance. If you delete the admin context, you’ll need to denote another context to perform this role. To designate a context as the administrative context, use the admin-context command:

ciscoasa(config)# admin-context context_name

Only one context can be the administrative context.

Creating Contexts

The following sections will discuss how you initially create your contexts so that you can set up security policies and move traffic through them.

MAC Addresses and Contexts

If you recall from the “Traffic Classification” section, when an interface is shared among multiple contexts, destination MAC addresses and translation rules are used to determine which context a packet should be processed by. Therefore, when an interface is shared, each context should use a different MAC address for the shared interface.

You can automatically have the appliance generate unique MAC addresses for an interface that is shared across multiple contexts with the mac-address auto command.

ciscoasa(config)# mac-address auto

This command is executed from the system area.

Note

You can also go into a context and associate a MAC address to the interface, but the mac-address auto command is the recommended approach to ensuring that shared interfaces have unique MAC addresses across the respective contexts.

Context Creation

To create a context, you must give it a name, allocate at least one interface, and specify where the configuration file for the context is stored. Here are the commands to accomplish these tasks:

ciscoasa(config)# context context_name
ciscoasa(confix-ctx)# allocate-interface physical_if_name[.subif]
                       [map_name] [visible | invisible]
ciscoasa(config-ctx)# config-url URL

Each context must have a unique name, which is case-sensitive. The names “null” and “system” are reserved and cannot be used. When you execute the context command, you are taken into a subcommand mode where you can set up the context’s initial properties.

The allocate-interface command associates an interface to a context (when in the context, you can see only the interfaces allocated to it). You can assign physical as well as VLAN subinterfaces to a context. VLAN subinterfaces must first be created in the system area before you can assign them to a context. The map_name parameter allows you to assign a different name that will appear in the context instead of the actual physical name. The visible parameter allows an administrator to see both the physical and mapped interface names within a context; however the invisible parameter only allows the administrator to see the mapped interface names. Basically the latter parameter allows you to hide the name of the physical interface for security purposes.

Each context has its own configuration file. The config-url command specifies the location and name of the configuration file. Locations you can specify include disk0 (flash), disk1, tftp, ftp, and https. The last can only be read from, not written to. Whenever you’re in a context and execute the write mem command, the context configuration is stored in the specified location.

Tip

If the configuration file is located on an external server and the appliance boots up and can’t reach the external server, the context configuration will not be loaded, and thus the context will fail. Therefore, I recommend that a context configuration file be placed in flash on the appliance itself (flash on the motherboard or, for the ASA, on the additional compact flash card).

Once you’ve performed the preceding configuration steps, the context is active—you can switch to the context and set up its security policies.

Here’s a simple example of setting up contexts:

ciscoasa(config)# interface ethernet0/1
ciscoasa(config-subif)# no shutdown
ciscoasa(config)# interface ethernet0/1.10
ciscoasa(config-subif)# vlan 10
ciscoasa(config)# interface ethernet0/1.20
ciscoasa(config-subif)# vlan 20
ciscoasa(config)# context CTX1
Creating context 'CTX1'... Done. (4)
ciscoasa(config-ctx)# allocate-interface ethernet0/1.10 inter1
ciscoasa(config-ctx)# allocate-interface ethernet0/1.20 inter2
ciscoasa(config-ctx)# config-url disk0:/CTX1.cfg

In this example, the e0/1 interface is activated, and two VLANs are associated with the physical interface in the system area. A context, called “CTX1,” is created that includes these two interfaces (with mapped names), and the configuration file for the context is located in the appliance flash memory.

Context Verification

Use the show context command to verify your context configuration in the system area:

ciscoasa# show context [name | detail | count]

Here’s an example of the use of this command:

ciscoasa# show context
Context Name   Interfaces         URL
*admin         Ethernet0/0        disk0:/admin.cfg
              Ethernet0/1
CTX1           Ethernet0/2        disk0:/CTX1.cfg
              Ethernet0/3
Total active Security Contexts: 2

An “*” beside a context name indicates that the context is the administrative context. In the preceding example, this is the admin context.

Managing Resources

One of the initial issues with contexts when they were introduced in version 7.0 was that you couldn’t place any resource restrictions on them; therefore, one context and its behavior could easily affect the other contexts on the appliance. For example, a TCP SYN flood attack occurring in one context could fill up the conn table and adversely affect connections attempting to be built in other contexts.

Supported Resource Limits

Starting in version 7.2, you can define resource limits for a context, ensuring that one context doesn’t create resource conflicts for other contexts. Resource limits you can define include the number of

• Management connections: ASDM, telnet, and SSH

• Hosts

• MAC addresses

• Xlates in the translation table

• Connections in the state table

• Syslog messages/second

• Application inspections/second

All resources are set to unlimited for a context, unless overridden, except for the following limits, which are by default set to the maximum allowed per context:

• Telnet sessions: Five sessions

• SSH sessions: Five sessions

• IPSec sessions: Five sessions

• MAC addresses: 65,535 entries

Defining Resource Limits

Resource limits are defined in a resource class. All contexts get their resource restriction from a default class called default, by default. You can override this behavior by creating a resource class and associating it to a specific context. This is accomplished with the following configuration:

ciscoasa(config)# class {default | resource_class_name}
ciscoasa(config-class)# limit-resource all 0
ciscoasa(config-class)# limit-resource asdm #_of_sessions
ciscoasa(config-class)# limit-resource ssh #_of_sessions
ciscoasa(config-class)# limit-resource telnet #_of_sessions
ciscoasa(config-class)# limit-resource hosts #_of_hosts
ciscoasa(config-class)# limit-resource mac-addresses #_of_addresses
ciscoasa(config-class)# limit-resource rate
                            inspect #_of_inspects/second
ciscoasa(config-class)# limit-resource [rate] conns {#_of_conns | xx%}
ciscoasa(config-class)# limit-resource rate syslogs #_of_logs/second
ciscoasa(config-class)# limit-resource xlates #_of_xlates | xx%}

For some resource limits, you can specify a percentage (%), such as 20% for the number of entries in the state table, like this: limit-resource conns 20%.

To associate a resource class to a context, from the system area, enter the context configuration and use the member command, like this:

ciscoasa(config)# context context_name
ciscoasa(config-ctx)# member resource_class_name

Here’s a simple example that illustrates the configuration of a resource class and associates it with the CTX1 context:

ciscoasa(config)# class resource-CTX1
ciscoasa(config-class)# limit-resource asdm 3
ciscoasa(config-class)# limit-resource ssh 3
ciscoasa(config-class)# limit-resource conns 50%
ciscoasa(config)# context CTX1
ciscoasa(config-ctx)# member resource-CTX1

In this example, no more than three ASDM and three SSH management sessions are allowed, and users sending traffic through the CTX1 context cannot use more than 50 percent of the entries in the state table.

Viewing Context Resource Allocations

You can see what resources have been allocated to a context by using the show resource allocation command:

ciscoasa# show resource allocation [detail]

Here’s a simple example of the use of this command:

ciscoasa# show resource allocation
Resource          Total      % of Avail
Conns [rate]      35000       N/A
Inspects [rate]   35000       N/A
Syslogs [rate]    10500       N/A
Conns             305000      30.50%
Hosts             78842       N/A
SSH               35          35.00%
Telnet            35          35.00%
<--output omitted-->

You can also see what resources are being used by a context(s) with the show resource usage command:

ciscoasa# show resource usage [context context_name | top n | all |
             summary | system | detail] [resource {[rate]
             resource_name | all}] [counter counter_name
             cnt_threshold]]

Here’s an example of the use of this command with the summary parameter:

ciscoasa# show resource usage summary
Resource       Current    Peak     Limit    Denied    Context
Syslogs [rate]    1743    2132   12000(U)        0    Summary
Conns              584     763  100000(S)        0    Summary
Xlates            8526    8966     93400         0    Summary
Host               254     254    262144         0    Summary
Conns [rate]       270     535     42200      1704    Summary
Inspects [rate]    270     535  100000(S)        0    Summary
U = Some contexts are unlimited and are not included in the total.
S = System: Combined context limits exceed the system limit;
the system limit is shown.

Here’s an example of the use of this command for examining the admin context resource usage:

ciscoasa# show resource usage context admin
Resource    Current     Peak  Limit     Denied      Context
Telnet            1        1      5          0      admin
Conns            44       55    N/A          0      admin
Hosts            45       56    N/A          0      admin

Context Example

To help you understand how to switch to multiple mode, create the contexts, and configure the contexts, let’s look at an example. I’ll use the network shown in Figure 22-2 to illustrate the configuration. The appliance is a 5510. E0/0 and E0/1 are trunk connections, where I’ve created two VLANs on each of these physical interfaces.

Figure 22-2: Context example

Example—Changing to Multiple Mode

To make it easier to understand the configuration, I’ll break it into sections. Currently the ASA 5510 is in single mode, so the first thing I’ll do is switch it to multiple mode:

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] N
Security context mode: multiple
<--output omitted-->
ciscoasa# show mode
Security context mode: multiple

Notice that I’m not importing the single mode configuration to the admin context in multiple mode; once the appliance has booted up, I’ve verified that it is running in multiple mode.

Example—Setting Up the Interfaces

From the system area, I then set up the interfaces:

ciscoasa(config)# interface e0/0
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# exit
ciscoasa(config)# interface e0/1
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# exit
ciscoasa(config)# interface e0/0.1
ciscoasa(config-subif)# vlan 311
ciscoasa(config-subif)# exit
ciscoasa(config)# interface e0/0.2
ciscoasa(config-subif)# vlan 312
ciscoasa(config-subif)# exit
ciscoasa(config)# interface e0/1.1
ciscoasa(config-subif)# vlan 101
ciscoasa(config-subif)# exit
ciscoasa(config)# interface e0/1.2
ciscoasa(config-subif)# vlan 102
ciscoasa(config-subif)# exit

I enabled the two physical interfaces that I’m using—e0/0 and e0/1—and I’ve created my subinterfaces for the four VLANs. VLAN 311 and 101 will be placed in one context, and 312 and 102 in a second context.

Example—Creating the Contexts

I’ll now create and set up my two contexts (“admin” and “ctx”):

ciscoasa(config)# admin-context admin
Creating context 'admin'... Done. (1)
ciscoasa(config)# context admin
ciscoasa(config-ctx)# allocate-interface e0/0.1
ciscoasa(config-ctx)# allocate-interface e0/1.1
ciscoasa(config-ctx)# config-url flash:/admin.cfg
WARNING: Could not fetch the URL flash:/admin.cfg
INFO: Creating context with default config
INFO: Admin context will take some time to come up .... please wait.
ciscoasa(config-ctx)# exit
ciscoasa(config)# context ctx
Creating context 'ctx'... Done. (2)
ciscoasa(config-ctx)# allocate-interface e0/0.2
ciscoasa(config-ctx)# allocate-interface e0/1.2
ciscoasa(config-ctx)# config-url flash:/ctx.cfg
WARNING: Could not fetch the URL flash:/ctx.cfg
INFO: Creating context with default config
ciscoasa(config-ctx)# exit
ciscoasa(config)# show context
Context Name Class       Interfaces           URL
*admin        default    Ethernet0/0.1,Ethernet0/1.1 flash:/admin.cfg
ctx          default    Ethernet0/0.2,Ethernet0/1.2 flash:/ctx.cfg
Total active Security Contexts: 2

Notice that I allocated my VLAN subinterfaces to the respective contexts as well as specified the location of the configuration files for the contexts.

Example—Configuring the Admin Context

Now I’ll set up the configuration and policies for the admin context:

ciscoasa(config)# changeto context admin
ciscoasa/admin(config)#
ciscoasa/admin(config)# interface e0/0.1
ciscoasa/admin(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa/admin(config-if)# security-level 0
ciscoasa/admin(config-if)# ip address 192.168.11.1 255.255.255.0
ciscoasa/admin(config-if)# no shutdown
ciscoasa/admin(config-if)# exit
ciscoasa/admin(config)# interface e0/1.1
ciscoasa/admin(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
ciscoasa/admin(config-if)# security-level 100
ciscoasa/admin(config-if)# ip address 10.0.1.111 255.255.255.0
ciscoasa/admin(config-if)# no shutdown
ciscoasa/admin(config-if)# exit
ciscoasa/admin(config)# route outside 0.0.0.0 0.0.0.0 192.168.11.254
ciscoasa/admin(config)# nat-control
ciscoasa/admin(config)# nat (inside) 1 0.0.0.0 0.0.0.0
ciscoasa/admin(config)# global (outside) 1 interface
INFO: outside interface address added to PAT pool
ciscoasa/admin(config)# access-list ACLoutside permit icmp any any
ciscoasa/admin(config)# access-list ACLoutside deny ip any an
ciscoasa/admin(config)# access-group ACLoutside in interface outside

Notice that when I executed the changeto command, the prompt changed to include the name of the context. (This is what the hostname command defaults to within the context.) I’ve set up a real simple configuration: configuring the interfaces with IP addresses, logical names, and security levels, defining a static route, setting up a PAT translation policy for outbound traffic, and allowing ICMP traffic to flow inbound.

Example—Configuring the ctx Context

Next I’ll switch to the ctx context and set it up:

ciscoasa/admin(config)# changeto context ctx
ciscoasa/ctx(config)#
ciscoasa/ctx(config)# interface e0/0.2
ciscoasa/ctx(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa/ctx(config-if)# security-level 0
ciscoasa/ctx(config-if)# ip address 192.168.12.1 255.255.255.0
ciscoasa/ctx(config-if)# no shutdown
ciscoasa/ctx(config-if)# exit
ciscoasa/ctx(config-if)# interface e0/1.2
ciscoasa/ctx(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
ciscoasa/ctx(config-if)# security-level 100
ciscoasa/ctx(config-if)# ip address 10.0.2.111 255.255.255.0
ciscoasa/ctx(config-if)# no shutdown
ciscoasa/ctx(config-if)# exit
ciscoasa/ctx(config)# route outside 0.0.0.0 0.0.0.0 192.168.12.254
ciscoasa/ctx(config)# nat-control
ciscoasa/ctx(config)# nat (inside) 1 0.0.0.0 0.0.0.0
ciscoasa/ctx(config)# global (outside) 1 interface
INFO: outside interface address added to PAT pool
ciscoasa/ctx(config)# access-list ACLoutside permit icmp any any
ciscoasa/ctx(config)# access-list ACLoutside deny ip any any
ciscoasa/ctx(config)# access-group ACLoutside in interface outside

This configuration is similar to the admin context configuration.

Example—Saving the Appliance Configuration

Last, I’ll switch to the system area and save the configuration of everything on the appliance:

ciscoasa/ctx(config)# changeto system
ciscoasa(config)#
ciscoasa(config)# write memory all
Building configuration...
Saving context :           system : (000/002 Contexts saved)
Cryptochecksum: 470df27f 7c312655 ba32399a fe96cb77
996 bytes copied in 0.820 secs
Saving context :            admin : (001/002 Contexts saved)
Cryptochecksum: 83a9938b ec06cf12 7d579f12 e7808459
1350 bytes copied in 0.840 secs
Saving context :              ctx : (002/002 Contexts saved)
Cryptochecksum: 0dac15dc 927b7011 a126adc6 00d45ab4
1348 bytes copied in 0.860 secs
[OK]

Note

Because no interfaces were shared between contexts, the MAC addresses on the subinterfaces could be the same or different; however, if an interface were shared between contexts, make sure you execute the mac-address auto command in the appliance system area.