cc/td/doc/product/icm/icm46/core
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table Of Contents

Support Facilities

The DDSN

Error Reporting

File Transfer

Support Processing

Serial Alarm Feed

SNMP Feed


Support Facilities


The ICM's Logger collects events and messages from all components of the system. The Logger passes this information to a process called the Listener, which resides at the Cisco Technical Assistance Center (TAC). Depending on the installation, the Logger may connect to the Listener via a dial-up connection or via a normal network connection.

The facilities that allow the Logger to transfer events and messages to the Listener are collectively called the Distributed Diagnostics and Services Network (DDSN). The DDSN allows Support representatives to remotely diagnose, and in some cases remotely fix, problems in your system.

This chapter also provides an overview of the DDSN.

The DDSN

To support the DDSN, each computer running the ICM Logger at a customer site is equipped with a modem. The Logger sends data to the Listener through a dial-up connection using the Windows NT Remote Access Service (RAS). Loggers located at customer premises also allow dial-in connections. This allows Support to connect to either side of the Logger to fully diagnose problems in the system. Figure 8-1 shows the basic parts of the DDSN.

Figure 8-1 DDSN Overview

The DDSN Transfer Process (DTP) keeps EMS events in memory until delivering them to the Listener. To minimize the traffic to the Listener (and particularly the number of dial-up connections that may needed over time), messages are batched and sent periodically. However, if the DTP receives a high priority event, it immediately sends the event to the Listener. If an attempt to establish a RAS connection fails because of a busy phone or no answer, the DTP process periodically tries to re-establish the RAS connection.

You can place exported log files (for example, .txt files) in the export directory on the local machine.

Every 30 minutes, the DTP checks to see if there are EMS events in memory or any new files in the Logger's export directory. When there are new events and files, the DTP sends the events and files to the Listener, establishing a RAS connection, if necessary. Any files sent to the Listener are then deleted from the Logger's export directory.

Error Reporting

The ICM Logger immediately informs the Listener of any significant errors or unexpected conditions it encounters. Error reporting is handled by two processes on the Logger:

Customer Support Forwarding Service (CSFS). Receives events, filters them, and holds then in memory.

DDSN Transfer Process (DTP). (Also known as Phone Home.) Transfers the events and export files to the machine running the Listener. It uses either a dial-up connection and the Remote Access Service (RAS) or a direct network connection. The Listener stores the events in an customer-specific directory on its machine.

ICM software sends two types of data to the Listener:

Event information generated by any process within ICM software.

Export files placed in the Logger's export directory.

The event messages received by the Listener include information about when and where the error occurred and the full message as reported on the event feed.

File Transfer

You can transfer any file to the Listener by copying it to the Logger's export directory. For example, you might transfer a per-process log file that you exported to a text file (.txt). DTP automatically transfers the file to the Listener during the next transfer cycle. At the Listener machine, the file is held in a customer-specific directory.

Support Processing

When your messages arrive at the Listener, they are stored in a customer-specific directory. For error messages, appropriate Support representatives receive automatic and immediate notification. Representatives assigned to a specific customer are notified of all error messages from that customer. Representatives assigned to specific areas of the ICM product are notified of all error messages related to their areas.

Serial Alarm Feed

ICM software provides an optional serial alarm feed that allows you to establish your own alarm/event links to the DDSN. The Serial Alarm Feed process (SERIALFD) uses the Customer Support Forwarding Service (CSFS) to communicate alarm information to an external system. The Serial Alarm Feed process receives events and sends alarms in ASCII format to a communications port on the Logger. Once the SERIALFD process is started, alarm messages are sent to the communications port as they occur.

The Serial Alarm Feed consists of a series of alarm messages that are sent out over a 9600 baud serial connection. The Alarm Messages are formatted as shown in Table 8-1.

Table 8-1 Alarm Message Format

Meaning
Example

Trap Number

6

System Name

GEOXYZRTRB

System Type

2

Process Name

rtr

Trap Severity

6

Date (format: YYYYMMDD)

19961219

Time (format: hh:mm:ss)

16:08:51

Number of Optional Arguments Following

1

1st Optional Argument

pim1

Description

Restarting process pim1 after having delayed restart for 60 seconds

End of message sequence (0xD, 0xA)

[CR][LF]


Note that all the fields in Table 8-1 are delimited by a single SPACE character. All fields are variable length.

You can find information about specific traps in the ICM Management Information Base (MIB). The MIB correlates to the driving table used by the Customer Support Forwarding Service (CSFS). You can look up each trap number in the MIB to see the descriptions and appropriate ASN.1 syntax used to generate the SNMP traps.


Note Refer to the the Cisco ICM Software Alarm MIB User Guide for more information about the ICM MIB.


Your Cisco customer representative can provide you with a copy of the ICM Alarm MIB upon request.

You typically see alarms from the following sources:

Nodes

Processes

Connections

Peripherals

Sessions/Links

Since the Serial Alarm Feed is an alarm process, only events that have triggered a state change in an object are forwarded to the communications port. All other events are discarded. For example, if a process stops, an alarm is generated and forwarded to the communications port. All subsequent alarms indicating that the process has stopped are discarded. When the process restarts, another alarm is generated. The latest alarm indicates a state change, so it is forwarded to the communications port.

SNMP Feed

The SNMP feed is an optional ICM feature that allows you to receive an event feed through an SNMP-compliant interface (TCP/IP). The ICM SNMP Extension Agent takes advantage of the Customer Support Forwarding Service (CSFS) event feed. The SNMP Extension Agent is an ICM-supplied Dynamic Link Library (DLL) that is installed on Loggers. The SNMP Extension Agent receives an event feed from the CSFS process and communicates with the Windows NT SNMP Agent to generate SNMP traps when certain alarmable events occur.

You can find information about specific traps in the ICM Alarm MIB.

Your Cisco customer representative can provide you with a copy of the ICM Alarm MIB upon request.

The SNMP Extension Agent relies on the Windows NT SNMP service. You must install this service on the Logger before you can bring up the SNMP Extension Agent. Once the SNMP service is installed, you can configure it to send SNMP traps to the desired management stations.

Use the Network option in the Windows NT Control Panel to configure the SNMP service. Add the community name "public" and enter the IP addresses (or host names) of the management stations that are to receive traps. Any changes you make in the SNMP configuration screen will not take effect until the SNMP service is restarted.


hometocprevnextglossaryfeedbacksearchhelp

Posted: Mon Dec 6 11:45:45 PST 2004
All contents are Copyright © 1992--2004 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.