Remote Management Tools

Network management software, such as CiscoWorks IP Telephony Environment Monitor (ITEM) or syslog servers, performs specific tasks to monitor and manage the health and availability of devices in a network. These tools are typically used in large-scale data networks (such as computer networks and telecommunication networks).

CiscoWorks ITEM Overview

CiscoWorks ITEM is a powerful suite of applications and tools that continuously evaluate and report on the operational health of the Cisco IP telephony implementation. CiscoWorks ITEM is used to manage Cisco IOS software-based IP telephony environments. CiscoWorks ITEM provides the following:

• Proactive health and fault monitoring of converged IP networks and IP telephony implementations
• Powerful tools to effectively manage the day-to-day customer care responsibilities of help-desk personnel
• The ability to capture performance and capacity management data

CiscoWorks ITEM consists of a product suite:

• CiscoWorks IP Telephony Monitor (ITM) Monitors Cisco voice elements in the network to alert operations personnel to potential problems and to help minimize downtime. It also includes CiscoWorks Common Services, a common foundation for data storage, login, access privileges, and navigation and launch management for all CiscoWorks applications.
• CiscoWorks IP Phone Information Utility (IPIU) Provides operational status and implementation details about an individual IP phone. It also provides security reports that document IP phone moves, adds, and changes, as well as information about the physical and logical connections of every Cisco IP Phone installed in a given network.
• CiscoWorks IP Phone Help Desk Utility (IPHDU) Reports operational status and implementation details about individual IP phones. It works in conjunction with IPIU to make read-only access to Cisco IP Phone installation details available to help-desk personnel.
• CiscoWorks ITEM Gateway Statistics Utility (GSU) Collects performance and behavior statistics about IP telephony gateways controlled by Cisco CallManager and Cisco IOS software, which can be processed by third-party software to produce utilization and capacity management reports.
• CiscoWorks WAN Performance Utility (WPU) Measures the performance, latency, and availability of multiprotocol IP networks on an end-to-end and hop-by-hop (router-to-router) basis.

CiscoWorks ITEM also provides real-time fault detection and determination about the underlying Cisco IP fabric on which the IP telephony implementation executes. CiscoWorks ITEM reports faults that occur on Cisco network devices, often identifying problems before users of network services realize that a problem exists. CiscoWorks ITEM supports more than 200 types of the most popular Cisco routers, switches, access servers, and hubs. For each of these supported devices, CiscoWorks ITEM automatically looks for a broad spectrum of common problems at the device and VLAN level, all without ever requiring operations managers to write rules or set polling or threshold values. CiscoWorks ITEM can listen to traps or can send polls and pings to get information for devices. CiscoWorks ITEM can send alerts and events automatically to an e-mail client or a pager. To monitor the network, CiscoWorks ITEM can be accessed via a web-based interface or a CiscoWorks desktop client.

Network management systems (NMSs) use Simple Network Management Protocol (SNMP), an industry-standard interface, to exchange management information between network devices.

Simple Network Management Protocol

SNMP is an application-layer protocol, part of the TCP/IP protocol suite. SNMP enables administrators to remotely manage network performance, find and solve network problems, and plan for network growth. There are three versions of SNMP:

• SNMP Version 1 (SNMPv1)
• SNMP Version 2 (SNMPv2)
• SNMP Version 3 (SNMPv3)

SNMPv1 and SNMPv2 have a number of common features, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of SNMPv3 is pending.

SNMP Basics

An SNMP-managed network consists of three key components:

• Managed devices A managed device designates a network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and make it available by using SNMP.
• Agents An agent, as network management software, resides on a managed device. An agent contains local knowledge of management information and translates it into a form that is compatible with SNMP.
• NMSs An NMS comprises an SNMP management application together with the computer on which it runs. An NMS executes applications that monitor and control managed devices. An NMS provides the bulk of the processing and memory resources that are required for network management. These NMSs share compatibility with Cisco CallManager:

  - CiscoWorks2000

  - HP OpenView

  - Third-party applications that support SNMP and Cisco CallManager SNMP interfaces

