Event History and Current Alarms

11.1 Event History Window

11.2 Current Alarm Window

11.3 Viewing Alarms Using the Command Line Interface

11.4 Alarm Severities Guidelines

11.5 Alarm/Event Status Changes

11.6 Examples of Module Alarms

Event History and Current Alarms

This chapter discusses the dialogs associated with Cisco 6100 or ViewRunner for Windows events and alarms.

11.1 Event History Window

The Event History Window displays all the alarms that have been asserted and cleared for a particular Cisco 6100 system. The ViewRunner software polls the node for new alarms and events at 15 second intervals by default throughout a session. You may may change this poll interval by selecting the Options >> ViewRunner Preferences menu option.

Note ViewRunner displays only the alarms or events as they are reported by the Cisco 6100 system or as they are generated by the ViewRunner software itself. Alarms from other network elements in the end-to-end ATM connection are not reported by ViewRunner.

The Cisco 6100 node saves up to 200 events at a time, beginning with number "1" and incrementing indefinitely. When the node event log exceeds 200 events, the oldest event in the queue, Event 1, is removed, and the newest event is added to the bottom of the queue as Event 201. Therefore, depending on how many alarms/events are generated, the node queue could begin with sequence Event 101 and end with Event 300.

ViewRunner, on the other hand, can save more than 200 events at a time. That is, if the node alarm/event queue is showing Event 101 through 300, the ViewRunner may be displaying alarm/event 50 through 300 depending on how long the ViewRunner session has been active and what the node was showing at the time the session began. There is a one-to-one correspondence between the sequence number of an alarm/event in the node with the Sequence Id of an alarm/event displayed by the ViewRunner for the most recent 200 events. However, if alarms/events have been removed from the top of queue at the node between ViewRunner sessions or between polls, the user will never see them. For example, if more than 200 events occur since the last ViewRunner session, you would not see those that had already been removed from the node queue when you begin the new session.

If the ViewRunner detects a system controller (SC) reset during an active session, all displayed alarms/events are removed from the Event History window, and only alarms/events occurring after the reset are displayed. The Cisco 6100 node itself loses alarm history and begins numbering again at "1" after an SC reset.

Figure 11-1: Event History Window

Note Once the Event History window has been opened, it cannot be closed. Notice that the "x" in the upper right hand corner of the window is disabled. However, you can iconify the window to get it off the screen.

The fields in this window are described in Table 11-1.

Field	Field Description
Sequence Id	The sequence number of the alarm/event in the ViewRunner's event log for this session. The field also contains an alarm icon whose color indicates something about the severity of the alarm: Red - Critical/Asserted Orange - Major/Asserted Yellow - Minor/Asserted Green - Critical/Cleared, Major/Cleared, and Minor/Cleared, Blue - Undefined White - Information
Severity	The severity of the alarm/event as determined by Cisco. The alarm/event severities are defined as follows. Service outage is defined as either line down or no cell throughput. Service impairment is defined as cell loss not associated with network congestion, but is great enough to result in a noticeable throughput loss. Undefined - indicates that the format of the data returned from the node was faulty
Log Time	The date and time on which the alarm/event occurred.
Entity	The module against which the alarm/event is asserted. The information in this field can be used to help track down the alarm/event in this chapter. The entity can be any one of the following: ATU-C, SC, NI¹, LIM² controller, LIM, Slot, ViewRunner, and Unknown. An "Unknown" entity is returned only when the format of the data from the node is faulty.
AID	The Access Identifier as in the chassis and slot number associated with the alarm/event. The information in this field can pinpoint the source of the alarm/event and thus help the user to further diagnose what the problem might be. ViewRunner will display "Unknown" in the AID field if an alarm/event was asserted by an entity which was later deleted, or by an entity that was added but not yet "autodiscovered" by ViewRunner before generating an alarm. By clicking on the blue, underlined text in this field, you can navigate directly to the entity and slot from which the alarm was received.
Status	The current status of the alarm as in: Asserted - an alarm/event has been generated by an entity. Cleared - a previously asserted alarm has been cleared. Info - informational event only. Undefined - indicates that the format of the data returned from the node was faulty
Description	A short description of the alarm/event. This description should be the same as the descriptions found in the alarm/event tables in the subsections of this chapter. This description is a predefined string based on the entity and event code from the node. See the Cisco 6100 Maintenance and Troubleshooting Manual for exceptions to this definition.

Table 11-1: Event History Window Field Definitions

Field Field Description

Sequence Id

The sequence number of the alarm/event in the ViewRunner's event log for this session. The field also contains an alarm icon whose color indicates something about the severity of the alarm:

Red - Critical/Asserted
Orange - Major/Asserted
Yellow - Minor/Asserted
Green - Critical/Cleared, Major/Cleared, and Minor/Cleared,
Blue - Undefined
White - Information

Severity

The severity of the alarm/event as determined by Cisco. The alarm/event severities are defined as follows.

Service outage is defined as either line down or no cell throughput. Service impairment is defined as cell loss not associated with
network congestion, but is great enough to result in a noticeable
throughput loss.
Undefined - indicates that the format of the data returned from the
node was faulty

Log Time

The date and time on which the alarm/event occurred.

Entity

The module against which the alarm/event is asserted. The information in this field can be used to help track down the alarm/event in this chapter. The entity can be any one of the following: ATU-C, SC, NI¹, LIM² controller, LIM, Slot, ViewRunner, and Unknown. An "Unknown" entity is returned only when the format of the data from the node is faulty.

AID

The Access Identifier as in the chassis and slot number associated with the alarm/event. The information in this field can pinpoint the source of the alarm/event and thus help the user to further diagnose what the problem might be. ViewRunner will display "Unknown" in the AID field if an alarm/event was asserted by an entity which was later deleted, or by an entity that was added but not yet "autodiscovered" by ViewRunner before generating an alarm.

