Monitoring and Troubleshooting the Security Contexts
Cisco ASA provides show and debug commands that are useful to check the health of the appliance or to isolate a problem. The necessary show and debug commands that are used to manage multiple security contexts in the appliance are discussed here.
After the system is converted to multiple contexts, the first thing to verify is that the system is using the new mode by using the show mode command, as shown in Example 9-19.
Example 9-19. Output of show mode
Sydney# show mode Security context mode: multiple
Once you verify that the system is running in multiple mode, configure the necessary contexts and assign the appropriate interfaces. A good way to check if the interfaces have been correctly assigned to the right context is to use the show context command. It lists all the configured contexts, the allocated interfaces, and the configuration URL. Example 9-20 shows the output of show context in the Chicago ASA, while logged into the system execution space.
Example 9-20. Output of show context in the System Execution Space
Chicago# show context Context Name Interfaces URL *admin GigabitEthernet0/0.1 disk0:/admin.cfg GigabitEthernet0/1.1 Cubs GigabitEthernet0/0.2, disk0:/Cubs.cfg GigabitEthernet0/1.2, GigabitEthernet0/1.5 Bears GigabitEthernet0/0.3 disk0:/Bears.cfg GigabitEthernet0/1.3 Total active Security Contexts: 3
The asterisk (*) next to admin indicates that this is an admin context. Another way to find out which context is designated as the admin context is to use the show admin-context command, as illustrated in Example 9-21.
Example 9-21. Output of show admin-context in the System Execution Space
Chicago# show admin-context Admin: admin disk0:/admin.cfg
A context administrator can view the context settings from within his security context. In Example 9-22, the administrator of the Cubs context is verifying the allocated interfaces and the configuration URL.
Example 9-22. Output of show context from a Security Context
Chicago/Cubs# show context Context Name Interfaces URL Cubs GigabitEthernet0/0.2, disk0:/Cubs.cfg GigabitEthernet0/1.2, GigabitEthernet0/1.5
Cisco ASA allows monitoring of CPU usage per security context. This is useful to determine which context is utilizing the most of the CPU cycles. Use the show cpu usage context all command to check the CPU utilization on each of the configured security contexts. In Example 9-23, the total system CPU utilization is 9.5 percent averaged over 5 seconds, 9.2 percent averaged over 1 minute, and 9.3 percent averaged over 5 minutes. The Cubs security context is using the most of the CPU cycles, averaging 5 percent over 5 seconds, 1 minute, and 5 minutes.
Example 9-23. Output of show cpu usage context all from the System Execution Space
Chicago# show cpu usage context all 5 sec 1 min 5 min Context Name 9.5% 9.2% 9.3% system 0.3% 0.0% 0.1% admin 5.0% 5.0% 5.0% Cubs 4.2% 4.2% 4.2% Bears
For troubleshooting purposes, Cisco ASA includes a number of important debug and syslog messages to help you isolate the issue. This section discusses four troubleshooting scenarios related to security contexts:
Security contexts are not added— When adding new contexts, the Cisco security appliance displays a message that the new security contexts creation failed, as shown in Example 9-24.
Example 9-24. Security Context Creation Failure
Chicago(config)# context WhiteSox Creating context 'WhiteSox'... Cannot create context 'WhiteSox': limit of 3 contexts exceeded ERROR: Creation for context 'WhiteSox' failed
The Cisco ASA appliance complains about exceeding the maximum number of security contexts allowed in this device. To verify the maximum number of allowed security contexts, use the show version command, as shown in Example 9-25.
Example 9-25. Verifying the Maximum Number of Security Contexts
Chicago# show version | include Security Contexts Security Contexts : 10
Depending on the security appliance model number, the administrator can add the maximum allowed security context number. Refer to Chapter 3, "Hardware Overview," for more information about the allowed number of security contexts in a Cisco ASA.
Security contexts are not saved on the local disk— If the security context configuration files are stored locally on the disk, and the appliance is having trouble either retrieving or saving them, you can enable debug disk to gather information.In Example 9-26, debug disk file,file-verbose, and filesystem are enabled with a log level of 255. In this example, the administrator saves the running configuration into the Flash file system. The highlighted entries show that the appliance opens up the running configuration file from the disk and writes the new contents. If Flash is corrupt, the administrator will see failed attempts to read or write files. These messages are analyzed by the Cisco Technical Assistance (TAC) engineers.
Example 9-26. Output of debug disk
Chicago# debug disk file 255 Chicago# debug disk file-verbose 255 Chicago# debug disk filesystem 255 Chicago# write memory Building IFS: Opening: file system:/running-config, flags 1, mode 0 IFS: Opened: file system:/running-config as fd 0 IFS: Fioctl: fd 0, fn 5, arg 370e7e0 configuration... IFS: Read: fd 1, bytes 147456 IFS: Read: fd 1, bytes 146664 IFS: disk0:/.private/startup-config 100% chance ascii text <snip> 1047 IFS: Close: fd 0 bytes copied in 4.40 secs (261 bytes/sec)IFS: Write: fd 0, bytes 1
Security contexts are not saved on the FTP server— If the security appliance is having issues when saving and retrieving configuration files from an FTP server, use the debug ftp client command to isolate the issue. In Example 9-27, the appliance is being configured to use an FTP server. The debug shows that the user password is incorrect in the configuration URL.
Example 9-27. Output of debug ftp client
Chicago(config)# debug ftp client Chicago# context CustB Chicago(config-ctx)# config-url ftp://cisco:firstname.lastname@example.org/CustB.cfg IFS: Opening: file ftp://cisco:email@example.com/CustB.cfg, flags 1, mode 0 IFS: Opened: file ftp://cisco:firstname.lastname@example.org/CustB.cfg as fd 0 IFS: Fioctl: fd 0, fn 5, arg 279bc64 Loading CustB.cfg FTP: 220 Please enter your user name. FTP: ---> USER cisco FTP: 331 User name okay, Need password. FTP: ---> PASS * FTP: 530 Password not accepted. FTP: ---> QUIT FTP: 221 Goodbye. Control connection closed. IFS: Close: fd 0
User connectivity issues using shared security contexts— As shown in Figure 9-6, when Host A in the Students context is not able to reach Host B in the Faculty context, the administrator can take the following steps to isolate the issue:
- Ping the inside IP address of the S_inside interface from Host A. If successful, move to Step 2; otherwise, check to see if there is an inbound ACL applied to the inside interface. Also verify that physical connectivity exists between the host and the inside interface.
- Ping the outside IP address of the F_outside interface from Host A. If successful, move to Step 3; otherwise, check the outbound ACL and NAT configuration on the Students context. Additionally, verify that the inbound ACL on the F_outside interface allows ICMP traffic from Host A.
- Because this topology uses a shared interface, check the NAT configuration on the Faculty context. Ping from Host A to Host B and verify that the outbound ACL on F_inside does not block the ICMP packets.
- If Host A is still not able to communicate with Host B in the other context, follow Step 1 through Step 3 and ping from Host B to Host A to verify connectivity and the contexts' configuration.