Network Interface Module Events

This chapter explains how to diagnose and handle network interface (NI) module events generated by the Cisco 6100 Series system. The following information is presented for each of the events:

Event summary---A summary of the event information including the ID, event name, and its severity.
Description---A short description of the event. Appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser.
Impact---A short discussion of the probable impact of the event. It lists, for example, the number of subscribers who could be affected by this problem.
Action---A step-by-step procedure for handling the event described in the section.

If none of the actions presented for the event are successful, contact the Cisco Technical Assistance Center (TAC) for additional support.

Note Refer to "Cisco 6100 Series System Event Troubleshooting" for detailed information on viewing events in the ViewRunner management software. Refer to "Event Guidelines and Definitions" for detailed information on event severity guidelines and alarm event status changes.

Table 7-1 lists NI module events and their IDs, definition, severity, and description. A detailed explanation of these events and corrective actions required (if any) is located in subsections in this chapter.

Table 7-1: Network Interface Module Events
ID Definition Severity Description

128

LR_CREATE_OBJ

Info

Module was detected

129

LR_PING_FAIL

Critical

Module did not respond to the system monitor

Table 7-1: **Network Interface Module Events**
ID	Definition	Severity	Description
128	LR_CREATE_OBJ	Info	Module was detected
129	LR_PING_FAIL	Critical	Module did not respond to the system monitor

Note Events with an id less than 128 are specific to the module in alarm. Events with an id value greater than or equal to 128 are system-wide events.

7.1 Module Was Detected

Event Summary

ID	Event Name	Severity
128	LR_CREATE_OBJ	Info

Description

The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:

Module was detected

Impact

Events of this type do not indicate service impairment or loss.

Action

This is an information event, not an alarm event. Information events do not represent a state change and therefore are not followed by a Cleared event.

Information events are typically one-time occurrences that are corrected by the module without a reset. They do not cause service degradation.

No craft action is required.

7.2 Module Did Not Respond to System Monitor

Event Summary

ID	Event Name	Severity
129	LR_PING_FAIL	Critical

Description

The following description appears in the ViewRunner for Windows Event History View dialog box or the ViewRunner for HP OpenView Error Events Browser:

Module did not respond to the system monitor

Impact

An event of this severity causes loss of service for more than four subscribers. Here are two examples of this type of event:

Loss of a LIM controller module could cause loss of service for up to 80 subscribers.
Loss of a NI module could cause loss of service for 64 to 400 subscribers, the number affected depending upon configuration (Digital Off-Hook or Direct Connect).

Action

In some cases, a module forces itself into a self-test based on the alarm condition. In other cases, the system controller (SC) module forces the alarmed module to reset. A module reset forces the module to be power cycled, self-tested, and reconfigured into the slot by the SC module.

Several alarm event conditions are cleared by a module reset. Look for the alarm event to clear within 1 minute. An alarm event is cleared when the SC module faceplate alarm LED changes from red to off.

In the ViewRunner management software, two actions show that an alarm event is cleared:

The receipt of a Cleared event in the Event History View dialog box (in ViewRunner for Windows) or the Error Events Browser (in ViewRunner for HP OpenView)
A change in the color of the alarmed module ejector tab changes from red to green

If the alarm event does not clear:

Step 1 Remove and reinsert the module. This forces a module to reset if neither the module nor the SC module could force a reset. A module reset usually clears all alarm conditions.

Step 2 Observe the SC module alarm LED or the ViewRunner ejector tabs to see if the alarm condition returns. If the previous problem persists, the condition will probably reoccur within 1 minute.

Step 3 If the alarm condition persists, replace the module.

Table of Contents

Network Interface Module Events