Table of Contents

Introduction
Related Documentation
New Features and Enhancements in Cisco Info Center 1.2
CWM, BPX/IGX/IPX, MGX and Platform Versions Compatibility Notes
Sun Platform Requirements

Minimum Hardware Requirement
Additional System Requirement

Notes, Cautions, and Limitations

Installation
Upgrading CIC
Removing CIC
Verifying, Starting, and Restarting the CIC Processes

Starting CIC Processes
Starting the License Server

Third Party Mediators
CWM Mediators
Syslog Mediators
CiscoView
Informix Database
Network Configuration
Service and Network Agents
Automation
Filter
Tools

CIC and HPOV Severity Level Assignments
HP OpenView Requirements
Third Party Product Limitations Notes
Cisco Info Center 1.2 Known Problems
New CIC 1.2 Supported Alarms
Info Center Syslog Rules File for Cisco IOS Devices (Routers)

Cisco IOS Event Format
Severity Mapping
Installation Issues
IP Addressing
Classes, NEType
IOS Rules File Parsing

Cisco Connection Online
Documentation CD-ROM

Release Notes for Cisco Info Center Release 1.2

I

These release notes provide information about the Cisco Info Center (CIC) version 1.2 release.

Introduction

Cisco Info Center is a Service-Level Management (SLM) system that provides a consolidated view of enterprise-wide events and status information. It collects event streams or messages from many different data sources and presents a single, consistent view of the current state of all Cisco Info Center managed systems. It distributes the event information to the operators and administrators responsible for monitoring service levels.

This information can then be:

• Assigned to operators

• Passed on to help desk systems

• Logged in a database

• Replicated on a remote Cisco Info Center system

• Used to trigger automatic responses to certain events.

Cisco Info Center allows diverse management platforms, applications, and Internet protocols to be brought together to provide the administrator a single point of monitoring those platforms and applications. Cisco Info Center does not replace the management platforms. It instead compliments them by providing an enterprise wide event/fault and status exchange. Cisco Info Center can also tie together domain limited network management platforms in remote locations.

Cisco Info Center tracks the state of events in a high performance distributed database and presents information of interest to specific users through individually configurable filters and views. Cisco Info Center Automation functions can be used to perform intelligent processing on the current state of managed objects. Cisco Info Center can build upon existing management systems or applications, therefore, it utilizes existing management skills and minimizes deployment time.

Related Documentation

The following documents are available on the Cisco Documentation CD-ROM and are companion documents to this Release Notes:

• Cisco Info Center Installation and Configuration

• Cisco Info Center Administrator Reference

• Cisco Info Center Mediator and Gateway Reference

• Cisco Info Center User Guide

The following list of documents contains additional information which may help you more fully understand the material described in this manual:

• Cisco WAN Manager Installation Guide

• Cisco WAN Manager Database Interface Guide

• Cisco WAN Manager SNMP Proxy Agent

• Cisco WAN Manager Operations Guide

• Internetworking Technology Overview

• Internetworking Terms and Acronyms

New Features and Enhancements in Cisco Info Center 1.2

Cisco Info Center Release 1.2 includes the following new features and enhancements.

• Cisco WAN Manager (CWM) 9.1.09, 9.2.03-9.2.05 support

The enhanced CWM support includes:

• Pre and Post CWM 9.1.09 sysobjid support

• QoS ATM-FR connection support

• Add/Modify/Delete alarms (20050-20067)

• Health Monitor alarms (28000-28075)

• Name change from SV+ to CWM reflecting product name change.

• New User Connection alarm format (25013-25018)

• Node reachability (25302-25303)

• IGX, BPX 8600 9.2 support

The enhanced IGX and BPX support includes:

• Models number support

• AIS, OAM loopback support (25013-25018)

• Automatic Protection Switching (APS) alarms support for BXM (20100-20107)

• CE - ATM connection support (25013-25018)

• New UXM back cards

• VSI Controller alarms (30000-30102)

• Virtual Trunking alarms support for BNI, BXM, UXM (20012)

• MGX 8220 5.0 support

The enhanced MGX 8220 support includes:

• AIS, OAM loopback support (50311)

• ATM Forum compliant IMATM, AUSM-8-B and alarms (50230-50251)

• Axis product name change to MGX8220

• FRSM-VHS (FRSM-2E3, FRSM-2CT3) and alarms (50381-50389)

• Hard disk diagnosis (MGX 8220 5.0) (50311-50313)

• MGX 8850 1.2 support

The MGX 8850 support includes:

• Power supply alarm (50024)

• Axis service modules

• PXM card, alarms and connections (50980-51208)

• RPM card, alarms and connections (50191-50200)

• Cisco IOS Syslog Message Integration and Enhancements to support the Cisco 3810, Cisco 7200, Cisco 7500, and GSR

• Installation enhancements, including

  • Solaris 2.6 Pkgadd/Pkginfo/Pkgrm Enhancement for CIC 1.2 Installation

  • Java-based INSTALL SHIELD support

  • Removal of CWM dependency as part of installation option

• Upgrade support from CIC 1.1 to CIC 1.2. There is no upgrade support from CIC 1.0.