This list specifies Cisco CallManager SNMP trap messages that are sent to an NMS that is specified as a trap receiver:

• Cisco CallManager failed
• Phone failed
• Phones status update
• Gateway failed
• Media resource list exhausted
• Route list exhausted
• Gateway Layer 2 change
• Quality report
• Malicious call

SNMP itself is a simple request-and-response protocol. NMSs can send multiple requests without receiving a response. Table 34-1 defines six SNMP operations.

Table 34-1. SNMP Operations

Operation	Definition
Get	Allows the NMS to retrieve an object instance from the agent.
GetNext	Allows the NMS to retrieve the next object instance from a table or list within an agent. In SNMPv1, when an NMS wants to retrieve all elements of a table from an agent, it initiates a Get operation, followed by a series of GetNext operations.
GetBulk	Makes it easier to acquire large amounts of related information without initiating repeated get-next operations. GetBulk (new in SNMPv2) was designed to virtually eliminate the need for GetNext operations.
Set	Allows the NMS to set values for object instances within an agent.
Trap	Allows the agent to asynchronously inform the NMS of some event.
Inform	Allows one NMS to send Trap information to another (new in SNMPv2).

 

SNMP Configuration on Cisco CallManager

Administrators have to enable SNMP for each device in the network that they want to monitor. For example, if you want to monitor Cisco CallManager with SNMP, on the Cisco CallManager server, click Start > Programs > Administrative Tools > Services. From the Service menu, search for the SNMP service and open the service to configure it. The SNMP Service Properties window shown in Figure 34-1 opens.

Figure 34-1. CallManager SNMP Service Configuration

Cisco CallManager supports SNMPv1 and SNMPv2. SNMPv1 lacks authentication capabilities (SNMPv2 increases the security capabilities of SNMP, and SNMPv3 supports authentication and encryption), which results in vulnerability to a variety of security threats:

• Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity.
• Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations.
• Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity.
• Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents.

Because SNMPv1 does not implement authentication, many vendors do not implement Set operations, thus reducing SNMP to a monitoring facility.

The first thing you need to do to configure SNMP management is to enable SNMP access. Enable access by configuring community strings, which act somewhat like passwords. The difference is that there can be several community strings and that each of them can grant a different form of access.

A community string can be the following:

• Read-only Gives read access to all objects in the MIB except the community strings but does not allow write access
• Read-write Gives read and write access to all objects in the MIB but does not allow access to the community strings
• Read-write-all Gives read and write access to all objects in the MIB, including the community strings

To define the SNMP read community string, complete these steps:

Step 1.	Choose Start > Programs > Administrative Tools > Services.
Step 2.	Choose the SNMP service, double-click the service name, and choose Security.
Step 3.	In the Security window, define community strings and assign them read permission.

This would now be the read community string a remote system could use to view various attributes of the Cisco CallManager server. In the example shown in Figure 34-2, the community string is "item."

Figure 34-2. CallManager SNMP Community String Configuration

Cisco Systems supports numerous Management Information Bases (MIBs) that organize and distribute information for a variety of network management devices.

You can use the MIB table that supports Cisco CallManager to provide all of the management interfaces for monitoring and managing your Cisco CallManager network. This MIB table is periodically updated, reflecting the current status of your Cisco CallManager network:

• CISCO-CCM-MIB To perform network management, you can use the CISCO-CCM-MIB to get provisioning and statistical information about Cisco CallManager, its associated devices (for example, IP phones and gateways), and its configuration.
• CISCO-CDP-MIB You can use the Cisco CallManager SNMP agent to implement the Cisco Discovery Protocol MIB, CISCO-CDP-MIB. This MIB enables Cisco CallManager to advertise itself to other Cisco devices on the network, allowing discovery of other Cisco CallManager installations on the network.

