-
Cisco 12000 Manager Release 2.2
- Reelase Notes for Cisco 12000/10720 Router Manager 2.2
- Cisco 12000/10720 Router Manager Installation and Configuration Guide, 2.2
-
Cisco 12000/10720 Router Manager User's Guide, 2.2
-
About This Guide
-
C12kM Overview
-
C12kM Concepts
-
Getting Started
-
Chassis Management
-
Managing Modules
-
Managing Interfaces
-
Interface Profiles
-
Interface Configuration
-
Interface Status
-
Interface Performance
-
Layer 3 QoS
-
Managing ATM Connections
-
VLAN Management
-
Fault Management
-
Change Management
-
Performance Management and Historical Data
-
SONET/SDH COnversion Chart
-
Table Of Contents
Cisco 12000 Manager (C12kM) Alarms
Cisco 12000 Series Internet Router Trap Support
Configuration Management Traps
Viewing the ATM Interface Faults Window
ATM Interface Faults Window—Detailed Description
Fault Management
This chapter describes how to view appropriate fault information on the Cisco 12000 series internet routers you are managing. The Cisco 12000 series internet routers can be configured to send snmp traps when various conditions are detected. This may be a fault, the correction/resolution of a previous condition or a status update. Traps are translated into Cisco EMF alarms and raised against the appropriate C12kM object. These alarms are cleared automatically (if the resolution can be clearly detected by C12kM) or manually.
This chapter contains the following information:
•
Cisco 12000 Manager (C12kM) Alarms
•
Cisco 12000 Manager (C12kM) Alarms
C12kM enables you to identify faults or alarms generated by Cisco 12000 series internet routers. Within the Map Viewer application, you are notified of alarms on individual objects by the colored status icons next to each managed object. The following table details all status colors and their related severities.
Alarms are propagated up the object hierarchy, and are reflected up to the highest level. For example, say a critical (red) alarm occurs on an interface. If you do not have the chassis map open, and if the interface text is not apparent, how would you know an alarm had occurred at that level? The answer is: propagation. The interface alarm would be propagated up the hierarchy to site level. This means that whatever level you are working at, you will see that an alarm has occurred. You can follow the path to discover where the alarm exists.
Note
Viewing Alarms
Alarms can be viewed using the Event Browser application that is part of the Cisco Element Management Framework (Cisco EMF).
Event Browser can be launched in two ways:
•
Event Browser allows you to view all alarms on all objects. The Query Editor window appears automatically when you launch the Event Browser application. The Query Editor allows you to set up a query (or filter) that allows you to filter all the alarms available and display only the alarms matching the query criteria you selected.
When the event browser is launched against an object, by default, all the alarms against that object and its descendents are displayed in the event browser. For e.g., if the event browser is launched against a chassis, then by default it displays all the alarms against the chassis and the module and interfaces objects available in that chassis. Refer to the Cisco Element Management Framework User Guide Release 3.2 (78-12536-01) for further details on using the Event Browser.
•
Cisco 12000 Series Internet Router Trap Support
When a fault occurs on a managed object in the network, C12kM receives immediate notification, through a "trap" that is sent through the network. This trap manifests itself as an alarm in C12kM. A trap of any of the above category can be one of five severity types:
•
•
•
•
•
Chassis Alarms
Table 14-2 provides information on traps that result in alarms raised against the chassis object.
Note
As can be seen from the table, Cisco EMF alarms may be cleared by other alarms. The general pattern is that an alarm clears alarms of the same or higher severity. All other alarms should be cleared manually.
Interface Alarms
Table 14-3 provides information on traps that result in alarms raised against interface objects.
Syslog Traps
Note
Cisco IOS can be configured to send Syslog traps to a designated server. There are eight levels of Syslog information which are mapped into four categories of Cisco EMF alarm severity. Syslog specific data is inserted into the Message portion of the Cisco EMF alarm. In all cases, alarms are raised against the Chassis object. There is no automatic clearing of Syslog Alarms. Table 14-5 summarizes the severity mapping between trap and alarm:
Syslog alarms have a Description in the Event Browser application in the following format:
"Asserted [<clogHistMsgText>] by facility [<clogHistFacility>], Message name [<clogHistMsgName>]"
Where:
clogHistMsgText is the message text
clogHistFacility is the facility name (where the message came from)
clogHistMsgName is the message name
An example Syslog Alarm Description is
"Asserted [Critical/high priority process ATM Periodic may not dismiss.] by facility [SCHED], Message name [EDISMSCRIT]"
Configuration Management Traps
When a change is made to the configuration of a Cisco 12000 series internet router, Cisco IOS can send a "configuration management event trap". This trap is translated into a Cisco EMF alarm with the following description:
"Config Change, Command Source: <ccmHistoryEventCommandSource>, Config Source: < ccmHistoryEventConfigSource>, Config Destination: < ccmHistoryEventConfigDestination>"
Where:
•
•
•
An example Configuration Management Event Alarm Description is:
"Config Change, Command Source: commandLine, Config Source: running, Config Destination: commandSource".
This would be received when a <write memory> command was issued.
Alarms are raised against the Chassis object with Informational Severity. There is no automatic clearing.
Heartbeat Polling
Heartbeat polling begins automatically when you commission a chassis. The chassis and all objects within the chassis are polled every five minutes. There are two types of heartbeat polling: Connectivity Management and Operational Status Polling.
The Heartbeat Polling section covers the following areas:
Connectivity Management
C12kM polls the management interface on the Cisco 12000 series internet router every 60 seconds to determine network connectivity. If management connectivity is lost, the chassis enters into a lost comms state and this state ripples down to all subchassis objects. A major lost comms alarm is raised against the chassis. The chassis continues to poll. If it detects re-establishment, it puts the chassis state back to the relevant state and this state ripples down to all subchassis objects as well. An alarm of Normal severity is then raised which clears the major lost comms alarm.
Operational Status Polling
Operational Status Polling— Occurs at module and interface levels. Each module and interface polls for its own operational status, for Modules/Interfaces, this is every 5 minutes. If a module detects that its operational status is down, it enters the Errored state and raises a Major alarm. The Errored state does not propagate down to PVCs and SVCs. If an interface goes down, you can see this in the Generic Interface Status window. In the Errored state the module or interface will continue to poll if the condition has been rectified. If it detects that the operational state has moved back to healthy then the object will transition into the Normal state and raise an alarm of Normal severity which will clear the previous Major alarm.
Disabling Heartbeat Polling
You can stop heartbeat polling on an individual interface by decommissioning the interface. You might want to do this if you have interfaces that are not yet connected or live. For example, when you commission a chassis, subchassis discovery is automatically initiated. If you have pre-deployed interfaces that are not yet live, these are discovered and put into an Errored state, after no connectivity is detected on them. An alarm is also be raised on the interface. To correct this situation, you need to decommission the inactive interface and clear the alarm manually.
Performance Logging
Heartbeat polling is unaffected if an object is in the performance logging state.
ATM Interface Faults
The ATM Interface Faults section covers the following areas:
•
•
Viewing the ATM Interface Faults Window
To view the ATM Interface Faults window, proceed as follows:
Step 1
ATM>Fault. The ATM Interface Faults window appears:Figure 14-1 ATM Interface Faults Window
Step 2
ATM Interface Faults Window—Detailed Description
The ATM Interface Faults window displays a single Fault tab.
Fault Tab
The Fault tab (see Figure 14-1) displays three areas: General Errors, SONET Frame Errors, and DS1/E1/DS3/E3 Errors.
General Errors
The General Errors area is not applicable to C12kM.
SONET Frame Errors
The SONET Frame Errors area displays the following information:
Path FEBE Errors—Number of G1 (path FEBE) errors on the physical interface.
Line FEBE Errors—Number of Z2 (line FEBE) errors on the physical interface.
Path Parity Errors—Number of B3 (BIP) errors on the physical interface.
Line Parity Errors—Number of B2 (BIP) errors on the physical interface.
Section Parity Errors—Number of B1 (BIP) errors on the physical interface.
DS1/E1/SD3/E3 Errors
The DS1/E1/DS3/E3 Errors area is not applicable to C12kM.
