Table Of Contents

Monitoring Standalone Content Engines and Transactions

Monitoring Standalone Content Engines

Monitoring Standalone Content Engines with the Cisco Discovery Protocol

Monitoring Standalone Content Engines with SNMP

Understanding the Different Versions of SNMP

Supported MIBs

Downloading MIB Files to Standalone Content Engines

Enabling the SNMP Agent on Standalone Content Engines

Defining SNMP Users for Standalone Content Engines

Configuring Standalone Content Engines to Send SNMP Traps

Disabling the SNMP Agent on Standalone Content Engines

Disabling SNMP Traps on Standalone Content Engines

Monitoring Standalone Content Engines with the ACNS Software Alarms

Alarm Severity Levels

Alarm Overload

Checking for Application Liveness

Configuring SNMP Alarm Traps on Standalone Content Engines

Displaying Information About ACNS Software Alarms

Displaying Details About ACNS Software Alarms

Displaying the History of ACNS Software Alarms

Displaying the Status of ACNS Software Alarms

Monitoring Critical Disk Drives on Standalone Content Engines

Specifying the Disk Error-Handling Threshold

Manually Marking and Unmarking Content Engine Disk Drives

Proactively Monitoring Disk Health with SMART

System Logging with Standalone Content Engines

Displaying the Current Configuration for System Logging

Configuring System Logging on Standalone Content Engines

Configuring System Logging to the Console

Configuring System Logging to Disk

Configuring System Logging to Remote Syslog Hosts

Mapping Syslog Priority Levels to RealProxy Error Codes

Using CiscoWorks2000

Monitoring Transactions with Standalone Content Engines

Displaying Statistics for Particular Protocols

Using ACNS Software Transaction Logs

Enabling Transaction Logging

Logging FTP Client Usernames

Enabling Squid-Style Transaction Logging

Enabling Extended Squid-Style Transaction Logging

Enabling Apache-Style Transaction Logging

Enabling Custom Format Transaction Logging

Logging Windows Domain with Authenticated Usernames

Sanitizing Transaction Logs

Exporting Transaction Log Files

Exporting Transaction Logs to External FTP or STFP Servers

Changing the Transaction Logging Export Settings on Standalone Content Engines

Restarting Export After Receiving a Permanent Error from the External FTP Server

Archiving the Working Log

Disabling Transaction Logging Export on Standalone Content Engines

Monitoring HTTP Request Authentication Failures in Real Time

Configuring the Remote Syslog Host for Real-Time Transaction Logging

Configuring a Transaction Log Facility when Logging to a Remote Syslog Host

Specifying the Transaction Log Entry Type when Logging to a Remote Syslog Host

Displaying the Transaction Log Configuration for Standalone Content Engines

Monitoring the Performance of Specific URLs

Monitoring Standalone Content Engines and Transactions

---

This chapter describes how to monitor locally managed deployments (standalone Content Engines). This chapter contains the following sections:

•Monitoring Standalone Content Engines

•Monitoring Critical Disk Drives on Standalone Content Engines

•System Logging with Standalone Content Engines

•Monitoring Transactions with Standalone Content Engines

•Monitoring the Performance of Specific URLs

---

Note In the ACNS 5.3.1 software and later releases, you can use the Secure File Transfer Protocol (SFTP) to connect to a Content Engine and securely retrieve log files from it.

For complete syntax and usage information for the CLI command used in this chapter, see the Cisco ACNS Software Command Reference, Release 5.5 publication. For information about monitoring a Content Router, Content Distribution Manager, or a Content Engine that is registered with a Content Distribution Manager (as opposed to standalone Content Engines that are not registered with a Content Distribution Manager), see the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.5.

---

Monitoring Standalone Content Engines

It is important that you monitor your Content Engines in order to gauge their performance and to identify any signs that you need to tune their configurations or deploy additional Content Engines. This section describes how use the Simple Network Management Protocol (SNMP) and the ACNS software alarms to monitor standalone Content Engines. Several tools are available to monitor the performance of standalone Content Engines that are running the ACNS 5.2.1 software and later releases. This set of tools includes the Cisco Discovery Protocol (CDP), SNMP, and the ACNS software alarms. For more information, see the following sections:

•Monitoring Standalone Content Engines with the Cisco Discovery Protocol

•Monitoring Standalone Content Engines with SNMP

•Monitoring Standalone Content Engines with the ACNS Software Alarms

Monitoring Standalone Content Engines with the Cisco Discovery Protocol

Cisco Discovery Protocol (CDP) is a device discovery protocol that runs on all Cisco-manufactured devices. With CDP, each device within a network sends periodic messages to all other devices within the network. Devices listen to periodic messages sent by others in order to learn about neighboring devices and determine the status of their interfaces.

With CDP, network management applications can learn the device type and the SNMP agent address of neighboring devices. Applications are then able to send SNMP queries within the network. Also, CiscoWorks2000 discovers the Content Engine by noticing the CDP packets that are sent by the Content Engine after booting.