• Availability upon request of the CIC multi-byte character patch for multi-language support.

CWM, BPX/IGX/IPX, MGX and Platform Versions Compatibility Notes

Cisco Info Center 1.2 operates with SV+ 9.0, 9.1, CWM 9.2.03-9.2.05, IPX 9.1 BPX/IGX release 9.0, 9.1, 9.2. MGX 8220 release 4.0, 4.1, 5.0, and MGX 8850 1.2 for all supported features.

Table 1 summarizes the supported combinations. CIC 1.2 has been tested with CWM version 9.2.03-9.2.05, CiscoView 4.2, IPX 9.1.03, BPX/IGX 9.2, MGX 8220 5.0, and MGX 8850 1.2 with HP Network Node Manager 5.01 in Solaris 2.6 and SV+ 9.1 in Solaris 2.5.1.

Sun Platform Requirements

This section describes the system requirements for the Cisco Info Center 1.2 release.

Minimum Hardware Requirement

The user can select one of two architectures for installing Cisco Info Center 1.2. The multi-system architecture, a fully distributed architecture, is the recommended architecture. For more information on installation, consult the Cisco Info Center Installation and Configuration manual.

Table 2 summarizes the requirements for the multi-system architecture.

Table 3 summarizes the requirements for the single-system architecture.

Additional System Requirement

In addition, the Sun system must have UNIX/Motif 1.2 or the Common Desktop Environment (CDE) installed.

Notes, Cautions, and Limitations

Installation

• The host machine should have JVM 1.1 or later installed in order for the CIC 1.2 Install Shield to function. Solaris 2.6 has a default JVM setup. For Solaris 2.5.1, the user can download the JVM environment from the following URL:

http://www.sun.com/solaris/java

• It is recommended to install CIC 1.2 on top of a fresh installation of HPOV 5.01, CWM 9.2.04-9.2.05 with Solaris 2.6. Note that CIC 1.2 can also be installed with HPOV 5.01, SV+ 9.1 with Solaris 2.5.1 but does not provide support for any CWM 9.2.03-9.2.05 features.

• To install Cisco Info Center, the user must be logged in as root in /opt/Omnibus with the environment variable OMNIHOME set to /opt/Omnibus. If no space is available in /opt, the user must install in another directory. The installation script automatically creates a link to /opt/Omnibus. However, the requirement is that /opt/Omnibus must not exist either as a file or directory prior to the installation.

• Run /opt/Omnibus/install/nco_license to install the license keys that you have purchased.

• Hostname resolution should be done using the /etc/hosts file.

For example, if the user is using a Name Server (for example, nis, nis+, dns), make sure that /etc/nsswitch.conf lists files before other name services as follows:

hosts:      files dns nis
 

• IPX/BPX/IGX/MGX should use the software (SW) and firmware (FW) versions shown in Table 4.

Upgrading CIC

Note the following points regarding the upgrade procedure.

• The upgrade path is from CIC 1.1 to 1.2. There is no upgrade support from CIC 1.0. Only the existing CIC1.1 features with additional Object Server database fields that may have been added by users during customization will be migrated. Additional user-defined tools and automations are not supported by the 1.1 to 1.2 upgrade script.

• A CIC license server must be available and running when upgrading the Info Server, and the user must provide the name of the host running the licenses to the upgrade script. Otherwise, the upgrade process will use the default license server as the local host (as it is displayed); and, if the local host does not have the license server running, then the upgrade process will exit but the object server will not get upgraded. Issue the following command to make sure that the CIC license server is running.

/usr/bin/ps -ef | grep elmd

• Always back up the CIC 1.1 directory by issuing the following command:

mv /opt/Omnibus /opt/Omnibus_1.1

The CIC 1.2 upgrade script will prompt for /opt/Omnibus_1.1 as the default.

• The OS should also be upgraded from Solaris 2.5.1 to Solaris 2.6 when doing an upgrade from CIC 1.1 to CIC 1.2 and SV+ 9.1 to CWM 9.2.04-9.2.05.

• Always inspect the /opt/Omnibus/log/upgrade.log after running the upgrade script to ensure proper upgrade from 1.1 to 1.2.

• The host name where the CWM Mediator is running should remain the same during the CIC upgrade; otherwise none of the tools will work with old alarms.

Removing CIC

To remove the CIC installation you must be root. Complete these steps to remove the installation.

Step 1 Stop the CIC Desktop by selecting Exit from the Conductor.

Step 2 Issue the following command to stop all CIC Server and Mediator(s) processes:

/opt/Omnibus/bin/nco_pa_shutdown

Step 3 To identify all current CIC packages, issue the following command:

pkginfo | grep Info-Center

Step 4 Issue the following command to remove the CIC components:

 pkgrm <all current CIC package names>
 

where the names can be all or some of the following: CICcom, CICdsk, CICgtw, CICjel, CIClic, CICmed, CICpad, CICsrv.

Step 5 Issue the following commands:

rm /etc/init.d/nco
rm /etc/rc2.d/S81nco
rm /etc/rc1.d/K65nco
rm -rf /.omnibus
rm -rf /opt/Omnibus

