|
|
The "Events and Alarms Management" chapter discusses ViewRunner fault management and the dialogs associated with Cisco 6100 or ViewRunner for HP OpenView events and alarms.
Faulty resources are taken out of service by the Cisco 6100. The Cisco 6100 changes the ISO state of the chassis, module, slot, or port to indicate that operations are not "normal" for that entity. In any resource that is faulty, Cisco 6100 changes its Operational State to Disabled and its Service State to Out of Service. The Service State of all resources dependent on the faulty entity are also set to Out of Service. That is, all ports on a module that has been set to Out of Service will also be set to Out of Service.
Alarms showing that a fault of some sort has occurred in a Cisco 6100 entity are reported by the Cisco 6100.
ViewRunner for HP OpenView receives traps from the Cisco 6100 and reports them in various Event Categories windows. ViewRunner checks the trap sequence number to ensure that traps aren't missed, duplicated, or received out of order. It can synchronize with the current alarm tables on the Cisco 6100 if a trap is missed. Therefore, ViewRunner can always display the correct view of a Cisco 6100's alarm state.
Event/alarm displays are kept current through the following methods:
The ViewRunner for HP OpenView does not currently use the Cisco 6100 event log to capture information as the ViewRunner for Windows. The event/alarm information is cached in the Oracle database.
Alarm synchronization is the process of synchronizing ViewRunner client GUIs and the Oracle alarm database with the Cisco 6100 slot, module, port, and image alarm states. A full alarm synchronization updates all Cisco 6100 alarm states, and a module alarm synchronization updates Cisco 6100 alarm states for a specific module and its ports.
Alarm synchronization is needed to guarantee that all ViewRunner client windows display the correct alarm state information. The following client windows are updated with an alarm sync:
ViewRunner gets out of sync with a Cisco 6100's alarm state whenever traps are not received. This can happen when:
A full alarm synchronization is invoked automatically whenever the following conditions exist.
A module alarm synchronization is invoked automatically whenever the following conditions exist.
A full alarm synchronization can be manually invoked via menu options, toolbar icon, or command line invocation.
If View Alarm Formatter discovers that it has missed a trap, it invokes a configuration synchronization. This may result in a lock out of user actions, as discussed in "Configuration Synchronization".
There is minimal impact on the user because Alarm synchronizations are brief and do not lock out the user actions. Alarm syncs are on the order of seconds.
When an alarm "out-of-sync" message is detected, ViewRunner regenerates the missed trap and forwards it to the Error Event Browser. The event message then is appended with "(Discovered by ViewRunner)" to indicate that a trap was missed. ViewRunner displays correct node status on all client GUIs.
ViewRunner for HP OpenView uses color in View Map to indicate the alarm status of a Location or a Wire Center. Location or Wire Center symbol displays the color of the most critical alarm on any of the entities (module, slot, port, or image) in that location or on that node. See the following figure.
ViewRunner also uses color in the Chassis View to indicate the most critical alarm for a particular module. The ejector tab on the module in any chassis is the color of the most critical alarm on that module. In addition, in the toolbar of the Chassis View, a count is kept of all current alarms of critical, major, or minor severity. The color next to the alarm count indicates the severity (red=critical, orange=major, and yellow=minor).
ViewRunner also reports alarms in various event category windows, the Current Alarm window, and in the module/port properties windows. All of which are discussed in detail in the following sections.
ViewRunner maps status into the default states and colors defined by HP OpenView. The status color displayed is dependent on the symbol's prioritization order of evaluating states. In the HP OpenView paradigm, the display of Administrative State colors overrides the display of Operational State colors. That is, an unmanaged Administrative State overrides a critical operational alarm. See "Use of Color in ViewRunner" for more information on the use of colors in ViewRunner.
A window that appears when you open ViewRunner is the Event Categories window. It has a list of the types of events that can be viewed. Each type of event has a box in front of it that displays the color of the highest level alarm asserted for that list of events/alarms.
The recovery from lost traps does not require automatic polling. It is performed when either an alarm or a configuration synchronization is invoked or when a trap is received. The alarm and configuration synchronizations may be configured to occur automatically.
The status colors of the icons on ViewMap are updated as new traps are received and when ViewRunner for HP OpenView periodically polls the Cisco 6100s to examine the highest outstanding alarm against the equipment. The default polling interval is 20 minutes.
The Error Events window shows all the alarms that have been asserted and cleared for a particular Cisco 6100.
The fields in this table are described in Table 12-1 below.
| Field | Field Description |
|---|---|
Ack | Acknowledgment of the alarm. |
Severity | The severity of the alarm/event as determined by Cisco. The alarm/event severities are defined as follows: information, undefined, critical, major, minor, warning, and normal. |
Date/Time | The date and time on which the alarm/event occurred. |
Source | The node against which the alarm/event is asserted. The information in this field can be used to help track down the alarm/event. An "Unknown" entity is returned only when the format of the data from the node is faulty. |
Message | A short description of the alarm/event. This description is a predefined string based on the entity and event code from the node. The first part of the message identifies the chassis and slot number associated with the alarm/event. In some cases, such as a system controller (SC) reset, the chassis and slot number information will be missing since all the alarms on all modules will be cleared. In other cases, such as when an alarm comes from a subtended node, the port number is also included. Some events/alarms are discovered by ViewRunner. In this case, the notation "(Discovered by ViewRunner)" appears at the end of the alarm description. See the Cisco 6100 Series Maintenance and Troubleshooting Guide for more information and for exceptions to this definition. |
The contents of the ViewRunner Error Events window can be sorted by any one of the above fields by clicking on the field header. Clicking on more than one column heading allows the user to nest sorts in the order of column selection. If there are more entries than can fit in the window, a scroll bar will appear to allow scrolling through the entries.
The Current Alarms window displays a concise list of all currently asserted alarms in the system, including module, slot, port, and image alarms. The window format is similar to the Error Events window.
In the Current Alarms window, current alarms are retrieved and displayed when the window is first opened, and when the user manually requests an alarm synchronization. The Current Alarms window is opened by clicking on the Current Alarms button in the Chassis View or by using the View menu option.
Figure 12-5 is an example of the Current Alarms window.
The fields in the Current Alarms window are described in the following table.
| Field | Field Description |
|---|---|
AID | The access identifier for the resource in alarm. The resource is the chassis and slot in alarm. Click on the hyperlink to use logical service oriented navigation to go to the status window for the entity in alarm. |
Entity | The module against which the alarm/event is asserted. The entity can be one of the following: ATU-C, SC, NI, LIM, or STM. |
Severity | The severity of the alarm/event as determined by Cisco. The alarm/event severities are defined as follows: information, undefined, critical, major, minor, warning, and normal. |
Source | The node against which the alarm/event is asserted. The information in this field can be used to help track down the alarm/event. An "Unknown" entity is returned only when the format of the data from the node is faulty. |
Description | A short description of the alarm/event. This description is a predefined string based on the entity and event code from the node. See the Cisco 6100 Series Maintenance and Troubleshooting Guide for more information and for exceptions to this definition. |
Click the Alarm Sync button in the lower left hand corner of the Current Alarm window to synchronize alarms to ensure that no traps have been missed by ViewRunner.
The command line interface (CLI) can be used to view alarms on the Cisco 6100. Complete information on the command syntax and use of the CLI is found in "Command Line Interface (CLI)" section.
The following are some examples of CLI commands used to show alarms on various Cisco 6100 entities.
> show alarms > show alarms sys
> show alarms crit.maj sys
> show alarms chassis L.3
> show alarms min chassis L
> show alarms atuc M.1.12
> show alarms crit lp L.2.12.2
Currently, the only valid command is show alarms with all its options.
The following rules are used to define an event versus an alarm and the severity associated with each.
Exceptions to the above guidelines are used as follows.
1. Even though a loss of an ATU-C does not necessarily affect any customer lines (if other modems in the logical pool are idle), a minor alarm is generated. As the loss of a modem can affect service levels for all subscribers in a given logical pool, a minor alarm will typically trigger a craft recovery action.
2. Some alarm events note in the Impact section of the alarm documentation that a significant number of subscribers will be affected. If the nature of the alarm condition is such that the system is likely to recover given time (for example, buffer overflow), the alarm will be categorized as "Informational". Impact and Alarm Description will be modified in the next software release to make this consistent. This is based on the logic that craft-activation alarms should really only be triggered when subscriber lines are out of service.
Overall, alarm severities will be mapped according to the following rules:
Alarms that have been "Asserted" by the Cisco 6100 are either followed by a "Cleared" event or by an "Info" Event 128 event which in effect clears all alarms associated with a particular entity at a particular slot. For example, some alarms can be "Cleared" if the problem was caused by congestion or single parity errors. Other times, the module generating the alarm must be reset and/or reinserted. In this case, the only event returned is Event 128 "Module was detected." which effectively clears whatever outstanding alarms were asserted against that module.
When you either click on a module in the Chassis View and choose Module Status, you will arrive at the appropriate Module Properties dialog for the alarm.
Figure 12-6 is an ATU-C Module Properties dialog showing an ATU-C module in alarm:
Posted: Fri Oct 8 13:09:26 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.