Content Engine-related tasks require that the Content Engine platform support CDP in order to be able to notify the system manager of the existence, type, and version of the Content Engine platform.

The following example enables CDP implementation on a standalone Content Engine with a single CLI command:

ContentEngine(config)# interface FastEthernet 0/0 cdp enable

Monitoring Standalone Content Engines with SNMP

Simple Network Management Protocol (SNMP) is an interoperable standards-based protocol that allows for external monitoring of the Content Engine through an SNMP agent.

An SNMP-managed network consists of three primary components: managed devices, agents, and management systems.

•A managed device is a network node that contains an SNMP agent and resides on a managed network.

•Managed devices collect and store management information and use SNMP to make this information available to management systems that use SNMP. Managed devices include routers, access servers, switches, bridges, hubs, computer hosts, and printers.

•An SNMP agent is a software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. The SNMP agent gathers data from the Management Information Base (MIB), which is the repository for information about device parameters and network data. The agent can also send traps, or notification of certain events, to the manager.

Each Content Engine that is running the ACNS 5.x software has an SNMP agent that is responsible for gathering information about the Content Engine's device configuration and activity. Before you can access this SNMP information, you must have deployed an SNMP management application on a management station. This SNMP management station is referred to as the SNMP host because it uses SNMP to send the device agent an SNMP Get request to obtain information from the Content Engine.

The SNMP management station and the device agent (the SNMP agent on the Content Engine) use SNMP to communicate, as follows:

1. The SNMP management station (the SNMP host) uses SNMP to request information from the Content Engine.

2. After receiving these SNMP requests, the device agent on the Content Engine accesses a table that contains information about the individual device (the Content Engine). This table, or database, is called a Management Information Base (MIB).

---

Note The SNMP agent on the Content Engine only initiates communication with the SNMP host under unusual conditions; it will initiate communication when it has a trap it needs to send to the host. For more information on this topic, see the "Configuring Standalone Content Engines to Send SNMP Traps" section.

---

3. After locating the specified information in the MIB, the device agent uses SNMP to send the information to the SNMP management station.

Figure 21-1 illustrates these SNMP operations when the Content Engine has been standalone.

Figure 21-1 SNMP Components with a Standalone ACNS Content Engine

Understanding the Different Versions of SNMP

The ACNS 5.x software supports the following versions of SNMP:

•Version 1 (SNMPv1)—This is the initial implementation of SNMP. See the RFC 1157 for a full description of its functionality.

•Version 2 (SNMPv2c)—This is the second release of SNMP, described in RFC 1902. It provides additions to data types, counter size, and protocol operations.

•Version 3 (SNMPv3)—This is the most recent version of SNMP, defined in RFC 2271 through RFC 2275.

SNMP Security Models and Security Levels

SNMPv1 and SNMPv2c do not have any security (that is, authentication or privacy) mechanisms to keep SNMP packet traffic confidential. As a result, packets on the wire can be detected and SNMP community strings compromised.

To solve the security shortcomings of SNMPv1 and SNMPv2c, SNMPv3 provides secure access to Content Engines by authenticating and encrypting packets over the network. The SNMP agent in the ACNS 5.x software supports SNMPv3 as well as SNMPv1 and SNMPv2c.

The following security features are provided in SNMPv3:

•Message integrity—Ensures that nothing has interfered with a packet during transmission.

•Authentication—Determines that the message is from a valid source.

•Encryption—Scrambles the contents of a packet to prevent it from being seen by an unauthorized source.

SNMPv3 provides security models as well as security levels. A security model is an authentication process that is set up for a user and the group in which the user resides. A security level is the permitted level of security within a security model. A combination of a security model and a security level determines which security process is used when an SNMP packet is handled. Three security models are available: SNMPv1, SNMPv2c, and SNMPv3.

Table 21-1 describes the combinations of security models and security levels.

Table 21-1 SNMP Security Models and Security Levels 

Model	Level	Authentication	Encryption	Process
v1	noAuthNoPriv	Community string	No	Uses a community string match for user authentication.
v2c	noAuthNoPriv	Community string	No	Uses a community string match for user authentication.
v3	noAuthNoPriv	Username	No	Uses a username match for user authentication.
v3	AuthNoPriv	Message Digest 5 (MD5) or Secure Hash Algorithm (SHA)	No	Provides authentication based on the Hash-Based Message Authentication Code (HMAC)-MD5 or HMAC-SHA algorithms.
v3	AuthPriv	MD5 or SHA	Yes	Provides authentication based on the HMAC-MD5 or HMAC-SHA algorithms. Provides Data Encryption Standard (DES) 56-bit encryption (packet authentication) based on the cipher block chaining (CBC)-DES (DES-56) standard.

The SNMPv3 agent can be used in the following modes:

•noAuthNoPriv mode (that is, no security mechanisms turned on for packets)

•AuthNoPriv mode (for packets that do not need to be encrypted using the privacy algorithm [DES 56])

•AuthPriv mode (for packets that must be encrypted; privacy requires that authentication be performed on the packet)