Verifying, Starting, and Restarting the CIC Processes

Complete these steps to stop the current CIC processes:

Step 1 Issue the following commands:

setenv OMNIHOME /opt/Omnibus

cd /opt/Omnibus/bin

/nco_pa_shutdown

Step 2 Issue the command /usr/bin/ps -ef | grep nco to make sure that none of the following processes are running:

/opt/Omnibus/bin/solaris2/nco_objserv

/opt/Omnibus/probes/solaris2/nco_p_rttrapd

/opt/Omnibus/probes/solaris2/nco_p_nnm5

/opt/Omnibus/bin/solaris2/nco_pad

/opt/Omnibus/probes/solaris2/nco_p_syslog

Otherwise use kill -9 <pid> to stop any nco processes that are still running.

Starting CIC Processes

To start the CIC process, complete these steps.

Step 1 Issue the following commands:

setenv OMNIHOME /opt/Omnibus

cd /opt/Omnibus/bin

./nco_pad

Step 2 Issue the command /usr/bin/ps -ef | grep nco to make sure that the processes shown in Table 5 are running, if installed.

Starting the License Server

Complete these steps to start the license server.

Step 1 Issue the following commands to start the license server:

setenv OMNIHOME /opt/Omnibus

cd /opt/Omnibus/bin

./nco_start_license

Step 2 Issue the following command to make sure that the license server is running

/usr/bin/ps -ef | grep elmd

Third Party Mediators

CWM Mediators

• Either CWM 9.2.03-9.2.05 or SV+ 9.1 must be installed and running.

CWM version 9.2.03-9.2.05 is needed for proper functioning with CIC1.2. To check the existence of the process, issue the command ps -ef | grep <process_name> where <process_name> can be svmain or RtmProxy.

• Multiple CWM Networks Support.

Network Names must be unique as they appear in the CWM hosts' svplus/config.sv file as managed by a single Info Server. The user can edit these files and restart the CWM hosts to ensure that the names are all different.

• dbaccess must only exist in /usr/users/informix/bin and INFORMIXDIR must be set to /usr/users/informix for the root user. A CWM 9.2.03-9.2.05 installation might choose /usr/users/informix723 as the installation destination. In this case use:

ln -s /usr/users/informix723 /usr/users/informix

• HP Network Node Manager should be installed and integrated with CWM. If HP NNM is installed after CWM installation, run the script SV+_HPOV.install. For more details, refer to the Cisco WAN Manager Installation Guide.

• Timing behavior of IPX/IGX/BPX intermediate alarms.

Certain transition (<10 sec) alarms will show up in the Event Log in HPOV but might not in CIC nor CWM Proxy. For example, when there is a status change on the trunk, a bit map (on the switch) is updated to indicate the change. Then the process (A) which sends a robust message to CWM checks the bit map and sends the latest status via a robust message. When the trunk cable is disconnected, a "loss of signal" message will be sent to CWM. But, when the cable is reconnected, two events happen on the switch: (1) the trunk will go into "Communication Failure" first, then "Clear"; and (2) the bitmap will be set to "Communication Failure" for a short time (3-6 secs) and then to "Clear." So depending on when the process (A) checks the bit map, sometimes the "Communication Failure" will not be sent to CWM if the bitmap has already been updated to "Clear." "Communication Failure" is just a intermediate state--- not the real state of the trunk in this case.

• The SysOIDs for SV+ 9.1.09 and CWM 9.204 or later traps are registered under 1.3.6.1.4.1.351.1 while the SysOIDs for all pre-CWM 9.204 (includes 9.1, 9.0) are registered under 1.3.6.1.4.1.351.120 (for 20000 level traps) and 1.3.6.1.4.1.351.100 (for 1000 level traps). The SysOIDs for all MGX (8220 and 8850) traps are registered under 1.3.6.1.4.1.351.110.

Syslog Mediators

The following Solaris patches should be installed.

• Sun patch 103738-07

The Syslog Mediator receives Syslog messages from the UNIX syslogd process. There is a bug with this daemon on Sun Solaris 2.5.1 where a burst of events to the syslogd process will overload the buffer for the names pipe /var/adm/nco, which is created by the Syslog Mediator to receive messages from syslogd. It is recommended that Sun patch 103738-07 or higher be applied to any Sun host running the Syslog Mediator to help remedy this problem.

• Sun Patch 106439-02

Problems with syslogd on Sun Solaris 2.6 can also occur. When started, the Syslog Mediator sends a HUP signal to the syslogd process to force it to reread its config file, /etc/syslog.conf, and begin forwarding messages to the Syslog Mediator on the named pipe, /var/adm/nco. The syslogd process on 2.6 will not reread the config file unless it has changed. A touch on the syslog.conf file, followed by start of the Syslog Mediator will remedy this. You should apply Sun Patch 106439-02 or higher on any Sun host running the Syslog Mediator to help remedy this problem.

CiscoView

CiscoView should be installed in /opt/CSCOcv and integrated with CWM 9.2.03-9.2.05. Consult the CiscoView documentation for a detailed description.

Informix Database