By clicking on the blue, underlined text in this field, you can navigate directly to the entity and slot from which the alarm was received.

Status

The current status of the alarm as in:

Asserted - an alarm/event has been generated by an entity.
Cleared - a previously asserted alarm has been cleared.
Info - informational event only.
Undefined - indicates that the format of the data returned from the
node was faulty

Description

A short description of the alarm/event. This description should be the same as the descriptions found in the alarm/event tables in the subsections of this chapter. This description is a predefined string based on the entity and event code from the node. See the Cisco 6100 Maintenance and Troubleshooting Manual for exceptions to this definition.

¹NI=network interface
²LIM=line interface module

The contents of the ViewRunner Event History 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.

It is also possible for the user to selectively remove entries from the display simply by selecting those entries and deleting them. Events can be selected in the Event History View and deleted by clicking the Alarm toolbar deletion button (looks like an x - see toolbar). This does not remove the alarms/events permanently from the Cisco 6100. They are removed only from the ViewRunner display. You select by clicking the Sequence Id number of each row. Use Shift or Ctrl to select multiple entries, either sequentially or randomly as desired.

Logical service oriented screen navigation is available in the Event History window. Just click on the blue underlined text, and ViewRunner will take you to the properties window of the chassis, slot, and port where the alarm was asserted.

11.2 Current Alarm Window

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 Event History window, except that it has fewer columns.

In the Current Alarms window, current alarms are retrieved and displayed when the window is first opened, and when the user manually requests a refresh.

Note The Current Alarm window is not updated dynamically using the existing ViewRunner Preferences > Alarm and Event polling interval.

Figure 11-2 is an example of the Current Alarms window.

Figure 11-2: Current Alarm Window

Logical service oriented screen navigation is available in the Event History window. Just click on the blue, underlined text, and ViewRunner will take you to the properties window of the chassis, slot, and port where the alarm was asserted.

Note Once the Current Alarms window has been opened, it cannot be closed. Notice that the "x" in the upper right hand corner of the window is disabled. You can iconify the window, however to get it off the screen.

11.3 Viewing Alarms Using the Command Line Interface

To view alarms on the Cisco 6100 system, use the command line interface (CLI). For information on the command syntax and use of the CLI, refer to the ViewRunner for Windows Installation and Administration Guide.

The following are some examples of CLI commands used to show alarms on various Cisco 6100 components.

To show all alarms in the system, enter one of the following commands

show alarms
show alarms sys

To show all major and critical alarms in the system, enter the following command:

show alarms crit.maj sys

To show all alarms for the 6110 LCC chassis number 3, enter the following command:

show alarms chassis L.3

To show all minor alarms in all 6110 LCC chassis, enter the following command:

show alarms min chassis L

To show all the alarms on the ATU-C module in the Cisco 6100 MC number 1, slot 12, enter the following command:

show alarms atuc M.1.12

To show all line port critical alarms on the 6110 LCC number 2, slot 12, port 2, enter the following command:

show alarms crit lp L.2.12.2

In the ViewRunner for Windows software release 2.0, the valid command is show alarms with all of its options.

Note For more information on events and alarms, including descriptions of all Cisco 6100 alarms and corrective action, refer to the Cisco 6100 Alarm Summary Guide.

11.4 Alarm Severities Guidelines

The following rules are used to define an event versus an alarm and the severity associated with each.

All events are not alarms. Events with a severity of "Info" (informational), are not alarms.
Events that are not alarms (informational events) are not followed in the event log by a cleared message.
An informational event is not defined as service affecting. Service affecting is defined in a binary sense for the purposes of alarm characterization - the subscriber is only service affected if taken out of service. Temporary traffic throughput impairments (loss of ATM cells, buffer overflows, parity errors, etc.) result in an informational event, but are typically expected to be recoverable in a reasonably transparent fashion to the subscriber.
Repeated informational events of this type (as defined in the actions below) may trigger an alarm in a future release.
Alarms all have a severity of minor, major, or critical.
Alarm severity is based on guidelines set forth in TR-NWT-000057, Functional criteria for DLC Systems; pp. 13-2 to 13-3, as follows:
Critical - greater than 128 customer lines are out of service
Major - greater than 24 customer lines are out of service
Minor - 2 to 23 customer lines are out of service

Exceptions to the above guidelines are used as follows.

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.
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:

Service outage is defined as either line down or no cell throughput.
Service impairment is defined as cell loss not associated with network congestion, but is great enough to result in a noticeable throughput loss.
- Critical - Service outage of greater than 128 subscriber lines.
- Major - Service outage of 24-128 subscriber lines or service impairment for at least 25% of the active subscribers.
- Minor - Service outage of 2-23 subscriber lines or service impairment for 10-25% of active subscribers.
- Informational - Information only or system anomalies (e.g., momentary cell loss or parity errors).

11.5 Alarm/Event Status Changes

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 those outstanding alarms were asserted against that module.

11.6 Examples of Module Alarms

When you either click on the hyperlink in the Event History window or the Current Alarms window or you navigate to the AID of the alarm, you will arrive at the appropriate Module Properties dialog for the alarm.

Figure 11-3 is an ATU-C Module Properties dialog showing an ATU-C module in alarm:

Figure 11-3: ATU-C Module in Alarm

Figure 11-4 is a Network Interface Module Properties dialog showing an NI module in alarm:

Figure 11-4: Network Interface Module in Alarm

Note Please see the Cisco 6100 Maintenance and Troubleshooting Manual for more information on events and alarms, including descriptions of all Cisco 6100 alarms and appropriate responses to them.

Table of Contents