Using SNMPv3, users can securely collect management information from their SNMP agents without worrying that the data has been tampered with. Also, confidential information, such as SNMP set packets that change a Content Engine's configuration, can be encrypted to prevent their contents from being exposed on the wire. Also, the group-based administrative model allows different users to access the same SNMP agent with varying access privileges.

Supported MIBs

The ACNS 5.x software implementation of SNMP supports the following MIBs:

•MIB-II

•ENTITY-MIB

•HOST-RESOURCES-MIB

•CISCO-CONTENT-ENGINE-MIB

•CISCO-ENTITY-ASSET-MIB

•CISCO-CONFIG-MAN-MIB

•CISCO-CDP-MIB

---

Note In the ACNS 5.2.1 software and later releases, the CISCO-CONTENT-ENGINE-MIB supports streaming WMT (MMS and MMS-over-HTTP), RealProxy, and Cisco Streaming Engine statistics. Standalone Content Engines support WMT and RealProxy.

---

Cisco Streaming Engine is only supported on Content Engines that are registered with a Content Distribution Manager; Cisco Streaming Engine is not supported on standalone Content Engines. In the ACNS 5.5 software, the CISCO-CONTENT-ENGINE-MIB supports streaming WMT for only MMS-over-HTTP.

---

Note
In the ACNS 5.3.1 software release, the CISCO-CONTENT-ENGINE-MIB was modified to add support for WMT RTSP streaming for Windows Media 9 clients and servers (that is, Windows Media 9 players and Windows Media 9 servers).

In the ACNS 5.2.1 software and later releases, there are six generic alarm traps in the CISCO-CONTENT-ENGINE-MIB for SNMP and Node Health Manager integration. For a list of these six generic alarm traps, see Table 21-5.

---

In the ACNS 5.1.1 software and later releases, you can use IP access control lists (ACLs) to control SNMP access on a Content Engine. For more information about defining IP ACLs, see Chapter 19, "Creating and Managing IP Access Control Lists for Standalone Content Engines."

Downloading MIB Files to Standalone Content Engines

You can download the MIB files for all of the MIBS that are supported by a standalone Content Engine that is running the ACNS 5.x software, from the following Cisco FTP site:

ftp://ftp.cisco.com/pub/mibs/v2

The MIB objects that are defined in each MIB are described in the MIB files at the above FTP site are self explanatory.

Enabling the SNMP Agent on Standalone Content Engines

By default, the SNMP agent on a standalone Content Engine is disabled and an SNMP community string is not defined. The SNMP community string is used as a password for authentication when accessing the SNMP agent on the standalone Content Engine. In order to be authenticated, the Community Name field of any SNMP message sent to the standalone Content Engine must match the SNMP community string defined on the standalone Content Engine.

The SNMP agent on the standalone Content Engine is enabled when an SNMP community string is defined on the Content Engine. You can use the Content Engine GUI or CLI to define an SNMP community string and enable the SNMP agent, as follows:

•From the Content Engine GUI, choose System > SNMP. In the displayed SNMP window, scroll down to the Community field and enter an SNMP community string. Click Update.

•From the Content Engine CLI, use the snmp-server community command:

ContentEngine(config)# snmp-server community comaccess

If the SNMPv3 protocol is going to be used for SNMP requests, the next step is to define an SNMP user account that can be used to access a standalone Content Engine through SNMP. For more information on how to create an SNMPv 3 user account on a standalone Content Engine, see the "Defining SNMP Users for Standalone Content Engines" section.

Defining SNMP Users for Standalone Content Engines

When defining SNMP users for standalone Content Engines, remember the following important points:

•If the SNMPv3 protocol is going to be used for SNMP requests, you must define at least one SNMPv3 user account on the standalone Content Engine in order for the Content Engine to be accessed through SNMP.

•A group defined with the SNMPv1 or SNMPv2c security model should not be associated with SNMP users; they should only be associated with the community strings.

Defining SNMPv3 Users

You can use either the Content Engine GUI or the CLI to define SNMPv3 user accounts on standalone Content Engines.

To use the Content Engine GUI to configure an SNMPv3 user account on a standalone Content Engine, follow these steps:

---

Step 1 From the Content Engine GUI, choose System > SNMP.

The SNMP window for configuring SNMPv1 or SNMPv2 appears.

Step 2 Scroll down to the bottom of the SNMP window. At the bottom of the window, click the SNMPv3 Configuration Click here link.

The SNMP window for configuring SNMPv3 settings (including SNMPv3 user accounts) appears.

Step 3 Scroll down to the SNMPV3 User configuration section of the SNMP v3 window. Use the SNMPV3 user configuration fields and drop-down lists to define new SNMPv3 user accounts on this Content Engine.

a. In the Name field, enter the name of the SNMP user. Use letters, numbers, dashes, and underscores, but no blanks. This is the name of the user on the SNMP host who wants to communicate with the SNMP agent on the Content Engine.

b. In the Group field, enter the name of the group to which the SNMP user belongs.

