|
|
This chapter describes the various ways you can view events in ViewRunner, the event severity guidelines, alarm and event status changes, and examples of module alarm events associated with Cisco 6100 Series systems.
In the ViewRunner for Windows software, you can view events generated by the Cisco 6100 Series system in one of the following ways:
In ViewRunner, use the Event History View dialog box to show all of the events that were asserted and cleared for a particular Cisco 6100 Series system.
During each session, default interval poll settings in the ViewRunner software cause it to poll the node for new events at 15-second intervals. You can change this poll interval by selecting Options > ViewRunner Preferences. Doing so, opens the ViewRunner Preferences: Interval Poll Settings dialog box (see Figure 11-1) where the interval can be increased or decreased.

The Cisco 6100 Series system node saves no more than 200 events at one time, beginning with number 1 and incrementing indefinitely. When the node event log has more than 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 the number of generated events, the node queue could begin with event 101 and end with event 300.
The ViewRunner for Windows software can save more than 200 events at a time. If, for example, the Cisco 6100 Series node event queue shows events 101 through 300, the ViewRunner could be displaying events 50 through 300. (The number of events in the ViewRunner display depends on how long the ViewRunner session has been active and on what the node was showing at the time the session began.)
The event numbers for the Cisco 6100 Series system display and the ViewRunner display correspond. For example, event 50, in the Cisco 6100 Series system display, corresponds to event 50 in the ViewRunner display. Events must be removed at the node or between ViewRunner sessions or polls. After events are removed from the top of the queue, they do not appear in the ViewRunner display. For example, if more than 200 events occur between consecutive ViewRunner sessions, you do not see those that were already removed from the node queue when you begin the new ViewRunner session. ViewRunner generates an alarm indicating that events have been missed during the current poll.
If the ViewRunner detects a system controller (SC) module reset during an active session, all displayed events are removed from the Event History View dialog box, and only events occurring after the reset are displayed. The Cisco 6100 Series system node loses event history and begins numbering again at 1 after an SC module reset.
Figure 11-2 is an example of the ViewRunner for Windows Event History View dialog box.

The fields in the Event History View dialog box are described in Table 11-1.
| Field | Field Description |
|---|---|
Sequence number of the event in the ViewRunner Event History View dialog box for this session. The field also contains an alarm icon in which the color indicates the severity of the event:
| |
Cisco determines the severity of the event. Event severities are defined as follows:
| |
The date and time when the event occurred. | |
The module that the event is asserted against. The information in this field can be used to help locate the event in the Cisco 6100 Series Alarm Summary Guide. The entity can be any one of the following: CAP ATU-C, SC, NI1, LIM2 controller, LIM, Slot, ViewRunner, or Unknown. An Unknown entity appears only if the format of the data from the node is faulty. | |
Corresponds to the chassis and slot number associated with the event. You can use the information in this field to pinpoint the source of the event and thus isolate the problem. ViewRunner displays Unknown in the AID field if an event was asserted by an entity that was later deleted, or by an entity that was added but not yet discovered by ViewRunner at the time the event was generated. To go directly to the entity and slot location in which the event was received, click the underlined text in this field. | |
The current status of the event. Possibilities include
| |
Description | A short description of the event. Corresponds to one of the descriptions found in the system event definitions tables in the Cisco 6100 Series Alarm Summary Guide. This description is a predefined string based on the entity and event code from the node. |
| 1NI = network interface 2LIM = line interface module 3AID = access identifier |
To sort the contents of the ViewRunner Event History View dialog box according to any one of the fields in the preceding table, click the field header (such as AID, Log Time, Severity). If you click more than one column heading, you can nest the results of sort operations. The order in which you select headings determines the order in which results are nested. If there are more entries than can fit in the dialog box, a scroll bar appears, allowing you to scroll through the entries.
To remove events from the display, select the events and delete them. Select events in the Event History View dialog box.
To select an event, click the Sequence Id number of each row. Use the Shift or Ctrl key to select multiple events.
To delete the selected events, click the Alarm toolbar deletion button. (This button is the x next to the discovery icon on the ViewRunner toolbar; see Figure 11-3.) Removing an event does not delete it permanently from the Cisco 6100 Series system. It is removed only from the ViewRunner display.

