• Basic Device Settings: This section describes configuration of basic device settings, such as hostname, domain, enable password, and Telnet password.
• Name-to-Address Mappings: This section describes configuration of local name-to-address mappings, as well as configuring a DNS server group.
• File System Management: This section describes how to manage the file system in flash memory on an ASA, including where the ASA keeps its configuration, system software, and auxiliary files.
• Managing Software and Feature Activation: This section describes how to manage the activation of features within the operating system of the ASA, and also changing the activation key of the security appliance.
• Remote Device Management: This section describes how to configure the ASA for remote management, using Telnet, Secure Shell (SSH), dedicated out-of-band interface, or HTTPS using ASDM.
• Controlling Management Access with AAA: This section describes how to configure the ASA to perform Authentication, Authorization, and Accounting, using the local database.
--------------------------------------------------------------------------------------------------------------
Chapter 4: Firewall Management
Overview
Refer to the following sections for information about these topics:
- 4-1: Using Security Contexts to Make Virtual Firewalls— Presents the configuration steps needed to make one physical firewall platform emulate multiple virtual firewalls.
- 4-2: Managing the Flash File System— Explains the types of images that are stored in nonvolatile firewall memory and how to work with them.
- 4-3: Managing Configuration Files— Presents the methods you can use to configure firewalls and manage their configuration files.
- 4-4: Automatic Updates with an Auto Update Server— Discusses a way to leverage a central server to update image and configuration files on multiple firewalls automatically.
- 4-5: Managing Administrative Sessions— Presents the configuration steps necessary to permit administrative users to access a firewall for configuration, monitoring, or troubleshooting.
- 4-6: Firewall Reloads and Crashes— Discusses how to perform a controlled firewall reload or reboot. After an unexpected firewall crash, you can also examine “post mortem” information about the cause of the crash.
- 4-7: Monitoring a Firewall with SNMP— Explains Simple Network Management Protocol (SNMP) and how it can be used to obtain system information from a firewall.
Any firewall that is deployed in a network must also be managed. Firewall administrators need to be able to make configuration changes, define virtual firewall contexts for other entities, maintain the firewall operating system and configuration files, and monitor firewall operation.
This chapter presents the configuration steps and background information you need to perform these management functions.
4-1: Using Security Contexts to Make Virtual Firewalls
On Adaptive Security Applianace (ASA) and Firewall Services Module (FWSM) platforms, you can configure one physical firewall chassis to act as multiple virtual firewalls. Each virtual firewall is called a context because it is one partition or instance of a fully functional firewall.
Even though all the configured contexts are emulated by a single firewall CPU, the traffic inspection and security policies of each are kept separate, as if they were being handled by a dedicated physical firewall. Therefore, each context can be configured and managed by different administrators, or they can all be managed by one administrator who has access to them.
Traditionally, one physical firewall would be added to a network every time a new firewall function was needed. The cost of adding firewalls in this way is incremental. The ability to run multiple security contexts on a single firewall provides a way to limit the cost of firewall hardware. Firewall contexts can be added according to license limits. This capability does come with a trade-off, however, because all contexts must share the resources available on the hardware platform.
Security contexts can be useful in both service provider and enterprise environments. A service provider can partition one physical firewall into multiple security contexts that can be assigned to customers for a recurring cost. Each customer can configure and manage his or her respective context.
In an enterprise setting, multiple contexts could be assigned to individual departments or organizations where there is no overlap in security policies. Each department would operate its own firewall context independently of others. On the “public” side of each firewall, each context could connect to a shared or common Internet feed.
Security Context Organization
A Cisco firewall that can support security contexts can operate in only one of the following modes:
- Single-context security mode— One context is configured on one physical firewall platform. This is the traditional or default mode of operation.
- Multiple-context security mode— Two or more contexts can be configured on one physical firewall.
In multiple-context security mode, a firewall is organized into the following functions, each having its own user interface:
- System execution space— A special area where individual contexts are defined and physical firewall resources are mapped to them. Because the system execution space does not use security policies and cannot provide network connectivity, it cannot really function as a true firewall context.
- Administrative context— A fully functional virtual firewall that is used mainly to manage the physical firewall. You can configure security policies, network addressing and routing, and any other firewall function needed for administrative use. This context operates independently of any other context.
- User contexts— Fully functional virtual firewalls that can be configured and handed over to a third party if needed. Each user context can have its own security policies, network addressing, access control, and so on. Almost anything that can be configured on a single-firewall platform can be configured on a user context.
Figure 4-1 shows how a single physical firewall can be organized to provide multiple security contexts. Each context has its own set of virtual firewall interfaces that are mapped from the physical or VLAN firewall interfaces.
In practice, the physical firewall platform might not have enough interfaces to be able to map them one-to-one with context interfaces. In Figure 4-1, the firewall would need two unique physical interfaces for each context! Even if there were enough interfaces to go around, you might not want to use all of them in the first place when only a few could provide the necessary connectivity.
Sharing Context Interfaces
Multiple-context mode allows some flexibility in mapping interfaces. You can map one physical interface to one context interface when isolation from other firewalls is required.
You can also map one physical interface to several context interfaces so that the contexts share a single connection. This might be practical in an enterprise setting, where each context is designated for a different department. Most likely, an enterprise would have a single path toward the public Internet. Every department would share that path, provided by one physical firewall interface. As that interface is mapped to each context, the resulting logical or mapped interface would become the context’s outside interface. Figure 4-2 illustrates this concept.
Physical interfaces can be shared in any configuration. For example, if two firewall contexts need to provide access to some authentication servers that they share, one physical interface could be mapped to those two contexts and no others.
Finally, consider that all contexts are really emulated by one firewall platform. As packets enter a physical firewall interface, the firewall CPU must determine which context is the true destination.
If one physical interface is mapped to one context interface, the firewall CPU simply takes packets arriving on that interface and puts them in the queue for that context interface. The mapped context must be the virtual firewall that will inspect and handle the inbound traffic.
Suppose one physical interface is mapped to interfaces in several contexts. Now when packets arrive on that interface, the firewall CPU must decide which of the mapped contexts is the correct destination firewall.
A firewall running in multiple-context mode uses a classifier function to sort out which context should actually process each inbound packet. In effect, a classifier is positioned at each firewall interface to decide which context should receive packets as they arrive. Figure 4-3 illustrates this concept.
The classifier is simple; if it can find a unique source interface or destination address, it has enough information to hand off a packet to a context. The classifiers shown at the bottom of Figure 4-3 have an easy job because their source interfaces are mapped to a single unique context. Packets arriving on the inside interfaces are passed directly to the respective context inside interfaces to begin the normal firewall stateful inspection process.
However, if firewall interfaces are shared between contexts, as in the topmost interface shown in Figure 4-3, the problem becomes a bit more difficult. The classifier at the top of the figure is faced with the task of finding a unique destination context for each inbound packet.
A classifier does this by attempting to find the packet destination address defined in one of the connected contexts. The destination address must be uniquely identified in one of the following ways:
- A global address defined in a static NAT entry
- A global address used in an xlate entry
- A firewall interface address (used when packets are destined for the firewall itself)
A classifier also works in only one direction. Each packet that arrives on a shared interface is examined so that it can be sent to a specific context. Because of this, you should work through scenarios with a connection originating on each side of the firewall to make sure that the classifier process will work properly. The classifier must find the destination address as a global address entry in one (and only one) of the security contexts.
For example, Figure 4-4 shows a simple arrangement in which two security contexts are configured to share their outside interfaces toward the public network. The left side of the figure shows what happens when a connection is initiated from inside host 192.168.1.100 to outside host 198.133.219.25. Because the inside context interfaces are not shared, the classifier nearest to the inside host can simply send the packets to Context A, where the host is connected. At Context A, the inside address is translated to global address 207.246.96.47, because of a static NAT configuration.
For the return traffic from the outside host, the classifier examines arriving packets on the shared outside interfaces. The destination address is 207.246.96.47, which is found as a global address in the xlate table on Context A. Therefore, traffic originating on the inside network can make the round trip successfully.
On the right side of Figure 4-4, a connection originates from the outside host, located on the shared interfaces. Here, the destination address 207.246.96.47 is again found as a global address in a static NAT xlate entry on Context A. This traffic too can make the round trip.
What if a dynamic NAT or PAT were used instead of a static NAT? In that case, the dynamic NAT would be configured to use one or more global addresses during translation. In Figure 4-4, the global address is 207.246.96.46, which could be found in xlate entries for connections passing through Context A. The classifiers on either side of the firewall would have no problem finding the global address on Context A.
Issues with Sharing Context Interfaces
If you decide to share the inside context interfaces, you should be aware of a classifier limitation. Consider the arrangement shown in Figure 4-5, where Contexts A and B share their inside interfaces.
The classifier must examine packets entering from the inside networks to decide which context should receive them. A search is made to find the packet destination addresses in the context xlate tables. In particular, the classifier can find only global addresses in the tables. This means that there must already be a static NAT entry in place for the outside address to appear as a global address.
In practice, this is seldom successful. The outside context interface usually points toward a public network such as the Internet, where most or all of the addresses exist but are not configured into the context. Usually, a default route points the way toward the public network where a context can find every other host that is not explicitly configured. However, the classifier must use actual global addresses, not routes, so it cannot determine which context to use to reach outside hosts.
To remedy this situation, you would have to configure static NAT entries for each of the outside host addresses that might be involved in connections from the inside hosts! That might result in two extremes:
- The list of outside hosts would be too small to be practical for the inside users.
- The number of outside hosts would be much too great to try to configure.
In most cases, the inside context interfaces are not shared because inside networks tend to be isolated and protected from every other network. However, another scenario deserves consideration. With multiple security contexts at your disposal, you might consider nesting or cascading contexts to provide layers or shells of security in an enterprise network.
Consider Figure 4-6, in which the left portion represents such a hierarchy of security contexts. The topmost context might be used at the boundary with the Internet to provide common security policies for the entire enterprise. Then other contexts might be nested below that to serve individual departments or buildings within the enterprise.
To test this scenario, the structure has been reduced on the right portion of the figure to show a cascade of just two security contexts. This turns out to be very similar to the previous example, in which the inside context interfaces were shared. However, it might not be obvious that the middle classifier is positioned where two context interfaces are shared. The Context A inside interface is shared with the Context B outside interface to build the cascading structure.
Again, when packets originating from the inside hosts reach this classifier, chances are that no static NAT or global address will be configured or found for outside Internet hosts. Therefore, that classifier cannot decide whether to send the packets to Context A or back to Context B.
As a result, you should plan on nesting or cascading security contexts only if you can provide static NAT entries for each outside host that inside hosts will be allowed to contact. Otherwise, you can build a nested arrangement from separate physical security appliance platforms, where classifiers are not needed between firewalls or contexts.
Solving Shared Context Interface Issues with Unique MAC Addresses
By default, every physical ASA interface uses its burned-in address (BIA) as its Media Access Control (MAC) address. Also, every subinterface of a physical interface uses the physical interface’s MAC address. After the ASA is configured for multiple context mode, system context interfaces (both physical and subinterfaces) are allocated to other contexts. This means that the MAC address of a system context interface is reused on each of its associated context interfaces.
For example, consider an ASA that has the following system context configuration. Physical interface Ethernet0 is shared across all contexts as the single link to the outside world. Each context has a unique subinterface of Ethernet1 to use as its inside interface, as shown in the following system context configuration:
context admin
allocate-interface Ethernet0
allocate-interface Ethernet1
config-url flash:/admin.cfg
!
context ContextA
allocate-interface Ethernet0
allocate-interface Ethernet1.1
config-url flash:/ContextA.cfg
!
context ContextB
allocate-interface Ethernet0
allocate-interface Ethernet1.2
config-url flash:/ContextB.cfg
Next, it is useful to see how the ASA allocates its MAC addresses. In the following example, the system context interface MAC addresses are displayed with the show interface command. Notice that each physical interface (Ethernet0, Ethernet1, and so on) has a unique address. The MAC addresses for subinterfaces (Ethernet1.1 and Ethernet1.2) are not shown; they simply inherit the address of their parent physical interfaces.
asa-a# show interface | include (Interface | MAC)
Interface Ethernet0 "", is up, line protocol is up
MAC address 000e.d7e6.af77, MTU not set
Interface Ethernet1 "", is up, line protocol is up
MAC address 000e.d7e6.af78, MTU not set
Interface Ethernet1.1 "", is up, line protocol is up
Interface Ethernet1.2 "", is up, line protocol is up
Interface Ethernet2 "Failover", is up, line protocol is up
MAC address 0005.5d19.019c, MTU 1500
Interface Ethernet3 "", is administratively down, line protocol is down
MAC address 0005.5d19.019d, MTU not set
Interface Ethernet4 "", is administratively down, line protocol is down
MAC address 0005.5d19.019e, MTU not set
Interface Ethernet5 "", is administratively down, line protocol is down
MAC address 0005.5d19.019f, MTU not set
asa-a#
Finally, each context is visited to display the MAC addresses of its own interfaces. Because system context interface Ethernet0 is allocated to each of the other contexts as a shared outside interface (also called Ethernet0), notice that the highlighted MAC addresses are identical:
asa-a/admin# show interface | include (Interface | MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 000e.d7e6.af77, MTU 1500
Interface Ethernet1 "inside", is up, line protocol is up
MAC address 000e.d7e6.af78, MTU 1500
asa-a/admin#
asa-a/admin# changeto context ContextA
asa-a/ContextA# show interface | include (Interface | MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 000e.d7e6.af77, MTU 1500
Interface Ethernet1.1 "inside", is up, line protocol is up
MAC address 000e.d7e6.af78, MTU 1500
asa-a/ContextA#
asa-a/ContextA# changeto context ContextB
asa-a/ContextB# sh interface | include (Interface | MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 000e.d7e6.af77, MTU 1500
Interface Ethernet1.2 "inside", is up, line protocol is up
MAC address 000e.d7e6.af78, MTU 1500
asa-a/ContextB#
Reusing the MAC addresses does not usually pose a problem because neighboring devices can still see a correspondence between a context interface’s IP address and its MAC address. But what about the example case where the same physical or subinterface is allocated to several different firewall contexts? Each of the allocated context interfaces would have a unique IP address from the same shared subnet, but would reuse the same MAC address.
Neighboring devices might not be able to distinguish one context from another because of the shared MAC address. However, the ASA can usually accept traffic destined to the shared MAC address and figure out which context interface is the real recipient. The ASA uses a classifier function to examine incoming packets and pass them along to the correct context. The classifier works through the following sequence of conditions to map a packet’s destination address to a context:
- A unique interface— When one interface is allocated to only one context, the destination context is obvious.
- A unique MAC address— The destination MAC address is found on only one context interface.
- A unique NAT entry— A unique destination Internet Protocol (IP) address is needed, either through a global address configured in a static NAT entry or found in the xlate table.
Beginning with ASA 7.2(1), you can configure the ASA to use unique MAC addresses on every subinterface and context interface. Physical (system context) interfaces continue to use their burned-in addresses, whereas context interfaces receive MAC addresses that are automatically generated. You can use the following global configuration command to assign unique MAC addresses:
This command can be used only in the system execution space because that is the source of all interface allocation. As soon as you enter the command, the interface MAC addresses is changed. You can revert back to the original interface MAC addresses by using the no mac-address auto command.
The MAC addresses are automatically generated according to the format spelled out in Table 4-1.
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
The slot is the interface slot number, or 0 for platforms without slots. The port is the interface port number, and subid is the ASA’s internal subinterface number. The contextid field is the context index, a number the ASA uses internally. You should not worry about what the internal numbering schemes mean—just know that you can easily distinguish the active and standby addresses by the leading 1 or 0 and that each context has a unique identifier.
Continuing the previous example, the mac-address auto command has been entered. The MAC addresses for each of the ASA’s contexts are shown in the following output.
asa-a# show interface | include (Interface | MAC)
Interface Ethernet0 "", is up, line protocol is up
MAC address 000e.d7e6.af77, MTU not set
Interface Ethernet1 "", is up, line protocol is up
MAC address 000e.d7e6.af78, MTU not set
asa-a# changeto context admin
asa-a/admin# show interface | include (Interface | MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 1200.0000.0100, MTU 1500
Interface Ethernet1 "inside", is up, line protocol is up
MAC address 1201.0000.0100, MTU 1500
asa-a/admin#
asa-a/admin# changeto context ContextA
asa-a/ContextA# show interface | include (Interface | MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 1200.0000.0200, MTU 1500
Interface Ethernet1.1 "inside", is up, line protocol is up
MAC address 1201.0001.0200, MTU 1500
asa-a/ContextA#
asa-a/ContextA# changeto context ContextB
asa-a/ContextB# show interface | include (Interface 165168| MAC)
Interface Ethernet0 "outside", is up, line protocol is up
MAC address 1200.0000.0300, MTU 1500
Interface Ethernet1.2 "inside", is up, line protocol is up
MAC address 1201.0002.0300, MTU 1500
asa-a/ContextB#
The ASA automatically generates its MAC addresses using carefully selected parameters. The first six hex digits of the MAC address are referred to as the Organizational Unique Identifier (OUI) or the vendor code. Cisco uses 02xxxx and 12xxxx, neither of which is registered to another vendor. This should produce MAC addresses that are unique within your network, without duplicating the addresses used by other devices.
| Tip |
|
In some rare cases, you could find that an automatically derived MAC address is conflicting with that of another device. How would you know if that happens? You might find that an ASA context is behaving erratically or you might see the following Syslog message in the ASA logs:
interface inside
To remedy this situation, you can use the following interface configuration command to manually configure the ASA context interface MAC address to a different, unique value:
asa(config-if)# mac-address mac_address [standby mac_address]
The MAC address is entered in dotted triplet format (H.H.H), such as 0015.c557.f9bd. If your ASA is configured as part of a failover pair, remember to configure both the active and standby unit interface MAC addresses.
Configuration Files and Security Contexts
The firewall’s flash memory file system is accessible only from the system execution space. This is because Flash is considered a controlled resource, available only to the physical firewall’s administrators. If an individual user context is given over to be managed by a third party, it would not make sense to allow that third party to make changes to or allocate all of the firewall flash for his or her own use.
Where, then, are the firewall image and configuration files stored for a user context? None of the contexts runs its own firewall operating system image. Only one image is run in multiple-context mode, and that image is managed only by the system execution space. All other contexts appear to run the same image, as shown by the output generated by the show version command.
Configuration files, however, are used and maintained by each context. They have the following characteristics:
- The system execution space has both startup and running configuration files that are stored in the flash memory. The startup configuration file can be read, written, and copied, but it is kept in a hidden flash file system.
- Admin and user contexts have both startup and running configuration files. The startup configuration files can be stored in the flash file system or on an external TFTP, FTP, or HTTP server. When an external server is used, the user context administrators can have complete autonomy over the configuration and use of their firewall context.
- The system execution space configuration defines where each context’s startup configuration file will be located.
Guidelines for Multiple-Context Configuration
You can configure and use several different types of contexts on a physical firewall or security appliance:
- The system execution space— Although this is not a true context itself, it is the foundation for all other contexts.
- The admin context— A fully functional virtual firewall that can be used to administer the physical firewall platform.
- One or more arbitrarily named user contexts— Each context operates as an independent virtual firewall.
Each has a specific role within the firewall platform, making configuration somewhat confusing.
The system execution space handles context definition, overall firewall modes of operation, and the physical firewall resources. Therefore, it should be configured before resources and features become available to other contexts.
You can configure the following types of features in the system execution space:
- Physical firewall interfaces (speed, duplex, negotiation, descriptions, VLAN associations, and operational status)
- System images (firewall operating system and PIX Device Manager/Adaptive Security Device Manager [PDM/ASDM] management application)
- Firewall startup configuration file
- Context mode (single or multiple)
- Context definitions (configuration files, interface allocation, or mapping)
- Firewall failover
- Saving crash information
- Firewall system clock
You must enter firewall license activation keys from the system execution space. In addition, the system execution space provides all access to the firewall’s flash file system.
However, the system execution space has no networking capability of its own. To access external network resources, such as a TFTP server containing the firewall image, the system execution space must work in conjunction with the admin context, where normal IP addressing and address translation are configured.
You should consider each nonsystem context to be a fully functional standalone firewall. Therefore, you can configure the admin and user contexts with all the firewall features presented in this book.
Initiating Multiple-Context Mode
Follow these steps to prepare a firewall for multiple-security context support:
- Verify multiple-context licensing:Firewall# show activation-keyA firewall can run in multiple-context mode only if it has been licensed to do so. As well, the maximum number of security contexts is set by the license. You can display the number of contexts supported by the current license, as shown in the following output:Firewall# show activation-key
Serial Number: 401262144
Running Activation Key: 0xcc05f166 0xd4c17b68 0x98501048 0x818cf190
0x4133d195
License Features for this Platform:
Maximum Physical Interfaces : 10
Maximum VLANs : 100
Inside Hosts : Unlimited
Failover : Active/Active
VPN-DES : Enabled
VPN-3DES-AES : Enabled
Cut-through Proxy : Enabled
Guards : Enabled
URL-filtering : Enabled
Security Contexts : 5
GTP/GPRS : Enabled
VPN Peers : Unlimited
This machine has an Unrestricted (UR) license.
The flash activation key is the SAME as the running key. - (Optional) Install a new license activation key:Firewall# activation-key keyYou might need to install a new activation key if multiple-context mode is disabled or if you need to increase the number of supported contexts.The key given here is a string of five groups of characters, each consisting of four pairs of hexadecimal digits. You can add a 0x prefix to each group of hex digits to denote the hex format, but this is not necessary. For example, you could use the following command:Firewall# activation-key 59381b44 a46717cc a43114a8 8ce11438 862113baRefer to Section “2-2: Firewall Features and Licenses,” in Chapter 2, “Configuration Fundamentals,” for more information about configuring license activation keys.
- Verify the security context mode:Firewall# show modeBy default, a firewall operates in single-context mode. You can display the current mode with this command. If the firewall is currently running in single-context mode, you see the following output:Firewall# show mode
Running Firewall mode: single
Firewall#If the firewall is already running in multiple-context mode, you see the following output:Firewall# show mode
Running Firewall mode: multiple
Firewall# - Initiate multiple-context mode:Firewall(config)# mode [noconfirm] multipleIn single-context mode, all the firewall’s configuration commands are contained in the startup configuration. Multiple-context mode changes this concept, because the initial startup configuration must contain commands that define the individual contexts. Each context has its own startup configuration file that configures features used only by that context.If single-context mode already has some configuration when this command is used, an admin context is automatically created, and the appropriate commands are imported into it. Any interfaces that were configured and enabled are automatically mapped into the admin context, too. Otherwise, the admin context begins with no mapped interfaces.The end result is that the firewall automatically generates the startup configuration for the system execution space, which is stored in a hidden flash file system. A startup configuration for the admin context is automatically generated and stored as the flash:/admin.cfg file.Initiating multiple-context mode triggers the display of several prompts for you to confirm each action before it is carried out. You can use the noconfirm keyword to force the firewall to initiate multiple-context mode without any confirmation prompts.For example, a firewall running in single-context mode is configured to begin running in multiple-context mode. The mode multiple command produces the following output:Firewall(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
***
*** --- SHUTDOWN NOW ---
***
*** Message to all terminals:
***
*** change mode to flash
Flash Firewall mode: multiple
[output omitted]
Creating context 'system'... Done. (0)
Creating context 'null'... Done. (257)
Creating context 'admin'... Done. (1)
INFO: Context admin was created with URL flash:/admin.cfg
INFO: Admin context will take some time to come up .... please wait.
*** Output from config line 32, " config-url flash:/admi..."
[output omitted]
Firewall# show mode
Running Firewall mode: multiple
Firewall#Notice that several contexts are automatically created during this process: The system context is actually the system execution space, the null context serves as a placeholder or a system resource, and the admin context becomes the configuration for the administrative side of the firewall.The number in parentheses after each context, such as (0), indicates the context number or index. The null context is always defined with the topmost index. After you initiate multiple-context mode, the firewall also leaves hooks for a backout plan should you ever need to revert to single-context mode. The previous running configuration is automatically saved as the flash:/old_running.cfg file. If the mode single command is used in the future, the firewall attempts to use that file to re-create a single-context mode configuration. Therefore, you should consider leaving that file intact in the flash file system for future use.
Navigating Multiple Security Contexts
In multiple-context mode, it is possible to open an administrative session (console, Telnet, or Secure Shell [SSH]) to the firewall and then move around between security contexts. This allows you to configure and monitor any of the contexts as necessary without opening sessions to the individual virtual firewalls.
You can navigate between contexts only if you successfully connect and authenticate to the admin context or the system execution space first. At that point, you are considered an administrator of the physical firewall platform and any contexts that are configured.
If you connect to a user context first, the firewall limits your administrative session to only that context. This restricts the administrators of a user context from gaining access to any other context on the firewall. Each context is then independently managed from within that context.
Context Prompts
Moving between contexts can get confusing. During one administrative session, you might have to keep track of which physical firewall platform and which context (virtual firewall) you are connected to. Fortunately, the firewall gives you a landmark each time you move your session.
The firewall always updates its prompt to indicate which context you are currently accessing. The traditional prompt, Firewall#, represents the system context; Firewall represents the firewall’s host name. Any other context is indicated by a prompt such as Firewall/context#, where context is the name of the context.
| Tip |
|
Changing a Session to a Different Context
You can move your terminal session from one context to another, as long as you have the administrative rights to do so, by entering the following command:
Firewall# changeto {system | context name} For example, suppose your firewall has the host name MyPix. It also has a system execution space (always created by default), an admin context, and a user context called CustomerA. You can use the following commands to navigate between contexts:
MyPix# changeto context admin
MyPix/admin#
MyPix/admin# changeto context CustomerA
MyPix/CustomerA#
MyPix/CustomerA# changeto system
MyPix#
Notice how the session prompt automatically changes to indicate the firewall and context name each time the session is moved. Keep in mind that the system execution space is always called system and not context system. Therefore, it does not really have a context name to be displayed in the prompt.
Configuring a New Context
All contexts must be defined from a firewall’s system execution space. Make sure you position your session in the system space with the following command before continuing:
The firewall also needs an admin context to be able to communicate beyond itself. The admin context is usually built automatically when the firewall is configured for multiple-context mode. As well, each time the firewall boots up, you should see console messages indicating that the admin context has been rebuilt.
To see a list of the contexts that have been configured, you can use the following command:
In the following example, only the admin context has been built:
Context Name Interfaces URL
*admin flash:/admin.cfg
Total active Security Contexts: 1
Firewall#
To configure a new context, follow these steps:
- Name the context:Firewall(config)# context name Every context must have a name that is unique on the physical firewall platform. This name is used in the context definition, in commands used to change sessions over to the context, in the user interface prompt, and in some forms of logging messages.
Tip You must add an admin context to every firewall so that it can communicate with the outside world. Therefore, the first context you should create is the admin context.By default, the admin context is named “admin” and is created by using the context admin command. If you decide to give it some other arbitrary name, you will identify it as the admin context in a later configuration step. - (Optional) Label the context:Firewall(config-ctx)# description textYou can define an arbitrary string of descriptive text (up to 200 characters) if you need to label a context with more information than just its name. For example, you might want to add a responsible person’s name and contact information, or some specific information about the purpose of the context, such as the following:Firewall(config)# context BuildingC_DataCenter
Firewall(config-ctx)# description Contact John Doe, jdoe@mycompany.com,
(859)555-1234; schedule any context downtime one week ahead of time. - Map existing firewall interfaces into the context.Firewall interfaces (physical or logical) are always created and tuned from within the system execution space. All user contexts (including the admin context) begin with no interfaces when they are first defined. As well, no interfaces can be created from a user context.Instead, you must map specific interfaces from the system execution space into a user context. After an interface has been mapped, it can be configured with a name, a security level, and an IP address from that context’s configuration mode.
- (ASA only) Map a physical interface:Firewall(config-ctx)# allocate-interface physical-interface [map-name]
[visible | invisible]The physical firewall interface named physical-interface (“GigabitEthernet0,” for example) is mapped into the current context.By default, the mapped interface appears with the same physical-interface hardware name in the context. If you would rather keep the interface hardware name hidden from the context users, you can specify an arbitrary interface name such as map-name. The context users then use that name to configure the interface. By default, mapped interface hardware names are also kept invisible to context users who use the show interface command. This is identical to including the invisible keyword. If you want to provide a clue as to the context interface’s position in the firewall platform, use the visible keyword. When a mapped interface is made visible, context users can see its “system name” in the show interface output, as in the following example:Firewall(config)# context NewContext
Firewall(config-ctx)# allocate-interface ethernet1 test visible
Firewall(config-ctx)# exit
Firewall# changeto context NewContext
Firewall/NewContext# show interface test
Interface test "", is down, line protocol is down
System name Ethernet1
Available but not configured via nameif
Firewall/NewContext#Tip When you map an interface into a user context, you are actually creating a “hardware” name for that interface. You still have to configure the user context so that the new interface has a name, using the nameif interface configuration command. In the preceding example, context NewContext considers the new mapped interface name “test” to be the hardware device. Interface “test” does not have a name and a security level for firewall use until it is configured further. You could use the following commands to complete the interface configuration:Firewall/NewContext# show running-config interface test
!
interface test
no nameif
no security-level
no ip address
Firewall/NewContext# configure terminal
Firewall/NewContext(config)# interface test
Firewall/NewContext(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
Firewall/NewContext(config-if)# no shutdownNow the show interface command shows the mapped interface “hardware” name (test), the logical name (outside), and the system platform name (Ethernet1), as shown in the following output:Firewall/NewContext# show interface outside
Interface test "outside", is down, line protocol is down
System name Ethernet1
MAC address 00a0.c901.0201, MTU 1500
IP address unassigned
Received 0 packets, 0 bytes
Transmitted 0 packets, 0 bytes
Dropped 0 packets
Firewall/NewContext# - Map a physical subinterface or VLAN interface.In an ASA, a physical interface can operate as a trunk, transporting traffic over multiple VLANs, where each VLAN is mapped to a unique subinterface number. For example, in the system execution space, interface gigabitethernet1 operates as a trunk. VLAN 5 might be mapped to subinterface gigabitethernet1.5, and VLAN 7 might be mapped to gigabitethernet1.7. (The subinterface numbers are arbitrary and do not have to match the VLAN number.)On an FWSM platform, only VLAN interfaces are supported as if they are physical interfaces.You can map a subinterface or a VLAN interface from the system execution space to a user context, as if it were a physical interface. Use the following command to define a single mapping:FWSM Firewall(config-ctx)# allocate-interface vlannumber [map_name]ASA
Firewall(config-ctx)# allocate-interface physical-
interface.subinterface [map_name] [visible | invisible]
Open table as spreadsheet The physical subinterface named physical-interface.subinterface (ASA) or the Virtual LAN (VLAN) interface (FWSM) is mapped to the current context as an interface by the same name. You can include an arbitrary logical map_name if you want to keep the actual interface name hidden from the context users. In that case, the context users use map_name to further configure the interface.You can also map a range of subinterfaces or VLAN interfaces, as long as their subinterface or VLAN numbers are contiguous. Use the following command to accomplish this mapping:FWSM
Firewall(config-ctx)# allocate-interface vlannumber-vlannumber
[map_name-map_name]ASA
Firewall(config-ctx)# allocate-interface physical-
interface.subinterface-physical.interface.subinterface [map_
name-map_name] [visible | invisible] Open table as spreadsheet Specify the range of interfaces with the starting subinterface and the ending subinterface, separated by a hyphen. The physical interface name (physical-interface) must be identical in the range definition, with only the subinterface numbers changing. For example, the following command maps subinterface numbers 1 through 5:Firewall(config-ctx)# allocate-interface
gigabitethernet0.1-gigabitethernet0.5For the FWSM platform, the range is given with the starting and ending VLAN interfaces, each beginning with the keyword vlan followed by the VLAN number. For example, the following command maps interfaces for VLANs 1 through 5:Firewall(config-ctx)# allocate-interface vlan1-vlan5 Naturally, you can also map a range of subinterfaces or VLAN interfaces to a range of logical interface names. To do so, specify the range of map names from starting to ending, separated by a hyphen. The map_name is an arbitrary name ending with a number. Both the starting and ending map_name must be identical, except for the number. The starting and ending number must define a range of the same size as the physical or VLAN interface range.For example, you can allocate a range of five physical subinterfaces to a range of five logical names with the following ASA command:Firewall(config-ctx)# allocate-interface
gigabitethernet0.1-gigabitethernet0.5 Int1-Int5Similarly, you could use the following command on an FWSM platform:Firewall(config-ctx)# allocate-interface vlan1-vlan5 Int1-Int5Note Although an interface can be mapped to other contexts, each context maintains its own interface state. For example, suppose physical interface GigabitEthernet0 has been mapped to interface0 in context admin. Context admin can shut down its interface0 while the physical interface GigabitEthernet0 is still up and functioning in the system execution space.Naturally, the reverse is not true; the system execution space controls the interface state for all other contexts. If the system space has a physical interface administratively shut down (with the shutdown command), all other contexts with that interface mapped show it as simply “down” and not “administratively down.”Also notice that, in the system space, interfaces are strictly physical and do not have logical names or security levels. You can see this in the following example:Firewall# show interface
Interface GigabitEthernet0 "", is up, line protocol is up
Hardware is i82543 rev02, BW 1000 Mbps, Full-duplex
Description: Outside public network (non-trunk)
Available for allocation to a context
MAC address 0003.479a.b395, MTU not set
IP address unassigned
[output omitted]
Interface GigabitEthernet0.2 "", is up, line protocol is up
VLAN identifier 2
Description: VLAN 2 - inside private network
Available for allocation to a context
Interface GigabitEthernet0.3 "", is up, line protocol is up
VLAN identifier 3
Description: VLAN 3 - stateful failover
Available for allocation to a context
-
- Define the context startup configuration location:Firewall(config-ctx)# config-url urlThe startup configuration can be located at a URL defined by url at any of the locations listed in Table 4-2. Table 4-2: Context Startup Configuration Locations Open table as spreadsheetLocation url SyntaxFlash memory (PIX)
flash:/[path/]filenameFlash memory (FWSM)
disk:/[path/]filenameTFTP server
tftp://[user[:password]@]server[:port]/[path/]filename[;int=if_name]FTP server
ftp://[user[:password]@]server[:port]/[path/]filename[;type=xy] where x denotes ASCII mode (a) or binary mode (i) and y denotes passive mode (p) or normal mode (n) HTTP server
http[s]://[user[:password]@]server[:port]/[path/]filenameCaution As soon as you enter the config-url command, the system execution space attempts to load that configuration file immediately. This is done so that the new context can be built with a working configuration. If the URL points to a location external to the firewall, the IP connectivity configured on the admin context is used to reach the URL server.However, be aware that if you reenter the config-url command to point to a new configuration file location, the configuration commands in that file are immediately merged with the context’s running configuration. This could result in an undesirable configuration.Within the new context, the URL pointing to the configuration file is used in place of a startup configuration file in flash memory. If the configuration file does not yet exist, the firewall creates the file with a minimal or blank context configuration.Any commands that involve the startup configuration use the URL instead. For example, the copy running-config startup-config and write memory commands copy the current running configuration to a file defined by the URL.In this fashion, the startup configuration can be uploaded to or downloaded from the URL location. The only exception is a URL that points to an HTTP or HTTPS server; then the file can only be downloaded to the firewall context.For example, the following commands configure the CustomerA context to download its startup configuration from a TFTP server:Firewall(config)# context CustomerA
Firewall(config-ctx)# config-url tftp://192.168.200.10/pixconfigs/
CustomerA.cfg - (Optional) Designate the admin context:Firewall(config)# admin-context nameBy default, the admin context is named “admin,” and the following command is automatically added to the system execution space configuration:Firewall(config)# admin-context adminIf you would rather use the context you have just created as the admin context, you can use the preceding command to assign its new role. The previous admin context still exists in the system execution space configuration and as a working context.
| Tip |
|
Context Definition Example
Consider a physical firewall that is configured with three separate contexts for the enterprise:
- One for firewall administration
- One for Department A
- One for Department B
Figure 4-7 shows a network diagram of the multiple-context arrangement.
For the purposes of this example, each context is defined and configured with only basic interface parameters. The idea is to become familiar with context creation and configuration and interface allocation. You perform the configuration steps by connecting to the physical firewall console to gain access to the system execution space.
First, get a sampling of the physical interfaces that are available on the system execution space. These interfaces are available to be mapped into user contexts. The following command and output are used:
: Saved
:
ASA Version 8.0(1)
!
interface GigabitEthernet0/0
description Public interface
!
interface GigabitEthernet0/1
description Trunk for private context interfaces
!
interface GigabitEthernet0/1.2
vlan 2
!
interface GigabitEthernet0/1.3
vlan 3
!
interface GigabitEthernet0/1.4
vlan 4
[output omitted]
Next, the admin context is used for firewall management, so it must be defined in the system execution space configuration. The admin startup configuration is stored in flash as the file admin.cfg. Two firewall interfaces are allocated to the context. Because it is the admin context, the interface names cannot be mapped to other arbitrary names. Use the following commands to configure the admin context:
Firewall(config)# context admin
Firewall(config-ctx)# config-url flash:/admin.cfg
Cryptochecksum(unchanged): 352c788c 39cd2793 66c6ef98 c6bc632e
INFO: Context admin was created with URL flash:/admin.cfg
INFO: Admin context will take some time to come up .... please wait.
Firewall(config-ctx)#
Firewall(config-ctx)# allocate-interface GigabitEthernet0/0
Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.2
Firewall(config-ctx)# exit
Firewall(config-ctx)# admin-context admin
Firewall(config)#
Now you can define a user context called DepartmentA. This is also done from the system execution space. Two firewall interfaces are allocated to the context, and the names are mapped to the generic values intf0 and intf1. For the present time, the context startup configuration is stored as a file named DepartmentA.cfg in flash memory. You can manage this file from the system execution space only, but context users can read or write to it using the startup-config command keyword. Later, the context users can arrange to store the file on an external server. When that happens, the following config-url command needs to be updated:
Firewall(config-ctx)# config-url flash:/DepartmentA.cfg
WARNING: Could not fetch the URL flash:/DepartmentA.cfg
INFO: Creating context with default config
Firewall(config-ctx)# description Virtual Firewall for Department A
Firewall(config-ctx)# allocate-interface GigabitEthernet0/0 intf0
Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.3 intf1
Firewall(config-ctx)# exit
Define the user context DepartmentB with the following commands on the system execution space. This context is structured similarly to the DepartmentA context. The startup configuration also is stored on the firewall flash until it is moved later.
Firewall(config-ctx)# description Virtual firewall for Department B
Firewall(config-ctx)# config-url flash:/DepartmentB.cfg
WARNING: Could not fetch the URL flash:/DepartmentB.cfg
INFO: Creating context with default config
Firewall(config-ctx)# allocate-interface GigabitEthernet0/0 intf0
Firewall(config-ctx)# allocate-interface GigabitEthernet0/1.4 intf1
Firewall(config-ctx)# exit
Firewall(config)# exit
Firewall#
After all the contexts are defined, do not forget to save the system execution space configuration to flash memory using the following command:
At this point, the firewall flash memory contains the startup configuration files for every user context. (The system execution space startup configuration file is always stored in a hidden flash file system.) The firewall flash memory looks something like this:
Directory of flash:/
3 -rw- 4958208 06:41:52 Nov 30 2004 image.bin
4 -rw- 8596996 10:12:38 Nov 12 2004 asdm.bin
10 -rw- 1591 16:45:18 Dec 03 2004 old_running.cfg
12 -rw- 1853 09:47:02 Dec 30 2004 admin.cfg
14 -rw- 2119 14:16:56 Dec 07 2004 CustomerA.cfg
16 -rw- 2002 14:19:44 Dec 07 2004 CustomerB.cfg
16128000 bytes total (2565231 bytes free)
Firewall#
| Note |
|
Now, each user context can be configured as an independent firewall. Each one starts with an empty configuration, except for the mapped interface definitions, so the initial session must be opened from the system execution space. As soon as a context is configured with enough information to have network connectivity, users can connect through any other means (Telnet, SSH, ASDM, and so on).
First, change the session to the admin context and have a look at the available interfaces. Notice that each one is present but has no usable configuration.
Firewall/admin# show running-config
:
PIX Version 8.0(1)
names
!
interface GigabitEthernet0/0
no nameif
no security-level
no ip address
!
interface GigabitEthernet0/1.2
no nameif
no security-level
no ip address
[output omitted]
At a minimum, name the inside and outside interfaces, and configure them with IP addresses and security levels. You can do this with the following configuration commands (described in more detail in Chapter 3, “Building Connectivity”):
Firewall/admin(config)# interface GigabitEthernet0/0
Firewall/admin(config-if)# nameif outside
Firewall/admin(config-if)# security-level 0
Firewall/admin(config-if)# ip address 192.168.1.10 255.255.255.0
Firewall/admin(config-if)# no shutdown
Firewall/admin(config)# interface GigabitEthernet0/1.2
Firewall/admin(config-if)# nameif inside
Firewall/admin(config-if)# security-level 100
Firewall/admin(config-if)# ip address 192.168.2.1 255.255.255.0
Firewall/admin(config-if)# no shutdown
You can configure the DepartmentA and DepartmentB user contexts in a similar manner. Use the changeto context DepartmentA and changeto context DepartmentB commands to move the session to each context.
In this example, firewall interfaces are allocated to the user contexts with the mapped names intf0 and intf1. After you connect to a user context session, the only clue you have about a mapped interface is its generic or mapped name. After all, the idea behind mapping interfaces is to present context users with arbitrary interface names that do not represent physical hardware.
Therefore, you might have to return to the system execution space configuration to remember which physical firewall interface is mapped to which context interface and which context interface should be configured as inside and outside.
To continue the example, the DepartmentA user context is configured next. Notice the initial interface definitions:
Firewall/DepartmentA# show running-config
: Saved
:
PIX Version 8.0(1)
names
!
interface intf0
no nameif
no security-level
no ip address
!
interface intf1
no nameif
no security-level
no ip address
[output omitted]
Now you can configure the context interfaces with the following commands:
Firewall/DepartmentA(config)# interface intf0
Firewall/DepartmentA(config-if)# nameif outside
Firewall/DepartmentA(config-if)# security-level 0
Firewall/DepartmentA(config-if)# ip address 192.168.1.11 255.255.255.0
Firewall/DepartmentA(config-if)# no shutdown
Firewall/DepartmentA(config)# interface intf1
Firewall/DepartmentA(config-if)# nameif inside
Firewall/DepartmentA(config-if)# security-level 100
Firewall/DepartmentA(config-if)# ip address 192.168.3.1 255.255.255.0
Firewall/DepartmentA(config-if)# no shutdown
| Tip |
|
Allocating Firewall Resources to Contexts
When a firewall platform is running in single-context security mode, you can configure and use only one operational firewall. Therefore, that firewall can use any or all of the available traffic inspection and session resources on that hardware platform. In other words, if the firewall uses most of its own resources while it does its job, its own performance is not affected.
In multiple-context security mode, however, all the configured contexts must share the available resources on their physical firewall platform. If one context becomes heavily loaded or highly utilized, it can use a majority of the traffic inspection resources. This can affect the other contexts by leaving them starved for the same resources.
Multiple-context mode can support resource allocation by imposing limits on how specific resources are used. You can configure resource limits in classes according to the resource type and assign memberships in the classes to contexts. Resource allocation has the following characteristics:
- Resource allocation is available on the FWSM, starting with release 2.2(1). Resource allocation is also available starting with ASA 7.2(1).
- Firewall resources that can be limited fall into several categories:
- Stateful inspection— The number of hosts, connections, address translations, and application inspections
- MAC addresses— The number of MAC addresses learned in transparent firewall mode
- Syslog message generation rate— The number of logging messages sent per second to Syslog servers
- Administrative sessions— The number of ASDM, Telnet, SSH, and IPSec connections to the firewall
-
- The default class permits unlimited use of most resources for all contexts by default. You can configure the default class and adjust specific resource limits in it, if needed.
- You can define and configure new classes with resource limits tailored for a certain level of service.
- You can impose specific limits on a context by assigning it membership in a class. Otherwise, every context that is not a class member belongs to the default class.
- Limits are set per class, not per context. Therefore, all contexts that are assigned to a class share various resources up to the limits of that class. To configure limits on a per-context basis, define one class per context and assign each context to its respective class.
- To exercise thorough control over system resources, you should define classes with specific limits. Then make sure every context is assigned to a class. After that is done, no context can inherit the unlimited resources of the default class.
You can use the following steps to define and apply classes of resource limits to security contexts:
- Define a class of service.
- Identify the class:Firewall(config)# class nameThe class is named name (an arbitrary string up to 20 characters).
Tip You can adjust the resource limits that are defined in the default class by using the class name default in this configuration step. The command syntax then becomes class default. By default, all the default class limits are set to unlimited (0), except for the following:- ASDM sessions (the default is 5)
- Telnet sessions (the default is 5)
- SSH sessions (the default is 5)
- IPSec sessions (the default is 5)
- MAC addresses (the default is 65,535 entries)
-
- (Optional) Define a limit for all resources:Firewall(config-class)# limit-resource all number% All resource types are limited to number (1 to 100) percent of the maximum available on the physical firewall platform. This limit overrides any resource types that are set in the class. After tnumber is set to 0, all resources are allowed to be unlimited. The value number must be followed by a percent character.For example, to limit all resources to 50 percent of their possible values, you would use the following command:Firewall(config-class)# limit-resource all 50%
- (Optional) Define a limit for a single resource:Firewall(config-class)# limit-resource [rate] resource_name number[%]You can limit a specific firewall resource within the class. If you set a limit with this command, it overrides any limit set by the limit-resource all command or by the cific firewall.You can limit the resource named resource_name to an actual value as number or to a percentage of the maximum possible value as number%. You can also add the rate keyword to indicate that number should be interpreted in units per second.Use Table 4-3 to find resource names and their maximum values. Table 4-3: Resource Names and Maximum Values Open table as spreadsheetResource_nameResource TypePlatform Maximum hosts Number of concurrent hosts having connectionsFWSM: 256,000ASA: No limit conns Total UDP and TCP connections between any hostsFWSM: 999,900 concurrentFWSM: 102,400 per secondASA: Limited by platform xlates Address translationsFWSM: 256,000 concurrentASA: No limit fixups (FWSM) inspects (ASA)Application inspectionsFWSM: 10,000 per secondASA: No limit Mac-addresses Transparent firewall MAC address table65,535 concurrent syslogs Syslog messages generatedFWSM: 30,000 per second[1] ASA: No limit Firewalls also support resource limits on various types of sessions that terminate on the firewall. Use Table 4-4 to find those resource names and maximum values. Table 4-4: Resource Names and Maximum Values for Terminating Session Types Open table as spreadsheetResource_nameResource TypePlatform MaximumAsdmConcurrent ASDM sessions32 for ASA80 for FWSM 3.1(1)telnetConcurrent Telnet sessions100[1] sshConcurrent SSH sessions100[1] ipsecConcurrent IPSec connections10[2] You can repeat the limit-resource command to define other resource limits for the class. For example, a class called Silver is configured to limit all firewall resources to 25 percent of the maximum available resources. In addition, the number of xlates is limited to 50,000, and the number of conns is limited to 100,000. The number of Syslog messages is limited to 4000 per second. You can use the following commands to define these limits:Firewall(config)# class Silver
Firewall(config-class)# limit-resource all 25%
Firewall(config-class)# limit-resource xlates 50000
Firewall(config-class)# limit-resource conns 100000
Firewall(config-class)# limit-resource rate syslogs 4000 - Exit the resource class submode:Firewall(config-class)# exit
-
- Assign a context to a class.
- Select a context:Firewall(config)# context nameThe context name should already be defined in the system execution space configuration.
- Assign it to a resource class:Firewall(config-ctx)# member classThe context becomes a member of the resource allocation class named “class,” as defined in Step 1. You can assign membership in only one user-defined class per context. Keep in mind that every context also belongs to the default class. Any resource limit that is not defined in “class” is then inherited from the default class.
-
- Monitor resource allocation.
- Display class membership:Firewall# show classEach of the configured classes is shown with its member contexts. In the following example, all contexts are members of the “default” class, and only context 1 is a member of the “silver” class:Firewall# show class
Class Name Members ID Flags
default All 1 0001
silver 1 2 0000
Firewall# - Review resource allocation:Firewall# show resource allocation [detail]You can use this command to display the current breakdown of resource limits as percentages of the total available. Add the detail keyword to see a more detailed breakdown by resource and context, as in the following example:Firewall# show resource allocation
Resource Total % of Avail
Conns [rate] 85000 50.00%
Fixups [rate] 50000 50.00%
Syslogs [rate] 15000 50.00%
Conns 500000 50.05%
Hosts 131072 50.00%
IPSec 5 50.00%
Mac-addresses 32767 49.99%
ASDM 5 6.25%
SSH 50 50.00%
Telnet 50 50.00%
Xlates 131072 50.00%
Firewall# show resource allocation detail
Resource Origin:
A Value was derived from the resource %and
C Value set in the definition of this class
D Value set in default class
Resource Class Mmbrs Origin Limit Total Total %
Conns [rate] default all CA unlimited
silver 1 CA 85000 85000 50.00%
All Contexts: 1 85000 50.00%
Fixups [rate] default all CA unlimited
silver 1 CA 50000 50000 50.00%
All Contexts: 1 50000 50.00%
Syslogs [rate] default all CA unlimited
silver 1 CA 15000 15000 50.00%
All Contexts: 1 15000 50.00%
Conns default all CA unlimited
silver 1 CA 500000 500000 50.05%
All Contexts: 1 500000 50.05%
[output truncated] - Display the current resource usage:Firewall# show resource usage [context context_name | top n | all |
summary | system] [resource {[rate] resource_name | all} | detail] [counter counter_name
[count_threshold]]You can use this command to display the actual resources being used, as described in Table 4-5. Table 4-5: Options for Displaying Resources Being Used Open table as spreadsheetKeywordDescription context context_name Resources in use by the context named context_name top n resource resource_name Displays the n greatest users of a specific resource all Displays all resource usage information summary Displays a summary by resource type system Resources in use by the system execution spaceYou can also display the results for a specific resource by giving the resource keyword along with a resource_name.Normally, each resource usage line is shown with the fields listed in Table 4-6. Table 4-6: Resource Usage Line Fields Open table as spreadsheetLabelDescriptionCurrentThe number of resources currently in usePeakThe highest amount since counters were clearedLimitThe limit imposed on a resourceDeniedHow many times a resource use has been denied because of a limitContextThe context using the resource If you enter the counter keyword, you can display results based one of the following specific counter_name values: current, peak, denied, or all.You can also get a feel for the complete variety and number of firewall resources used by a context. By adding the detail keyword, you can see all resources being used, whether or not the resources can be limited.
-
Verifying Multiple-Context Operation
To see the current admin context name and configuration URL, you can use the show admin-context command, as in the following example from an ASA platform:
Admin: admin flash:/admin.cfg
Firewall#
To see information about the configured contexts, you can use the following command:
Firewall# show context [[detail] [name] | count] You can specify a context name to see information about only that context. Otherwise, all the contexts are shown. Include the detail keyword to see a breakdown of each context resource, including the configuration URL and interface mappings.
The following example shows the output from an ASA that has three configured contexts: admin, CustomerA, and CustomerB.
Context Name Interfaces URL
*admin GigabitEthernet0 flash:/admin.cfg
GigabitEthernet1.1
CustomerA GigabitEthernet0, tftp://172.30.1.10/customerA.cfg
GigabitEthernet1.3
CustomerB GigabitEthernet1.2,3 tftp://172.16.0.20/customerB.cfg
Total active Security Contexts: 3
Firewall#
On an FWSM platform, the same command produces slightly different output:
Context Name Class Interfaces URL
*admin silver Vlan10,100 disk:/admin.cfg
CustomerA silver Vlan20,100 tftp://172.30.1.10/customerA.cfg
CustomerB default Vlan30,100 tftp://172.16.0.20/customerB.cfg
You can add the detail keyword to see a breakdown of the context configuration. The following example shows the detailed configuration for a context named CustomerA:
Context "CustomerA", has been created
Desc: Virtual firewall for CustomerA's headquarters location
Config URL: tftp://172.30.1.10/customerA.cfg
Real Interfaces: GigabitEthernet0, GigabitEthernet1.3
Mapped Interfaces: intf0, intf1
Flags: 0x00000011, ID: 2
Failover group: 1
Firewall#
Finally, although the firewall cannot limit CPU load as a resource that is shared across contexts, the firewall does keep CPU load statistics. You can see a breakdown of the CPU usage as it is distributed across all the configured contexts. Use the following command from the system execution space:
Firewall# show cpu usage context {name | all} The following example shows CPU usage on a firewall configured with three contexts:
5 sec 1 min 5 min Context Name
7.1% 8.0% 7.1% system
12.0% 12.0% 10.0% admin
27.7% 28.5% 27.0% CustomerA
4.0% 4.0% 4.0% CustomerB
Firewall#
0 comments
Post a Comment