c. In the Remote SnmpID field, enter the globally unique identifier for a remote SNMP entity (for example, the SNMP network management station) for at least one of the SNMP users.

---

Tip In order to send an SNMPv3 inform message, at least one SNMPv3 user with a remote SNMP ID option must be configured on the Content Engine. The SNMP ID is entered in octet string form. For example, if the IP address of a remote SNMP entity is 192.147.142.129, then the octet string would be 00:00:63:00:00:00:a1:c0:93:8e:81.

---

d. From the Auth-Algorithm drop-down list, choose the algorithm used to authenticate the SNMP user (md5, sha, or no_auth). By default, no_auth for no authentication is chosen.

–Choose md5 for the HMAC-MD5-96 authentication level.

–Choose sha for the HMAC-SHA-96 authentication level.

e. In the optional Auth-Password field, enter the HMAC MD5 user authentication password. This field is only applicable if you chose md5 as the authentication type.

f. In the optional Priv-Password field, enter the HMAC MD5 user private password. This field is only applicable if you chose md5 as the authentication type. This is a string that enables the SNMP agent to receive packets from the host.

Step 4 Click Update to add the new SNMPv3 user account.

The new user account that you just created is listed in the SNMPv3 window.

Step 5 Continue to add more SNMPv3 user accounts. To remove an existing SNMPv3 user account, click the Delete check box next to the account that you want to remove.

Step 6 Click Update again to save your changes to the SNMPv3 user accounts.

---

To use the Content Engine CLI to define an SNMPv3 user account on a standalone Content Engine (the SNMP server), use the snmp-server user global configuration command. Use the no form of this command to remove SNMP access.

snmp-server user name group [auth {md5 password [priv password] | sha password [priv password]} | remote octetstring [auth {md5 password [priv password] | sha password [priv password]}]]

Table 21-2 describes the parameters for the snmp-server user command.

Table 21-2 Parameters for the snmp-server user CLI Command 

Parameter	Description
name	Name of the SNMP user.
group	Group to which the SNMP user belongs.
auth	(Optional) Configures user authentication parameters.
md5	Configures the HMAC MD5 authentication algorithm.
password	HMAC MD5 user authentication password.
priv	(Optional) Configures the authentication parameters for the packet.
password	HMAC MD5 user private password.
sha	Configures the HMAC SHA authentication algorithm.
password	HMAC SHA authentication password.
remote	(Optional) Specifies engine identity of remote SNMP entity to which the user belongs.
octetstring	Engine identity octet string.

In the following example, an SNMPv3 user account is created on the Content Engine. The SNMPv3 user is named acme and belongs to the group named admin. Because this SNMP user account has been set up with no authentication password, the SNMP agent on the Content Engine will not perform authentication on SNMP requests from this user.

ContentEngine(config)# snmp-server user acme admin

Configuring Standalone Content Engines to Send SNMP Traps

You can use either the Content Engine GUI or the CLI to configure standalone Content Engines to send SNMP traps.

From the Content Engine GUI, choose System > SNMP. The SNMP window appears. From the SNMP window, do one of the following:

•To configure the Content Engine SNMPv1 or SNMPv2 agent to send SNMP traps to a specific SNMP host, enter information in the appropriate fields of this window, and click UPDATE.

For example, you must define the SNMP trap host by specifying the hostname or IP address of the SNMP trap host that will be sent in the SNMP trap messages from the Content Engine.

•To configure the Content Engine's SNMP v3 agent to send SNMP traps to a specific SNMP host, scroll down to the bottom of the SNMP window. Click the SNMPv3 Configuration Click here link. The SNMP window for configuring an SNMPv3 agent on the Content Engine appears. Use the SNMPv3 window to configure SNMP traps and SNMP v3 user accounts for this Content Engine.

For more information about configuring SNMPv3 user accounts, see the "Defining SNMPv3 Users" section. For information about the fields in the SNMP windows, click the HELP button in the window.

When using the Content Engine CLI to configure a standalone Content Engine to send SNMP traps, remember the following important points:

•For an SNMP host to receive a trap, both the snmp-server enable traps command and the snmp-server host command for that host must be configured. In addition, SNMP must be enabled with the snmp-server community command.

•The SNMP agent is disabled by default, and a community string is not configured.

To use the Content Engine CLI to configure SNMP traps on a standalone Content Engine, follow these steps:

---

Step 1 Choose one of the security model groups (SNMPv1, SNMPv2c, or SNMPv3) by using the snmp-server group name global configuration command.

snmp-server group name {v1 [notify name] [read name] [write name] | v2c [notify name] [read name] [write name] | v3 {auth [notify name] [read name] [write name] | noauth [notify name] [read name] [write name] | priv [notify name] [read name] [write name]}}

where:

•name	Name of group.
•v1	Specifies the group using the Version 1 Security Model.
•notify	(Optional) Specifies a notify view for the group.
•name	Notify view name.
•read	(Optional) Specifies a read view for the group.
•name	Read view name.
•write	(Optional) Specifies a write view for the group.
•name	Write view name.
•v2c	Specifies the group using the Version 2c Security Model.
•v3	Specifies the group using the User Security Model (SNMPv3).
•auth	Specifies the group using the AuthNoPriv Security Level.
•noauth	Specifies the group using the noAuthNoPriv Security Level.
•priv	Specifies the group using the AuthPriv Security Level.