The CWM Informix Database name should be "stratacom."

Network Configuration

The network configuration should include:

• IPX running 9.0, 9.1

• IGX/BPX running 9.0, 9.1, 9.2

• MGX 8220 running 4.0, 4.1, 5.0

• MGX 8850 running 1.2.

Service and Network Agents

• The CWM Service and Network Agent should be installed and running. Refer to the Cisco WAN Manager Installation Guide for installation instructions.

• The CWM SNMP Agent must use default port 8161 for SNMP Trap Registration. The Info Server uses port 8161 to communicate with Service and Network Agent.

Automation

• The Num Lock key must be off for the right mouse button to start the Automation Pop-up menu.

• 12-hour-Cleared and 24-hour-Deleted automation is disabled by default. The users must enable it. Consult the Cisco Info Center documents for a detailed description.

• Delay in NEType, NEAddress, NetworkName, NEFWVersion, and NEModelID lookups. When new networks are added to the CWM desktop or after a cold start, the incoming events of the new node may be tagged with unknown NEType, NEAddress, NetworkName, NEFWVersion, and NEModelID with the value displayed as "unknown." Users may experience a minimum delay of 60 seconds before the corresponding CWM lookup tables are populated.

• No automation to handle a change of IP address. Currently, if a node has an IP address already configured, changing the IP address on the node will not trigger an update to Info Server. This means that all incoming events from that node still carry an old NEAddress. The user can create tools to execute nco_sql to run an update on a node if that node's IP address is changed.

• Endpoint deletion automation does not work for MGX endpoint deletion. If the master endpoint of a user connection is MGX, a user connection alarm will not be cleared by automation when the MGX endpoint is deleted.

• Object Deletion automation clears any events of the same ObjectType and updates the ObjectStatus and Severity as "Cleared". This is the way it is designed. These "Cleared" traps will then be physically deleted by 12-hour-Cleared automation (if this automation is enabled).

Filter

• Use additional fields in CIC 1.2 for the Multiple Networks and CWM Mediators filter. Users must build filters with new database fields such as NetworkName, NEFWVersion, NEModelID, SVVersion, LNNI, RNNI, OAM, and AIS. Consult the Cisco Info Center documentation for a detailed description.

• The syntax of the Manager field has been changed. The new format is:

<host>@SV+, <host>@NNM5 or <host>@syslog.

Tools

• All CIC Tools rely on the nco_pa process. If this process dies or cannot get a connection, none of the tools will work. The status of the nco_pa process is logged in the /opt/Omnibus/log/NCO_PA.log file.

• Voice and data connections. Only AdminGUI, CiscoView and get_config are associated with voice and data endpoint traps in the 1.x release. Tools such as RTC, and add/delete loop back are not available.

• Intermittent failure on Tstcon/Tstdelay. Tstcon/tstdelay sometimes fails, but that should reflect the result from ConnProxy. Check /usr/users/svplus/log/ConnProxy.log on the machine running the mediators if you encounter a Tstcon/tstdelay failure.

• dsx3RcvEXZCounter in the RTC tool gives a "does not exist" error message. The MGX dsx3 counter does not work on the SRM card but works on the BNM card.

• The RTC Graph tool occasionally outputs an error message such as "no such name". This is an HP Openview xnmgraph problem. Please check "Third Party Product Limitations Notes" for details.

• No line loopback support for BPX/MGX addlnloop is available in BPX and MGX but this feature is not supported in this release.

• There must be connectivity to the CWM host for all tools to work. All nodes should be reachable from the CWM machine through IP-relay. The CWM gateway node should be LAN connected.

CIC and HPOV Severity Level Assignments

Discrepancies are reported between the severity level assignments of the HPOV 4.1, 5.01 and CIC 1.x.

CIC 1.x maps MGX alarms to a severity level according to the value of the MGX SNMP varbind: moduleTrapAlarmSeverity. The following table provides the mapping details as used.

HPOV maps the MGX alarms to a severity level according to a static file:

/etc/opt/OV/share/conf/C/StrataCom_trapd.conf

HP OpenView Requirements

Info Center Release 1.2 works with HP Openview Release 5.01 for Solaris 2.6.

For HP OpenView installation requirements and procedures, please refer to the HP OpenView Network Node Manager Products, Installation Guide

Third Party Product Limitations Notes

Xnmgraph occasionally gives "no such name" or "wrapped (0->0). Waiting for next" even though the data is available for get as tested by xnmbrowser.

Xnmgraph shows an incremental statistics value that is not consistent with the Text counter display.

Cisco Info Center 1.2 Known Problems

CIC 1.2 has been tested with CWM 9.2.03-9.2.05, IPX 9.1, BPX/IGX 9.2 and MGX 8850 1.2 and MGX 8220 5.0 on a Solaris 2.6 setup installed with HPOV 5.01. The following are the known issues in this release:

• Add Loopback/Delete Loopback will not work on events originating on an MGX 8850.

• Testconnection/Testdelay might fail on events originating on a new UXM in IGX, PXM on MGX 8850 and FR on MGX 8850. This is due to a problem on SNMPSET bugs on these agents.