The Current Alarms View dialog box lists all currently asserted alarm events in the system, including module, slot, and image alarm events. The dialog box format is similar to that for the Event History View dialog box.
You can use the Current Alarms View dialog box to retrieve and display current alarm events. You can do this when the dialog box is first opened or after you manually request a refresh. To retrieve current alarm events, you can also go to Options > ViewRunner Preferences to set a smaller polling interval in the ViewRunner Preferences dialog box (see Figure 11-1).
In the Current Alarms View dialog box, click the blue underlined text to have ViewRunner take you to the Properties dialog box of the chassis, slot, and port where the alarm event was asserted.
Figure 11-4 is an example of the Current Alarms View dialog box.

Logical service-oriented dialog box navigation is available in the Event History View dialog box. Just click the blue, underlined text, and ViewRunner takes you to the Properties dialog box of the chassis, slot, and port where the alarm was asserted.
To view alarms for the Cisco 6100 Series 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 Series system components.
show alarms show alarms sys
show alarms curtained 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
In the ViewRunner for Windows software, Release 2.0, the valid command is show alarms with all of its options.
There are four types of events generated by the Cisco 6100 Series system and viewed in ViewRunner for Windows:
The following sections describe the guidelines for each type of event.
The following are guidelines used to distinguish information events from other events:
An exception to the above guidelines is as follows.
In the Impact sections of the following chapters, some events affect a significant number of subscribers. If the alarm condition is such that the system is likely to recover in time (for instance, buffer overflow), the alarm will be categorized as an information event.
Alarm severity is based on guidelines set forth in TR-NWT-000057, Functional Criteria for DLC Systems. The guidelines are as follows:
Normally, an alarm event causes a service impairment or a service outage. However, some alarm events do not affect service. A service impairment typically results in a loss of end-to-end traffic for some number of subscriber connections (one to several) for a brief period of time (milliseconds to seconds, but normally less than one minute unless repeat occurrences are encountered). A service outage is the absolute loss of the ability to connect one or more subscribers.
In the ViewRunner Event History View dialog box, alarm events are followed by an additional event showing a Cleared event status, which means the alarm event is corrected.
The following are guidelines used to distinguish minor alarm events from other events:
Service outage severities are coded as either a major alarm event or a critical alarm event, depending on the number of subscribers affected. If four or fewer subscribers are out of service, the event is a major alarm event.
Service outage severities are coded as either a major alarm event or a critical alarm event, depending on the number of subscribers affected. If more than four subscribers are out of service, the event is a critical alarm event.
Alarm events that have been asserted by the Cisco 6100 Series system are followed by both:
1. A Cleared event
2. An Info event---In effect, clears all alarm events associated with a particular entity at a
particular slot
For example, you can clear some alarm events if the problem is caused by congestion or a single parity error. At other times, you must reset or reinsert the module generating the alarm event. In this case, the only event returned is Event 128, "Module was detected," which clears whatever outstanding alarm events were asserted against that module.
ViewRunner for Windows Release 2.4.0 supports two chassis alarm events. Both of these alarms are critical and they both report fan tray status. You can view chassis alarms in the Event History View dialog box or in the Current Alarms View dialog box. Only the Cisco 6130 system supports a fan tray at the time of this Release.
The first alarm, MC Fan Failure, occurs when you have checked the Fan Tray Present toggle on the 6100 Properties dialog box (see Figure 11-5), but a fan tray is not present.
The second alarm, MC Fan Required, occurs when you have configured a module requiring a fan tray, such as the DMT-2 ATU-C module and no fan tray can be detected. In this instance, the DMT-2 module will detrain and issue a corresponding critical module alarm.

You can arrive at the appropriate Module Properties dialog box for the alarm in one of three ways:
1. Click the hyperlink in the Event History View dialog box.
2. Click the Current Alarms View dialog box.
3. Navigate to the AID of the alarm.
Figure 11-6 is a Subtend Host Module Port Properties dialog box showing the port of a Subtend Host module in alarm.

Figure 11-7 is a Network Interface Module Properties dialog box showing an NI module in alarm.

![]()
![]()
![]()
![]()
![]()
![]()
![]()
Posted: Tue Oct 12 08:14:14 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.