Step 2 Enable all SNMP traps on the Content Engine.

ContentEngine(config)# snmp-server enable traps

If you do not enter the snmp-server enable traps command, no traps are sent. Use the no form of this command to disable all SNMP traps or only SNMP authentication traps.

Step 3 Specify which host or hosts receive SNMP traps from the Content Engine.

The following example shows how to configure the Content Engine to send all SNMP traps to the host 172.31.2.160 using the community string public:

ContentEngine(config)# snmp-server host 172.31.2.160 public

---

Note To send SNMP traps, you must configure at least one SNMP trap host. In the ACNS 5.1 software and earlier releases, you could only configure up to four SNMP hosts. In the ACNS 5.2.1 software and later releases, you can configure up to eight SNMP hosts on a Content Engine.

---

Step 4 Enable the SNMP agent on the Content Engine, and assign a community string as a password for authentication when you access the SNMP agent on the Content Engine.

The following example shows how to specify comaccess as the password:

ContentEngine(config)# snmp-server community comaccess

---

Tip Any SNMP message sent to the Content Engine must have the Community Name field of the message match the community string defined here in order to be authenticated.

---

The snmp-server community string global configuration command provides view-based access control for SNMPv1, SNMPv2c, and SNMPv3 but also continues to provide backward compatibility between different versions.

In the ACNS 5.x software prior to the ACNS 5.1 software release, the snmp-server community string global configuration command did not have an option to create a community string that allows SNMP messages to execute a set operation on a MIB object. A rw option has been introduced for this purpose. Also, the previous version of the SNMP agent did not provide selective access control to MIB objects. Access to any MIB object was denied or granted based on authentication of the SNMP community string.

With the introduction of view-based access control, it is now possible to configure a community string that grants access to only part of the MIB subtree. To provide backward compatibility with the previous version of this command, a default read group or default write group (if the rw option is specified on the command line) is associated with the community string if no group name is specified. Both of these default groups are hidden from users and not displayed in the configuration file or in the show snmp group EXEC command, but are created during initialization of the SNMP agent.

---

Disabling the SNMP Agent on Standalone Content Engines

To disable the SNMP agent on standalone Content Engines, enter the no snmp-server global configuration command:

ContentEngine(config)# no snmp-server

To disable the SNMP agent and to remove the previously defined community string, enter the no snmp-server community global configuration command:

ContentEngine(config)# no snmp-server community

Disabling SNMP Traps on Standalone Content Engines

To disable all SNMP traps on standalone Content Engines, enter the no snmp-server enable traps global configuration command:

ContentEngine(config)# no snmp-server enable traps

To disable the sending of the MIB-II SNMP authentication trap, enter the no snmp-server enable traps snmp authentication command.

Monitoring Standalone Content Engines with the ACNS Software Alarms

Traditionally SNMP is used to report error conditions by generating SNMP traps. ACNS 5.x continues to use this monitoring method, as described in the "Monitoring Standalone Content Engines with SNMP" section.

In the ACNS 5.2.1 software and later releases, the Node Health Manager feature is supported. The Node Health Manager enables ACNS applications to raise alarms to draw attention to significant problems. The Node Health Manager, which is the data repository for such alarms, aggregates the health and alarm information for the applications, services (for example, the cache service) and resources (for example, disk drives) that are being monitored on the Content Engine. For example, this new feature gives you a way to determine if a monitored application (for example, the HTTP proxy caching service) is alive on the Content Engine. These alarms are referred to as the ACNS software alarms.

In the ACNS 5.2.1 software and later releases, the following Content Engine applications can generate an ACNS software alarm:

•Node Health Manager (Alarm overload condition and Node Manager aliveness)

•Node Manager for service failures (aliveness of monitored applications)

•System Monitor (sysmon) for disk failures

Alarms that have been raised on a Content Engine can be listed using the Content Engine CLI commands in Table 21-3. SNMP traps are sent all raised and cleared alarms. The type of SNMP trap sent varies by alarm.

---

Note If the Content Engine is registered with a Content Distribution Manager, the Node Health Manager also sends a notification about the alarm to the Content Distribution Manager. For more information on this topic, see the Cisco ACNS Software Configuration Guide for Centrally Managed Deployments, Release 5.5.

---

In the ACNS 5.2.1 software release, several CLI commands were added to allow you to systematically identify the source of an ACNS software alarm (the cause of the problem). (See Table 21-3.) You can use these CLI commands to identify the source of a problem without searching through numerous ACNS software logs.

Table 21-3 List of Show Alarms CLI Commands 