Note

To get more information about the MIB tables, go to Cisco.com and search for CISCO-CCM-MIB.

 

Syslog Overview

Syslog allows logging of events across the network to various destinations. It provides an orderly presentation of information that assists in the diagnosis and troubleshooting of system problems. Theses messages can be saved in a file or sent to, for example, a CiscoWorks server, a third-party syslog server (such as Kiwi Syslog Daemon), or the host itself.

Tip

Kiwi Syslog Daemon is a freeware Windows syslog server. It receives, logs, displays, and forwards syslog messages from hosts, such as routers, switches, UNIX hosts, and any other syslog-enabled device. For more information, go to http://www.kiwisyslog.com.

When the local host is used, Remote Syslog Analyzer Collector (RSAC) software must be installed. RSAC can be installed on a remote UNIX or Microsoft Windows 2000 or Windows NT machine to process syslog messages.

Syslog Configuration in Cisco CallManager

Cisco CallManager syslog messages are configured in Cisco CallManager Serviceability. To configure alarms, use the Cisco CallManager Serviceability web page and select Alarm > Configuration. After selecting your server and the CallManager service, the Alarm Configuration window shown in Figure 34-3 opens. To enable syslog messages, simply check the Enable Alarm check box under the Syslog Trace section and enter the IP address of your syslog server.

Figure 34-3. CallManager Syslog Configuration

Table 34-2 lists alarm events that can be configured in the alarm trap.

Table 34-2. Configurable Alarm Events

Name	Destination Description
Enable Alarm for Event Viewer	Windows 2000 Event Viewer program. The program logs Cisco CallManager errors in the application logs within Event Viewer, and provides a description of the alarm and a recommended action.
Enable Alarm for Syslog	Cisco CallManager Syslog capabilities. Check the Enable Alarm check box in the Syslog Trace area of the Alarm Configuration window to enable the syslog messages and configure the syslog server name. If this destination is enabled and no server name is specified, Cisco CallManager sends syslog messages to the local host. Cisco CallManager stores alarm definitions and recommended actions in a Standard Query Language (SQL) server database. The system administrator can search the database for definitions of all the alarms. The definitions include the alarm name, description, explanation, recommended action, severity, parameters, and monitors. This box is unchecked by default.
Enable Alarm for System Diagnostic Interface (SDI) Trace	The SDI trace library. Ensure that this alarm destination is configured in Trace configuration of Cisco CallManager Serviceability.
Enable Alarm for Signal Distribution Layer (SDL)	The SDL trace library. This destination applies only to the Cisco CallManager and Cisco CTIManager services. Configure this alarm destination using Trace SDL configuration.

Table 34-3 lists alarm levels used by Cisco CallManager.

Alarm Event Levels

Level	Name	Description
7	Emergency	This level designates the system as unusable.
6	Alert	This level indicates that immediate action is needed.
5	Critical	Cisco CallManager detects a critical condition.
4	Error	This level signifies that an error condition exists.
3	Warning	This level indicates that a warning condition is detected.
2	Notice	This level designates a normal but significant condition.
1	Informational	This level designates information messages only.

The Cisco CallManager Serviceability Alarms window provides a web-based interface that has two main functions:

• To configure alarms and events
• To provide alarm message definitions

Both functions assist the system administrator and support personnel in troubleshooting Cisco CallManager problems. Alarms can be configured for Cisco CallManager servers in a cluster and for services for each server, such as Cisco CallManager, Cisco TFTP, and Cisco CTIManager.

Alarms can be forwarded to a Serviceability Trace file. The administrator configures alarms and trace parameters and provides the information to a Cisco TAC engineer. Administrators can direct alarms to the Windows 2000 Event Log, syslog, SDI trace log file, SDL trace log file (for Cisco CallManager and CTIManager only), or to all these destinations.

Dependency Records