• Voice/Data/CE events (from SV+ 9.1) that happened prior to a CIC upgrade will no longer launch tools correctly after the upgrade and will not be deduplicated correctly with the new Voice/Data/CE events (from CWM 9.2.04-9.2.05) due to changes in PSAP and LSAP indexing.

• Launching Equipment Manager from the CWM 9.2 desktop might cause a core dump. This is a known bug. The workaround is to launch the Equipment Manager from the CIC Tools menu.

• Overlapping Network Names appear in the CIC Event List under the Network field. This happens occasionally with SWSW 9.1 in combination with a CWM 9.2 environment. For example, "Network1" might show up as "Network1 Network2". The workaround is to issue a kill -HUP command on the <rttrapd pid> to cure the problem for new events

• In the CWM 9.2 and SWSW 9.1 environment, the "commbreak" and IP reachability alarms for an MGX node are wrongly labeled as BPX in the "NEType". This problem is fixed with the CWM 9.2 and SWSW 9.2 network.

• SNMP get "Error: snmpget: Agent reported error ..." with the RTC Tool when a "Show Stat" or "Graph" returns an error. This situation occurs when the underlying firmware does not support the referenced MIB.

• When running the CIC 1.2 installation script, you are prompted to select the components you want to install and then select Next. If you complete the installation script and later try to run it to install additional components, the script will not install these components. In this case you must first remove the installation and then rerun the installation script to install the components you want.

New CIC 1.2 Supported Alarms

Table 7 indicates the new alarms that are supported with release 1.2.
Table 7: New Alarms for Release 1.2