CLI Command	Description	More Information
show alarm	Displays a list of all currently raised ACNS software alarms (critical, major, and minor alarms) on the Content Engine.	See the "Displaying Information About ACNS Software Alarms" section.
show alarm critical	Displays a list of only currently raised ACNS software critical alarms on the Content Engine.	See the "Displaying Information About ACNS Software Alarms" section.
show alarm major	Displays a list of only currently raised ACNS software major alarms on the Content Engine.	See the "Displaying Information About ACNS Software Alarms" section.
show alarm minor	Displays a list of the currently raised ACNS software minor alarms on the Content Engine.	See the "Displaying Information About ACNS Software Alarms" section.
show alarm detail	Displays detailed information about the currently raised ACNS software alarms.	See the "Displaying Details About ACNS Software Alarms" section.
show alarms history	Displays a history of ACNS software alarms that have been raised and cleared on the Content Engine. The CLI retains the last 100 alarm raise and clear events only.	See the "Displaying the History of ACNS Software Alarms" section.
show alarms status	Displays the counts for the currently raised ACNS software alarms on the Content Engine. Also lists the alarm overload state and the alarm overload settings.	See the "Displaying the Status of ACNS Software Alarms" section.

---

Note On standalone Content Engines, information about the ACNS software alarms is available through the Content Engine CLI and also through SNMP. See Table 21-3 for a list of the CLI commands that you can use to access this alarm information for a standalone Content Engine.

---

Alarm Severity Levels

There are three levels of ACNS software alarms. (See Table 21-4.)

Table 21-4 Levels of Alarm Severity for ACNS Software Alarms 

Alarm Level	Description
Critical	Alarms that affect the existing traffic through the Content Engine, and are considered fatal (Content Engine cannot recover and continue to process traffic).
Major	Alarms that indicate a major service (for example, the cache service) is damaged or lost. Urgent action is necessary to recover this service. However, other node components are fully functional and the existing service should be minimally impacted.
Minor	Alarms that indicate a condition that will not affect a service (a non-service-affecting condition) occurred but that corrective action is required in order to prevent a serious fault from occurring.

The output of the show alarms history EXEC command includes the severity of the ACNS software alarm:

ContentEngine# show alarms history

    Op Sev Alarm ID             Module/Submodule     Instance

    -- --- -------------------- -------------------- --------------------

  1 C  Mi  servicedead          nodemgr              mediacache

  2 C  Mi  servicedead          nodemgr              cache

  3 R  Mi  servicedead          nodemgr              mediacache

  4 R  Mi  servicedead          nodemgr              cache

  5 C  Mi  servicedead          nodemgr              rpc_httpd

  6 R  Mi  servicedead          nodemgr              rpc_httpd

  7 C  Mi  servicedead          nodemgr              rpc_httpd

  8 R  Mi  servicedead          nodemgr              rpc_httpd

  9 C  Mi  servicedead          nodemgr              mediacache

 10 C  Mi  servicedead          nodemgr              cache

 11 R  Mi  servicedead          nodemgr              mediacache

 12 R  Mi  servicedead          nodemgr              cache

 13 C  Mi  servicedead          nodemgr              cache

 14 C  Mi  servicedead          nodemgr              mediacache

 15 C  Mi  servicedead          nodemgr              rtspg

 16 R  Mi  servicedead          nodemgr              cache

 17 R  Mi  servicedead          nodemgr              mediacache

 18 R  Mi  servicedead          nodemgr              rtspg

Op - Operation: R-Raised, C-Cleared

Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor

Alarm Overload

In the ACNS 5.2.1 software and later releases, Content Engines can track the rate of incoming alarms from the Node Health Manager. If the rate of incoming alarms exceeds the high-water mark (HWM), then the Content Engine enters an alarm overload state. When a standalone Content Engine is in an alarm overload state, then the following occurs:

•SNMP traps for subsequent alarm raise and clear operations are suspended. The trap for the raise alarm-overload alarm and the clear alarm-overload alarm are sent; however traps related to alarm operations between the raise alarm-overload alarm and the clear alarm-overload alarm operations are suspended.

•Alarm overload raise and clear notifications are not blocked.

•The Content Engine remains in an alarm overload state if the rate of incoming alarms decreases to the point that the alarm rate is less than the low-water mark (LWM).

Checking for Application Liveness

The Node Manager tracks the liveness of applications that it creates on the Content Engine (for example, the HTTP cache application, the WMT streaming application, and the RTSP gateway (RTSPG) streaming application). When the Node Manager detects the termination of a spawned application, it raises an alarm. An application is considered dead when the Node Manager does not receive keepalives from the application.

When an application dies, the Node Manager raises a servicedied alarm to report the condition, and then it restarts the service. If the service continues to run for a short time (typically 10 seconds), the servicedied alarm is cleared.

If the application dies again after restarting, the servicedied alarm continues to be raised and the Node Manager attempts to restart it. Restarts are done typically a maximum of 10 times by the Node Manager. After that, the Node Manager raises a svcdisabled alarm for the service, clears the 'servicedied' alarm, and it stops restarting the service.

