Contents
Health monitoring options on Cisco Firepower appliances
Hardware and software components
SNMP monitoring on Firepower appliances
FTD health monitoring from FMC
Monitoring critical parameters on FTD
CPU monitoring using SNMP from FXOS
CPU monitoring using SNMP from FTD
FMC health policy for CPU monitoring
Interface monitoring using SNMP
Hard disk monitoring using SNMP
Continuously monitoring the health of a network appliance is one of the most critical activities performed by almost every administrator. The parameters that most accurately convey the overall health of any network appliance are:
1. CPU utilization
2. Memory utilization
3. Interface statistics
4. Hard disk utilization (if the appliance has a hard disk and is used for its regular operations)
Most device administrators prefer some form of automation to monitor these parameters. The tool of choice for this in most cases is Simple Network Management Protocol (SNMP).
In this article, we will primarily discuss the SNMP monitoring capabilities of an appliance running Firepower Threat Defense (FTD). We will also look at health policies that can be configured from the Firepower Management Center (FMC), which is another way to monitor the health of the managed devices automatically from the FMC.
Health monitoring options on Cisco Firepower appliances
There are at least three options available for monitoring the health of a Cisco Firepower® appliance running FTD. Two of these options rely on SNMP from two different software sources. The third one relies on custom scripts that FMC runs on its managed devices.
In order to understand the data returned by the SNMP probes, it is important that we understand the high-level architecture of FTD and Cisco Firepower appliances.
Hardware and software components
Every Cisco Firepower appliance contains four main components:
1. The supervisor
2. The Firepower Extensible Operating System (FXOS), which is the operating system installed on the supervisor
3. The security module(s)
4. The security software running on the security module (the security software that this paper discusses is FTD)
The supervisor and security modules are hardware components, and the FXOS and FTD are software running on the respective hardware components.
The supervisor contains built-in physical interfaces and also has the option of adding more interfaces by inserting external network modules. All the physical interfaces (both built-in interfaces and external network modules) on the appliance are part of the supervisor module.
In the current range of hardware appliances, we have the following:
● Firepower 2100 Series
● Firepower 4100 Series
● Firepower 9300 Series
The Firepower 2100/4100 appliances are 1RU with the facility to host a single logical FTD device. The Firepower 9300 range is a 3RU, modular security appliance which allows for up to 3 security modules to be inserted, each of which can host a logical FTD device.
Since v6.3 of the FTD software, the FP4100/9300 appliances are capable of running multiple instances of FTD within a single appliance/security module. Each instance of FTD deployed in this way is a fully independent logical device consuming resources dedicated to it.
The security software (FTD logical device) running on security modules only has logical interfaces. The supervisor also consists of a built-in hardware switch. This switch is what connects the physical interfaces available on the supervisor to the logical interfaces that are created on security software running on the security modules.
Firepower appliances have two major subsystems:
The Firepower Extensible Operating System (FXOS) which controls the chassis hardware
The Firepower Threat Defense security application which runs within the module
Breaking things down a little further, the FTD software is a unified image which consists of two main engines, Snort and LINA.
● The LINA engine derives from the classic Adaptive Security Appliance (ASA) from Cisco and is responsible for the initial handling of packets as well as functions such as routing and network address translation. It is also referred to as the Data Plane.
● The Snort engine is where the higher-level inspection functions take place.
The current SNMP engine of the FTD software is based on the classic ASA and has visibility into the LINA related features.
FX-OS and FTD have independent control planes and for monitoring purposes, they have different SNMP engines. Each of the SNMP engines provides different information and you might be interested in monitoring both for a more comprehensive view of the device status.
In the current FTD releases, the SNMP Management Information Bases (MIBs) supported on the FTD relay information only about the data plane.
SNMP monitoring on Firepower appliances
Each independent software component provides its own SNMP monitoring capabilities. In the case of FTD running on Cisco Firepower appliances like 4100 and 9300, there are two main software components:
1. The FTD software
2. The FXOS software
Firepower 4100/9300 devices have a dedicated interface for the device management and this is the source and destination for the SNMP traffic addressed to the FXOS subsystem. In addition, the FTD application uses a LINA interface (data and/or diagnostic) for the SNMP configuration.
The SNMP engine on Firepower 2100 appliances uses the FTD management interface and IP address. The appliance itself bridges the SNMP traffic received on this interface and forwards it to the FXOS software.
Each software component has its own management plane and their respective managers. FMC manages the FTD software and Firepower Chassis Manager (FCM) manages the FXOS software. For the 2100 series appliances, the two management planes still do exist, but they are both managed from the FMC.
SNMP monitoring from FXOS provides details for the entire security module. It does not differentiate between the various logical devices (security software installed on the security module) running on the security module. SNMP monitoring from FTD provides details specific to FTD. In the current FTD versions, this data is specific to the data plane’s resource utilization.
FTD health monitoring from FMC
Another option that can be used to monitor the health of the appliances running FTD is using the health monitoring policies on the FMC. The health monitor on the FMC tracks a variety of health indicators to ensure that the hardware and software in the Cisco Firepower system are working correctly. You can use the health monitor to check the status of critical functionality across your Cisco Firepower system deployment.
You can use the health monitor to create a collection of tests, referred to as a health policy, and apply the health policy to one or more appliances. The tests, referred to as health modules, are scripts that test for criteria you specify. You can modify a health policy by enabling or disabling tests or by changing test settings, and you can delete health policies that you no longer need. You can also suppress messages from selected appliances by blocked listing them.
It is also possible to configure email, SNMP, or syslog alerting in response to health events. A health alert is an association between a standard alert and a health status level. For example, if you need to make sure an appliance never fails due to hardware overload, you can set up an email alert. You can then create a health alert that triggers that email alert whenever CPU, disk, or memory usage reaches the warning level you configure in the health policy applied to that appliance. You can set alerting thresholds to minimize the number of repeating alerts you receive.
The configuration of health monitoring policies is explained in a later section.
Monitoring critical parameters on FTD
There are four critical parameters to monitor:
1. CPU
2. Memory
3. Interfaces
4. Hard disk
CPU monitoring using SNMP from FXOS
FXOS provides average CPU utilization statistics for one and five-minute intervals. The average is calculated for all the CPU cores irrespective of the process running on the specific core. More specifically, in case of FTD, multiple cores will have data plane threads and Snort instances running on them and two cores will have other system processes running on them. Each of these processes could be differently loaded. The way the data plane is built, it continuously queries the interface buffers for incoming packets. This way the cores running data plane threads are almost always running at 100% CPU utilization. The rest of the processes utilize the CPU only when they have work to do. Because of this difference in the way CPU is used, the average CPU utilization reported by FXOS is quite high, even if the box is idle.
CPU monitoring using SNMP from FTD
As discussed earlier, the SNMP from FTD today relays information about the FTD data plane. So when we query the SNMP module on FTD for CPU utilization statistics, the data returned talks about the CPU utilization of the CPU cores running data plane threads. As discussed in the last section, the data plane CPUs are almost always active. In contrast to the SNMP queries to FXOS, the SNMP queries to FTD software ensure that the correct CPU utilization values are returned. The data plane only reports the statistics for CPU usage when it has a packet to process. It discards the CPU utilization values for the rest of the times when it is just busy checking if there are packets available to process.
With respect to CPU utilization, querying the FTD software is more meaningful since it returns more accurate data. The potential drawback is that the data returned shows the true state of only a subset of the CPUs.
FMC health policy for CPU monitoring
FMC allows monitoring of CPUs as part of its health policy configuration. If CPU monitoring is enabled, the FMC queries the sensors for their CPU status and reports the CPU utilization values in the FMC. The CPU utilization values reported by the FMC as part of the health monitoring process are the true CPU utilization values for all the CPU cores.
Although the values reported using this approach are the correct CPU utilization values, the problem with this approach is that it does not provide any information about the type of process running on the specific CPU.
Among the options available to monitor the CPU utilization, the FMC health monitor is the best option to monitor the device for high CPU utilization cases. As explained later in this paper, one can set up SNMP-based alerts in their health policies, and that can be utilized to integrate this solution with any existing SNMP-based monitoring process that already exists in the managed network.
Similar to CPU monitoring, memory usage on the device can also be monitored using SNMP from either FXOS or FTD. Additionally, FMC health policies also support memory usage monitoring.
Monitoring of FTD memory utilization via SNMP returns information from the data plane threads. It is recommended that the FMC health policies are used to monitor memory usage on the managed device(s).
Similar to CPU monitoring, one can set up SNMP-based alerts in their health policies, and that can be utilized to integrate this solution with any existing SNMP-based monitoring process that already exists in the managed network.
Interface monitoring using SNMP
For FP4100/9300 appliances prior to FXOS v2.4.1, data interfaces could not be shared across logical devices. This meant that statistics for data interfaces could be queried from either FXOS or FTD. Note: When using SNMP to monitor shared data interfaces via FXOS, the values returned will be cumulative for traffic across all of the logical devices on the appliance.
FXOS allows sharing of management interfaces. So if monitoring the interface statistics for management interface is a requirement, then for individual logical devices, it must be monitored from FTD. For cumulative statistics for management traffic across all the logical devices on the appliance, the shared management interface can be monitored from FXOS. If there is only one logical device, then the management interface can be monitored from either FXOS or FTD, and the values must match.
Hard disk monitoring using SNMP
FTD does not provide a way to monitor the hard disk usage via SNMP today. If there is a requirement to monitor disk usage, then the FXOS SNMP MIBs can be used. Please keep in mind that the FXOS will be providing aggregate disk usage statistics by all applications running on the security module if there is more than one application installed on it.
A managed FTD device can be configured to either generate SNMP traps or to allow SNMP read access (SNMP write access is not supported).
For FTD devices, a Firepower Threat Defence Platform Settings policy must be created, and the SNMP options configured. The options consist of defining and enabling SNMP servers, specifying the Read Community string and the SNMP User Datagram Protocol port to use, and assigning the system administrator name and location if desired.
Once this is complete, you must define the hosts that are allowed to poll the FTD device. Hosts can be allowed to poll or trap. If trap is defined, a list of event notification traps will be displayed that you can select (all or some).
FTD supports SNMPv1, v2c, and SNMPv3. The monitoring can only be done on FTD data plane level interfaces including the diagnostic interface. The FTD management interface cannot be monitored via SNMP because technically it is not a part of the FTD data plane engine.
SNMPv2 example (poll)
Step 1. Within the FMC GUI, navigate to Devices > Platform Settings > (Policy) > SNMP. Check the option “Enable SNMP Servers” and configure the SNMPv2 settings per task requirements:
Step 2. On the Hosts tab, click on the Add button and specify the SNMP server settings
The finished configuration will look similar to this:
Step 3. Deploy the policy.
Cisco Firepower primarily uses the health monitor to provide health status events/alerts on system components.
There are also some ASA/FTD data plane based SNMP Object Identifiers (OIDs) that are available for monitoring FTD devices. These are mainly focused on data plane (L2-L4 packet) processing.
Below is an example of available OIDs.
CPU |
1 minute |
.1.3.6.1.4.1.9.9.109.1.1.1.1.7.1 |
5 minutes |
.1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 |
|
Memory |
Free memory |
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.2.1 or .1.3.6.1.4.1.9.9.221.1.1.1.1.20.1.1 |
Standard Linux OIDs are also available for monitoring CPU, swap and memory utilization. Below is an example of available SNMP OIDs that can be monitored.
Performance |
User CPU time (%) |
.1.3.6.1.4.1.2021.11.10.0 |
System CPU time (%) |
.1.3.6.1.4.1.2021.11.10.0 |
|
Idle CPU time (%) |
.1.3.6.1.4.1.2021.11.11.0 |
|
Load average (1 min) |
.1.3.6.1.4.1.2021.10.1.3.1 |
|
Load average (5 min) |
.1.3.6.1.4.1.2021.10.1.3.2 |
|
Load average (15 min) |
.1.3.6.1.4.1.2021.10.1.3.3 |
|
Swap |
Swap total |
.1.3.6.1.4.1.2021.4.3.0 |
Swap free |
.1.3.6.1.4.1.2021.4.4.0 |
|
Memory |
Mem total |
.1.3.6.1.4.1.2021.4.5.0 |
Mem free |
.1.3.6.1.4.1.2021.4.6.0 |
|
Mem buffer |
.1.3.6.1.4.1.2021.4.14.0 |
|
Mem cached |
.1.3.6.1.4.1.2021.4.15.0 |
These OIDs measure data plane statistics only.
In this section, we will discuss how the internal monitoring system of the FMC can be used to view and retrieve health statistics from your FTD deployment.
A built-in subsystem (health monitor) is automatically configured to obtain the status of various components within the platform both for the FMC itself and managed devices. It is used to track a variety of health indicators to ensure that the hardware and software in the system are working correctly. The health monitor is used to check the status of critical functionality across a Cisco Firepower deployment.
This is achieved by creating a health policy, which contains a collection of tests. The health policy can then be applied to one or more managed devices. The tests are scripts that run at specified intervals using criteria that the administrator has specified. In addition to tests running automatically at specified intervals, it is possible to run all or specific tests on demand.
The health monitor can be used to access health status information for the entire system, a particular appliance, or a particular domain in a multi-domain deployment.
By default, graphs, charts, and tables display health status information in the GUI. Customizable event views allow for quick and easy analysis of health status events gathered by the health monitor.
In addition to the graphical representation of health status information, health alerts can be configured to allow the system to generate alerts to be transmitted to an external monitoring system via email, syslog, or SNMP. Customizable event thresholds allow the administrator to specify when alerts should be generated along with the ability to specify which events should or should not generate alerts.
For more details on FMC health monitoring, please refer to the Health Monitoring Chapter in the latest FTD configuration guide: https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/health_monitoring.html.
Alerts don’t have to be generated only when there is a problem. In fact, you can configure health alerts to generate SNMP traps (for example) to report normal status. That way, your network management station can be used to verify an all green situation.
Health monitor alerts can be associated with one (or more) of the following severity conditions:
● Critical
● Warning
● Normal
● Error
● Recovered
So, for example, an alert can be associated with an event such as memory usage that generates every five minutes showing normal operation (e.g., mem_alert_normal). An additional alert can be associated with the memory usage event that triggers a warning when the memory threshold is breached (mem_alert_warning).
Reminder: Alerts can be delivered via SNMP, syslog, or SMTP depending on user preference.
The health monitor policy allows you to define which health modules to monitor and also specify threshold values for some of them. Some modules apply to the management appliance only, while others apply to both the managed device and the management server.
The first module “Policy Run Time Interval” defines the interval at which the tests are run. The default is five minutes, which is defined by Cisco and will suffice for the majority of deployments. This time can be modified if required.
Health module |
On/off or tuneable |
Notes |
Policy Run Time Interval |
Tuneable |
|
FTD managed device and FMC health modules
Health module |
On/off or tuneable |
Notes |
Appliance Heartbeat |
On/off |
|
CPU Usage |
Both |
|
Card Reset |
On/off |
|
Cluster/Failover Status |
On/off |
Managed device only |
Disk Status |
On/off |
|
Disk Usage |
Both |
|
Health Monitor Process |
Both |
|
Inline Link Mismatch Alarms |
On/off |
|
Interface Status |
On/off |
|
Intrusion and File Event Rate |
Both |
Managed device only |
Link State Propagation |
On/off |
|
Local Malware Analysis |
On/off |
|
Memory Usage |
Both |
|
Platform Faults |
Both |
FP2100 only |
Process Status |
On/off |
|
Reconfiguring Detection |
On/off |
Managed device only |
Time Synchronization Status |
On/off |
|
FMC-only health modules
Health module |
On/off or tuneable |
Notes |
AMP for Endpoints Status |
On/off |
|
AMP for Firepower Status |
On/off |
|
Backlog Status |
On/off |
|
FMC HA Status |
On/off |
|
Host Limit |
Both |
|
Power Supply |
On/off |
(Physical only) |
RRD Server Process |
Both |
|
Security Intelligence |
On/off |
|
Smart License Monitor |
On/off |
|
Series Data Monitor |
On/off |
|
URL Filtering Monitor |
On/off |
|
User Agent Status Monitor |
On/off |
|
VPN Status |
On/off |
|
More information on health monitoring and alerts can be found here: https://www.cisco.com/c/en/us/td/docs/security/firepower/630/configuration/guide/fpmc-config-guide-v63/health_monitoring.html.
More information on FXOS MIBs can be found here: https://www.cisco.com/c/en/us/td/docs/security/firepower/fxos/mib/b_FXOS_MIBRef.html.