Trap ID	Trap Name	Description
20021	cpuUtilizationAboveNormal	This trap is generated whenever a BPX/IGX/IPX processor's CPU utilization is above the threshold. The alarm is reported from the node based on an existing interval statistic that is collected for profiling the performance of the node.
20022	cpuUtilizationNormal	This trap is generated whenever a BPX/IGX/IPX processor's CPU utilization falls back below the threshold. The alarm is reported from the node based on an existing interval statistic that is collected for profiling the performance of the node.
20023	memoryUtilizationAboveNormal	This trap is generated whenever a BPX/IGX/IPX processor's dynamic memory utilization exceeds a fixed threshold. the alarm is reported from the node based on existing statistics that are collected for profiling the performance of the node.
20024	memoryUtilizationNormal	This trap is generated whenever a BPX/IGX/IPX processor's dynamic memory utilization falls below a lower threshold indicating the memory allocation has returned to a safe level. The alarm is reported from the node based on existing statistics that are collected for profiling the performance of the node.
20025	busFailure	This trap is generated whenever a BPX/IGX/IPX bus fails.
20026	busNormal	This trap is generated whenever a BPX/IGX/IPX bus failure clears.
20050	nodeAdded	This trap is generated whenever a node is added to the network.
20051	nodeDeleted	This trap is generated whenever a node is deleted from the network.
20052	nodeNameChanged	This trap is generated whenever a node name is changed.
20053	nodeIpAddressChange	This trap is generated whenever a node IP address is changed.
20054	nodeStatusChange	This trap is generated whenever a node alarm status changes in the network.
20055	cardAdd	This trap is generated whenever a card is added to IGX/IPX/BPX nodes.
20056	cardDeleted	This trap is generated whenever a card is deleted from IGX/IPX/BPX nodes.
20057	peripheralAdded	This trap is generated whenever a peripheral is added to IGX/IPX/BPX nodes.
20058	peripheralDeleted	This trap is generated whenever a peripheral is deleted from IGX/IPX/BPX nodes.
20059	trunkAdded	This trap is generated whenever a trunk is added to IGX/IPX/BPX nodes.
20060	trunkDeleted	This trap is generated whenever a trunk is deleted from IGX/IPX/BPX nodes.
20061	lineAdded	This trap is generated whenever a line is added to IGX/IPX/BPX nodes.
20062	lineDeleted	This trap is generated whenever a line is deleted from IGX/IPX/BPX nodes.
20063	portAdded	This trap is generated whenever a port is added to IGX/BPX/IPX nodes.
20064	portDeleted	This trap is generated whenever a port is deleted from IGX/BPX/IPX nodes.
20065	cardModified	This trap is generated when a card is modified on a BPX/IGX/IPX node. If the back card (bc_type field in the CWM `card' database table) is changed, this trap is generated.
20066	trunkModified	This trap is generated whenever a trunk is modified on a BPX/IGX/IPX node.
20067	portModified	This trap is generated whenever a port is modified from IGX/BPX/IPX nodes.
20100	apsClearAlarm	Indicates the APS alarm is cleared.
20101	apsActivatedAlarm	APS is enabled on the line.
20102	apsDeactivatedAlarm	APS is disabled on the line.
20103	apsCardFailedAlarm	APS card is in alarm.
20104	apsLineFailedAlarm	APS configured line is in alarm.
20105	apsLineSwitchedAlarm	APS lines are switched.
20106	apsLineSwitchFailedAlarm	APS line switch failed.
20107	apsStbyLineFailAlarm	APS standby line is in alarm.
25302	svNodeIpUnreachable	CWM finds a given node to be IP unreachable.
25303	svNodeIpReachable	CWM finds a given node to be IP reachable
28000	svProcessRestarted	This trap is sent when a process within CWM with the name trapSvProcessName is restarted.
28001	svProcessNotRestarted	CWM process terminated.
28002	svDatabaseFull	CWM database full.
28003	svDatabaseNormal	CWM database is not full.
28004	svDiskSpaceLow	CWM detects that the free disk space is running low.
28005	svDiskSpaceNormal	CWM detects that the free disk space is no longer low.
28006	svTftpError	This trap is sent when a CWM process encounters a TFTP error received from a node.
28007	svRtmMaxMgrsRegistered	This trap is sent when CWM RTM process cannot register with an agent (like MGX/VNS node) because the limit for the maximum number of managers to register has been reached. The default limit is 8 managers.
28008	svStatisticsParsingError	This trap is sent when the CWM statsparser process encounters an error in parsing a statistics file received from a node.
28075	svDatabaseInSync	This trap is sent when a process within CWM has completed synchronizing its database with the configuration in the network. CWM generates network configuration change traps to the external clients after this synchronization is complete.
30000	controllerAdded	This trap is generated whenever a virtual switch (VSI controller) is added to the network.
30001	controllerDeleted	This trap is generated whenever a virtual switch (VSI controller) is deleted from the network.
30002	controllerModified	This trap is generated whenever a VSI controller is modified in the network.
30100	vsiInterfaceAdd	This trap is generated whenever a virtual logical interface is added.
30101	vsiInterfaceDeleted	This trap is generated whenever a virtual logical interface is deleted
30102	vsiInterfaceModified	This trap is generated whenever a virtual logical interface is modified.
50024	shelfPowerOverLoadTrap	Indicates that the functionModuleType when inserted raised the total power consumption of the shelf beyond threshold value. functionModuleType value other(1) indicates that a fan tray has been removed, which increases the power consumption value beyond the capacity of remaining fan tray. shelfIntegeratedAlarm is set to the value major(3). When the alarm condition is cleared, the same trap is sent with shelfIntegratedAlarm value set to clear (1).
50033	cardResPartTypeChangeTrap	This trap is sent out when the resource partition type is changed.
50035	secLineModuleRemovedTrap	Indicates whether or not a particular secondary (bottom) line module has been removed. This is applicable to MGX 8850 only, in a case where the front card (functionModuleType) is a full height card with 2 half height back cards.
50036	secLineModuleInsertedTrap	Indicates whether or not a particular secondary (bottom) line module has been inserted. This is applicable to MGX 8850 only, in a case where the front card (functionModuleType) is a full height card with 2 half height back cards.
50037	secLineModuleMismatchTrap	Indicates that the front card does not support the secondary (bottom) line module. This is applicable to MGX 8850 only, in a case where the front card (functionModuleType) is a full height card with 2 half height back cards.
50044	functionModuleHoldTrap	Indicates that a function module is in the Hold state.
50052	atmLineCellFormatTrap	This trap is sent out when the line cell format is changed. PXM lines can be configured to either UNI or NNI cell formats. The STI format is not supported in the MGX 8850 PXM.
50064	coreCardSwitchInProgress	This indicates that the switchcc process is in progress, that all the initial checks for switchcc to happen were successful.
50065	coreCardSwitchBlocked	This indicates that the switchcc process cannot happen due to the checks failing. Hence a switchcc blocked trap is being sent. This is more like a failure trap.
50120	dsx1LineNoAlarmTrap	Indicates no line alarm. Note: for FRSM-2CT3, there can be T1 line within each T3 (28 T1s).
50121	dsx1LineInAlarmTrap @Severity=Major, Minor, Warning	Note: for FRSM-2CT3, there can be T1 line within each T3 (28 T1s).
50122	dsx1LineLpbkEnableTrap @Severity=Major, Minor, Warning	Note: for FRSM-2CT3, there can be T1 line within each T3 (28 T1s).
50123	dsx1LineLpbkDisableTrap @Severity=Major, Minor, Warning	Note: for FRSM-2CT3, there can be T1 line within each T3 (28 T1s).
50135	pxmCurClkSourceTrap @Severity=Major, Minor, Warning	Indicates that the current clock source has changed.
50191	trapRpmPortAdd	Indicates that a sub interface is added.
50192	trapRpmPortDelete	Indicates that a sub interface is deleted.
50193	trapRpmPortModify	Indicates that a sub interface is modified.
50194	trapRpmPortActive	Indicates that a sub interface is Active.
50196	trapRpmChanAdd	Indicates that a RPM channel is added.
50197	trapRpmChanDelete	Indicates that an RPM channel is deleted.
50198	trapRpmChanModify	Indicates that an RPM channel is modified.
50199	trapRpmChanActive	Indicates that an RPM channel is active.
50250	trapImaGTSMchange	Indicate the failure status of the IMA group (GTSM goes UP/DOWN).
50251	trapImaCellRateChange	Indicates that the bandwidth of an IMA group changed due to addition/deletion of links to/from the IMA group.
50311	trapChanOamLpbkStatus	Sent when the channel Ras_Oam_Loopback_state changes from Failed to Ok or Ok to Failed. It will carry status for a chunk of 256 channels as bitmaps. If the status of only 1 channel belonging to the chunk of 256 changes, trap is seen only for that chunk of 256 channels and not for any other chunk. For e.g., suppose if channel 500 fails the RAS loopback test, trap is sent for the second chunk of 256 channels spanning channel nos 257 to 512.
50312	rasDskChksumStatusTrap	Indicates the Status of the SM configuration and FirmWare files. The Trap shows the number of corrupted PRI and Firmware files in the ASC from where it is sent. This trap is sent every time the diagnostics is completed.
50313	rasDskBadSectorsTrap	Indicates the number of Bad Sectors in the ASC Hard Disk. If the number of Bad Sectors exceeds the threshold value, the rasDskHealth is set to FAIL. The threshold value is 30% of the total number of Sectors. This Trap is sent every time the diagnostics is completed.
50315	pxmCurClkSourceTrap	Indicates that the current clock source has changed.
50381	trapGenFrPortActive	Trap that is generated to indicate that a FR logical port has become active. Currently, this trap is used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50382	trapGenFrPortFailed	Trap that is generated to indicate that a FR logical port has failed. Currently, this trap is used only in all favors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50383	trapGenFrPortDelete	Trap that is generated to indicate that a FR logical port has been deleted. Currently, this trap is used only with the various types of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50384	trapGenFrPortLoopbackEnabled	Trap that is generated to indicate that loopback on a FR logical port has become active. Currently, this trap is used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50385	trapGenFrPortLoopbackDisabled	Trap that is generated to indicate that loopback on a FR logical port has become disabled. Currently, this trap is used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50386	trapGenFrPortOvrSubscribed	Trap that is generated to indicate that a FR logical port has become oversubscribed. Currently, this trap is used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50387	trapGenFrChanActive	Sent when a FR logical channel becomes active: this trap is currently used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50388	trapGenFrChanFailed	Sent when a FR logical channel fails: this trap is currently used only in all flavors of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50389	trapGenFrChanDelete	Sent when a FR logical channel is deleted: this trap is currently used only in all flavours of FRSM-VHS card (FRSM-2CT3/T3/E3/HS2).
50713	trapVismPortFailed	Indicates port Failed.
50926	trapCesmChanActiveGeneric	Sent when a CESM Channel becomes active.
50927	trapCesmChanDeleteGeneric	Sent when a CESM Channel is deleted.
50928	trapCesmChanUnderflowGeneric	Sent when a CESM Channel egress underflows.
50929	trapCesmChanOverflowGeneric	Sent when a CESM Channel egress overflows.
50930	trapCesmChanCellLossGeneric	Sent when a CESM Channel Egress cell loss occurs.
50931	trapCesmChanIdleSuppStartGeneric	Sent when Idle suppression starts on this connection.
50932	trapCesmChanIdleSuppStopGeneric	Sent when Idle suppression stops on this connection.
50933	trapCesmPortAddedGeneric	Indicates port added (enabled).
50934	trapCesmPortActiveGeneric	Indicates port active.
50935	trapCesmPortFailedGeneric	Indicates port is failed.
50936	trapCesmPortDeleteGeneric	Indicates port is deleted.
50980	trapBbIfAdded	Indicates that Broadband Interface on PXM is Added.
50981	trapBbIfActive	Indicates that Broadband Interface on PXM is Active.
50982	trapBbIfDelete	Indicates that Broadband Interface on PXM is Deleted.
50983	trapBbIfFailed	Indicates that Broadband Interface on PXM is Failed (In alarm).
50984	trapBbIfCnfChange	Indicates that Broadband Interface on PXM configuration has been modified.
50985	trapBbIfRscAlloc	Indicates that Broadband Interface on PXM Resource has been allocated to a network controller (for e.g. PAR).
50990	trapBbChanAdded	Indicates that Broadband Channel on user port of PXM is Added.
50991	trapBbChanActive	Indicates that Broadband Channel on user port of PXM is Active and no alarms exist.
50992	trapBbChanDelete	Sent when a Channel is deleted.
50993	trapBbChanFailed	Sent when a Channel fails (In alarm).
51201	parNodeStatusChange	This trap is generated when a alarm status of the node (parnNodeId) changes.
51202	parNodeParmsChange	This trap is generated when a node (parnNodeId) parameters change.
51203	parTrunkAdd	This trap is generated when a new trunk is added in the network
51204	parTrunkStatusChange	This trap is generated when the status of the trunk changes or the type of alarm changes.
51205	parTrunkDelete	This trap is generated when the trunk is deleted from the network.
51206	parTrunkConfig	This trap is generated when the trunk parameters are configured.
51207	parConnRouteStateChange	This trap is generated only by the node that masters the connection.
51208	parDownConnStateChange	This trap is generated when a connection is downed. This trap is generated only by the node that masters the connection

Info Center Syslog Rules File for Cisco IOS Devices (Routers)

During development of Cisco version 1.2, a new rules file was developed to parse Syslog messages from Cisco IOS devices (mainly routers, but any platform that runs IOS). This rules file is an enhancement of previous rules files that did only limited parsing of Cisco IOS messages.

This rules file was developed using messages from IOS version 12.0. The messages in this version should be a superset of previous software versions, so they should be backward compatible with previous versions of the Cisco IOS. Please note that Cisco IOS devices include ATM line cards on the Catalyst devices. Also, note that Cisco IOS messages are mainly platform independent---there are only a small number of facilities that are specific to certain platforms. There is also no way to determine from the messages themselves what hardware platform they came from (unless they are a hardware specific message). Hardware specific message facilities are marked a table that is included in the online CCO documentation.

The rules file was developed with the following information found on CCO.

The "Table of Contents" for Cisco IOS error messages is at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12supdoc/12sems/
index.htm

The structure and format of Cisco IOS error messages is described at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12supdoc/12sems
/emover.htm

Cisco IOS Event Format

Cisco IOS messages are in a specific format:

"FACILITY-SEVERITY-MNEMONIC: Message Text"

For example, "LINEPROTO-5-UPDOWN: Link on Interface eth0 changed state to down".

The SEVERITY field is a number from 0 to 7, with 0 being the most critical. Severity mappings from Cisco Severity to NetCool severities (0-5) are shown in Table 8 below.

By default, the rules file discards any messages set to level "Indeterminate" (which matches Cisco levels 6 and 7). This default can be changed very simply in the rules file.

Each facility has multiple messages associated with it. Many facilities have additional configuration (such as Type 1 and Type 2 settings for generic clears) associated with them, while the majority have no additional configuration past the default. These facilities are still, however, left in the rules file to assist future customer configuration.

Some facilities (especially the CMCC/CIP messages) are preceded with "CARD-SEVERITY-MSG:SLOT" (e.g. "CIP-5-MSG:SLOT7"). This information is stored in Info Server fields (the card is stored in Object Type, and the slot in Slot).

The event format is documented in detail in the Cisco IOS message URL shown above.

Severity Mapping

Table 8 indicates the severity level mapping between Cisco severity levels and NetCool severity levels.

Installation Issues

The properties file should have the "Manager" variable set to Syslog@host where "host" is the name of the host running the syslog probe. This can also be set in the command line. The install script should be set up to configure this when installing the syslog probe.

Routers should be configured to send logging messages to the host where syslog is running. This can be configured with the command "logging IPAddress" where IPAddress is the IP address of the host running the syslog probe.

The /etc/syslog.conf file should be set to forward events to the syslog probe, as documented in the installation manual.

IP Addressing

For de-duplication (and any other correlation) to work correctly, Syslog messages from a router should all come from the same source IP address. Ideally, this IP address should be resolvable (either through DNS or /etc/hosts) from the machine running the Syslog Mediator. Cisco recommends that routers have a "loopback" interface, and that you assign an address to the loopback interface.

If Syslog messages are set to come from the loopback interface (using the command logging-source interface loopback0), then the hostname of the router will resolve to the same name. This is necessary, because if not set, the source address of the message will be the router interface of message egress. This may change in a dynamic environment.

If loopback addresses are not used, the command logging-source interface interface should still be used, with an interface chosen that is least likely to go down.

Classes, NEType

Because there is no way to determine from event messages what type of router or switch is sending messages, the following Classes and NEType have been assigned to Cisco routers and Catalyst switches in the Rules file.

• Class 255, NEType 555---Cisco Routers

• Class 256, NEType 556---Catalyst Switches

IOS Rules File Parsing

The Syslog rules file does the following:

1. Determines whether the event is a Cisco IOS message by looking for an event preceded by a "%" and followed by some text, followed by a dash and then a number between 0 and 7.

2. Sets @Agent to "CiscoIOS" and the @Summary to $Details past the "%," and jumps in a switch statement to the "CiscoIOS' section.

3. Extracts the Facility, Severity, Mnemonic, and Message Text. If the message is prepended with slot and card information, this is extracted as well, and the slot is placed in @Slot, while the card type is placed in @ObjectType.

4. By default, the Identifier is set to "Node-> Summary," and the AlertGroup to the Facility.

5. The severity is set from the Cisco Severity, based on Table 8.

6. There is then a long switch statement that performs a switch on the Facility. Most entries are blank, as the default behavior is sufficient, but they are left in the statement for future enhancements.

7. In some of the cases (see Table 9 for information on which have been modified) certain events are discarded (for example, those with BRI for interfaces) and others have generic automations (Type 1 and 2) set.

8. After the switch statement, events that still have severity = 1, "Indeterminate" are discarded, except for those that have Type 2 set.

Table 9 summarizes the variables that are set by the rules file.

Cisco Connection Online

Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously: a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

• WWW:  http://www.cisco.com

• WWW:  http://www-europe.cisco.com

• WWW:  http://www-china.cisco.com

• Telnet:  cco.cisco.com

• Modem:  From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.

Documentation CD-ROM

Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more current than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.

Posted: Mon Sep 27 18:05:50 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.