To restart the service, you must unconfigure and configure the features (for example, in the case of the NTP service, enter the no ntp server hostname | IP address global configuration command to unconfigure the NTP service, and then enter the ntp server hostname | IP address global configuration command to reconfigure the NTP service.

Configuring SNMP Alarm Traps on Standalone Content Engines

You can configure a Content Engine to generate an SNMP trap for a specific alarm condition. You can configure the generation of SNMP alarm traps on standalone Content Engines based on the following:

•The severity of the alarm (critical, major, or minor)

•The action (the alarm is raised or cleared)

In the ACNS 5.2.1 software release, the following six generic alarm traps were added to the CISCO-CONTENT-ENGINE-MIB (the CCE MIB). See Table 21-5.

Table 21-5 Generic Alarm Traps 

Name of Alarm Trap	Severity	Action	CLI Command To Enable Alarm Trap
cceAlarmCriticalRaised	Critical	Raised	snmp-server enable traps alarm raise-critical
cceAlarmCriticalCleared	Critical	Cleared	snmp-server enable traps alarm clear-critical
cceAlarmMajorRaised	Major	Raised	snmp-server enable traps alarm raise-major
cceAlarmMajorCleared	Major	Cleared	snmp-server enable traps alarm clear-major
cceAlarmMinorRaised	Minor	Raised	snmp-server enable traps alarm raise-minor
cceAlarmMinorCleared	Minor	Cleared	snmp-server enable traps alarm clear-minor

---

Note By default, these six general alarm traps are disabled.

---

These six general alarm traps provide SNMP and Node Health Manager integration. Each of these six alarm traps can be enabled or disabled through the Content Engine CLI. In the ACNS 5.2.1 software and later releases, the snmp-server enable traps global configuration command includes an alarm option.

ContentEngine(config)# snmp-server enable traps alarm ?

  clear-critical  Enable clear-critical alarm trap

  clear-major     Enable clear-major alarm trap

  clear-minor     Enable clear-minor alarm trap

  raise-critical  Enable raise-critical alarm trap

  raise-major     Enable raise-major alarm trap

  raise-minor     Enable raise-minor alarm trap

In the following example, the Content Engine (the SNMP server) is configured to generate an SNMP trap if a critical alarm is cleared:

ContentEngine(config)# snmp-server enable traps alarm clear-critical

Displaying Information About ACNS Software Alarms

To display information about all of the currently raised critical, major, and minor alarms for a standalone Content Engine, enter the show alarm EXEC command. If there are no alarms currently raised on the Content Engine, the output indicates "None." The following shows a sample output:

ContentEngine# show alarm

Critical Alarms:

----------------

None

Major Alarms:

-------------

None

Minor Alarms:

-------------

None

You can also display information for only a specific level of ACNS software alarms that are currently raised on the Content Engine, as follows:

•To display information about only the critical alarms, enter the show alarm critical EXEC command.

•To display information about only the major alarms, enter the show alarm major EXEC command.

• To display information about only the minor alarms, enter the show alarm minor EXEC command.

---

Note For a description of the various severity levels for alarms (critical, major, and minor), see Table 21-4.

---

Displaying Details About ACNS Software Alarms

To display details about the currently raised SNMP alarms, enter the show alarm detail EXEC command. This command allows you to identify more information about a particular alarm.

Displaying the History of ACNS Software Alarms

To display a history of ACNS software alarms that have been raised and cleared on a standalone Content Engine, enter the show alarms history EXEC command:

ContentEngine# show alarms history

    Op Sev Alarm ID             Module/Submodule     Instance

    -- --- -------------------- -------------------- --------------------

  1 C  Mi  servicedead          nodemgr              mediacache

  2 C  Mi  servicedead          nodemgr              cache

  3 R  Mi  servicedead          nodemgr              mediacache

  4 R  Mi  servicedead          nodemgr              cache

  5 C  Mi  servicedead          nodemgr              rpc_httpd

  6 R  Mi  servicedead          nodemgr              rpc_httpd

  7 C  Mi  servicedead          nodemgr              rpc_httpd

  8 R  Mi  servicedead          nodemgr              rpc_httpd

  9 C  Mi  servicedead          nodemgr              mediacache

 10 C  Mi  servicedead          nodemgr              cache

 11 R  Mi  servicedead          nodemgr              mediacache

 12 R  Mi  servicedead          nodemgr              cache

 13 C  Mi  servicedead          nodemgr              cache

 14 C  Mi  servicedead          nodemgr              mediacache

 15 C  Mi  servicedead          nodemgr              rtspg

 16 R  Mi  servicedead          nodemgr              cache

 17 R  Mi  servicedead          nodemgr              mediacache

 18 R  Mi  servicedead          nodemgr              rtspg

Op - Operation: R-Raised, C-Cleared

Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor

To display additional information about an alarm, enter the show alarms history detail support EXEC command:

Content Engine# show alarms history detail support 

     Op Sev Alarm ID             Module/Submodule     Instance

     -- --- -------------------- -------------------- --------------------

   1 C  Mi  servicedead          nodemgr              rtspg              

     Jul  2 18:22:04.577 UTC, Processing Error Alarm, #000001, 2000:330004

     nodemgr: The rtspg service has died.

     /alm/min/nodemgr/-service_name-/servicedead:

         -service name- service has died.

     Explanation:

         The node manager found the specified service to be dead. 

         Attempts will be made to restart this service.

     Action:

         Examine the syslog for messages relating to cause of service

          death. The alarm will be cleared if the service stays

         alive  and does not restart in a short while.

   2 R  Mi  servicedead          nodemgr              rtspg              

     Jul  2 18:21:54.231 UTC, Processing Error Alarm, #000001, 2000:330004

     nodemgr: The rtspg service has died.

     /alm/min/nodemgr/-service_name-/servicedead:

         -service name- service has died.

     Explanation:

         The node manager found the specified service to be dead. 

         Attempts will be made to restart this service.

     Action:

         Examine the syslog for messages relating to cause of service

          death. The alarm will be cleared if the service stays

         alive  and does not restart in a short while.

Op - Operation: R-Raised, C-Cleared

Sev - Severity: Cr-Critical, Ma-Major, Mi-Minor

Displaying the Status of ACNS Software Alarms

To display the counts for all currently raised alarms on the Content Engine, enter the show alarms status EXEC command. The following sample output shows the number of currently raised ACNS software alarms. The output also includes information about the alarm overload settings (for example, if overload detection is currently enabled or disabled on the Content Engine).

ContentEngine# show alarms status

Critical Alarms :          0

Major Alarms    :          0

Minor Alarms    :          0

Overall Alarm Status : None

Device is NOT in alarm overload state.

Device enters alarm overload state @   10 alarms/sec.

Device exits alarm overload state  @    1 alarms/sec.

Overload detection is DISABLED.

Monitoring Critical Disk Drives on Standalone Content Engines

To operate properly, the Content Engine depends on the following critical disk drives:

•The first disk drive that is referred to as "disk00."

•The disk drive that contains the first sysfs (system file system) partition.

The sysfs partition is used to store log files, including transaction logs, system logs (syslogs), and internal debugging logs. It can also be used to store image files and configuration files on a Content Engine.

---

Note The term critical drive is defined as a disk drive that is either disk00 or a disk drive that contains the first sysfs partition. A critical drive can be different based on the Content Engine model. For example, with smaller, single disk drive Content Engines there is only one critical disk drive; with higher-end Content Engines that have more than one disk drive, there may be more than one critical disk drive on the Content Engine.

---

When a Content Engine is booted and a critical disk drive is not detected at system startup time, the ACNS system on the Content Engine runs at a degraded state. If one of the critical disk drives goes bad at run time, the applications might malfunction, suspend operations, or stop operating, or the ACNS system might suspend or stop operations. Consequently, it is important that the critical disk drives on a Content Engine are monitored and that disk drive errors are reported.

With an ACNS system, a disk device error is defined as any of the following events:

•A Small Computer Systems Interface (SCSI) or Integrated Drive Electronics (IDE) device error is printed by Linux kernel.

•A disk device access by an application (for example, an open(2), read(2), or write(2) system call) fails with an EIO error code.

•A disk device that existed at startup time is not accessible at run time.

In the ACNS 5.2.1 software and later releases, you can monitor Content Engine disk drives. Disk status is recorded in flash (non-volatile storage). When an error on a Content Engine disk device occurs, a message is written to the system log (syslog) if the sysfs partition is still intact, and an SNMP trap is generated if SNMP is configured on the Content Engine.

In addition to tracking the state of critical disk drives, you can define a disk device error-handling threshold on the Content Engine. If the number of disk device errors reaches the specified threshold, the corresponding disk device is automatically marked as bad. The ACNS system does not stop using the bad disk device immediately; it stops using the bad disk drive after the next reboot.

If the specified threshold is exceeded, the Content Engine either records this event or reboots. If the automatic reload feature is enabled and this threshold is exceeded, then the ACNS system automatically reboots the Content Engine. For more information about specifying this threshold, see the "Specifying the Disk Error-Handling Threshold" section.

---

Note You can also manually mark a disk drive as bad or good by using the disk drive mark EXEC command. For more information on this topic, see the "Manually Marking and Unmarking Content Engine Disk Drives" section.

---

In the ACNS 5.2.1 software release, support for remapping bad (but unused) sectors on a SCSI drive was added. In the ACNS 5.3.1 software and later releases, this capability includes IDE and Serial Advanced Technology Attachment [SATA] drives. For more information on this topic, see the Cisco ACNS Software Upgrade and Maintenance Guide, Release 5.x.

Specifying the Disk Error-Handling Threshold

In the ACNS 5.2.1 software and later releases, you can configure a disk error-handling threshold. This threshold determines how many disk errors can be detected before the disk drive is automatically marked as bad. By default, this threshold is set to 10.

To change the default threshold, use the disk error-handling threshold global configuration command. Valid values are from 0 through 100. Specify 0 if you never want the disk drive to be marked as bad.

In the following example, five