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:

CiscoWorks ITEM consists of a product suite:

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:

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:

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

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:

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:

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:

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:

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

Категории