Cisco ASR 9000 Series Aggregation Services Router MIB Specification Guide
Chapter 4 - Monitoring Notifications
Downloads: This chapterpdf (PDF - 124.0KB) The complete bookPDF (PDF - 2.96MB) | Feedback

Table of Contents

Monitoring Notifications

SNMP Notification Overview

Enabling Notifications

Cisco SNMP Notifications

Environmental or Functional Notifications

Flash Card Notifications

Interface Notifications

Routing Protocol Notifications

Redundancy Framework Notifications

Netsync Notifications

Subscriber Session Notifications

Monitoring Notifications

This chapter describes the Cisco ASR 9000 Series router notifications supported by the MIB enhancements feature introduced in Cisco IOS XR Software Release 3.7. SNMP uses notifications to report events on a managed device. The notifications are traps for different events. The router also supports other notifications not listed.

This chapter contains the following sections:

SNMP Notification Overview

An SNMP agent can notify the SNMP manager when important system events occur, such as the following:

  • An interface or card starts or stops running
  • Temperature thresholds are crossed
  • Authentication failures occur

When an agent detects an alarm condition, the agent:

  • Logs information about the time, type, and severity of the condition
  • Generates a notification message, which it then sends to a designated IP host

SNMP notifications are sent as one of the following:

  • Traps—Unreliable messages, which do not require receipt acknowledgement from the SNMP manager.

To use SNMP notifications on your system, you must specify their recipients. These recipients indicate where Network Registrar notifications are directed. By default, all notifications are enabled, but no recipients are defined. Until you define the recipients, no notifications are sent.

Many commands use the keyword traps in the command syntax.


NoteMost notification types are disabled by default. However, some notification types cannot be controlled with the snmp command. For example, some notification types can be enabled by snmp or CLI and other types are enabled by a combination of CLI and snmp. The linkUpDown notifications are controlled by the snmp trap link-status and snmp-server trap link ietf commands.


Specify the trap types if you do not want all traps to be sent. Then use multiple snmp-server traps commands, one for each of the trap types that you used in the snmp host command.

Enabling Notifications

You can enable MIB notifications using either of the following procedures:

  • Using the command-line interface (CLI)—Specify the recipient of the trap message and specify the types of traps sent. The enabling command also specifies which types of traps are enabled. For detailed procedures, go to the following URL:

http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.7/vfw/command/reference/vfr37snp.html

  • Performing an SNMP SET operation with the setany command—To enable or disable MIB notifications, perform an SNMP SET operation on a specific object.

To enable the notifications, set the object to true (1).

To disable the notifications, set the object to false (2).

For detailed procedures, go to the following URL:
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.7/system_management/command/reference/yr37snmp.html


NoteIf you issue the snmp-server traps command without a notification-type argument, the router generates traps for all types of events, which might not be desirable. Some MIBs require the user to set additional objects to enable some notifications.


Cisco SNMP Notifications

This section contains tables that describe a MIB event, why the event occurred, and a recommendation as to how to handle the event. Each table lists the following information:

  • Event—The event display
  • Description—What the event indicates
  • Probable cause—What might have caused the notification
  • Recommended action—Recommendation as to what should be done when the particular notification occurs

NoteIn the following tables, where“no action is required” is documented, there might be instances where an application, such as trouble ticketing, occurs. For detailed information, go to the following URL:
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.7/system_management/command/reference/yr37snmp.html


Environmental or Functional Notifications

Table 4-1 lists notifications generated for events that might indicate the failure of the
Cisco ASR 9000 Series router or conditions that might affect router functionality.

 

Table 4-1 Environmental or Functional Notifications

Event
Description
Probable Cause
Recommended Action
cefcModuleStatusChange

Indicates that the status of a module has changed.

Module has unknown state.

Enter the show platform command to view error message details. For syslog messages associated with this event, consult Messages and Recovery Procedures.

 

 

Module is operational.

No action is required.

 

 

Module has failed due to some condition.

Enter the show module command to view error message details. For syslog messages associated with this event, consult Messages and Recovery Procedures.

cefcPowerStatusChange

Indicates that the power status of a FRU has changed.

FRU is powered off due to unknown problem.

Enter the show environment command to check the actual power usage. For syslog messages associated with this event, consult Messages and Recovery Procedures.

 

 

FRU is powered on.

No action is required.

 

 

FRU is administratively off.

No action is required.

 

 

FRU is powered off as the available system power is insufficient.

Enter the show environment command to check the actual power usage.

cefcFRUInserted

Indicates that a FRU was inserted.

A new field-replaceable unit such as a fan, transceiver, power supply, or redundant power supply was added.

No action is required.

cefcFRURemoved

Indicates that a FRU was removed.

A field-replaceable unit such as a fan, transceiver, power supply, or redundant power supply was removed.

Replace the field-replaceable unit.

dsx1LineStatusChange

The dsx1LineStatus is a bit map that contains loopback state and failure state information.

When a failure is detected, the corresponding dsx1LineStatus bit should change to reflect the failure. For example, when a Receiving LOS failure is detected, the corresponding bit (bit 64) should be set to indicate the failure and as a result the dsx1LineStatus changes.

When the dsx1LineStatus reports failures, the recommended action is correction of the conditions causing the error.

ciscoSonetSectionStatusChange

Indicates that the value of sonetSectionCurrentStatus has changed.

Section loss of:

  • Frame failure
  • Signal failure

Enter the show controllers command for the interface and check that the Alarm Defects are None and Active Alarms are Zero.

ciscoSonetPathStatusChange

Indicates that the value of sonetPathCurrentStatus has changed.

Caused due to:

  • sonetPathSTSLOP
  • sonetPathSTSAIS
  • sonetPathSTSRDI
  • sonetPathUnequipped
  • sonetPathSignalLabelMismatch

Enter the show controllers command for the interface and check that the Alarm defects are None and Active Alarms are Zero.

ciscoSonetLineStatusChange

Indicates that the value of sonetLineCurrentStatus has changed.

Caused due to:

  • sonetLineAIS
  • sonetLineRDI

Enter the show controllers command for the interface and check that the Alarm Defects are None and Active Alarms are Zero.

dsx3LineStatusChange

Indicates that the value of dsx3LineStatus has changed. It is a bit map containing loopback state and failure state information.

Caused due to:

  • link failure
  • hardware issue

If a link fails or a hardware issue appears, alarms (single or mulitple depending on the failure) are generated.

A bit position is defined for each failure and the sum of all the failed bit positions is set to dsx3LineStaus. A dsx3LineStatusChange notification is generated whenever there is a change in the value of dsx3LineStatus.

When the dsx3LineStatus reports failures, check for the bit position to identify the cause of failure.

Flash Card Notifications

Table 4-2 lists CISCO-FLASH-MIB notifications generated by Cisco ASR 9000 Series router flash cards. These notifications indicate the failure of a flash card or error conditions on the card that might affect the functionality of all interfaces.

 

Table 4-2 Flash Card Notifications

Event
Description
Probable Cause
Recommended Action
ciscoFlashDeviceInsertedNotif

Indicates a removable flash device was inserted into the router.

A removable flash device was inserted into the router.

Check for the flash card that was inserted from ciscoFlashDeviceTable.

This information is also provided in the notification itself.

ciscoFlashDeviceRemovedNotif

Indicates a removable flash card was removed from the router.

A removable flash device was removed from the router.

Check the ciscoFlashDeviceTable to identify the removed flash card.

This information is also provided in the notification itself.

Interface Notifications

Table 4-3 lists notifications generated by the router for link-related (interface) events.

 

Table 4-3 Interface Notifications

Event
Description
Probable Cause
Recommended Action
linkDown

Indicates that a link is about to enter the down state, which means it cannot transmit or receive traffic. The ifOperStatus object shows the previous state of the link. Value is down(2).

An internal software error might have occurred.

Use the CLI command, show ip interface brief, to determine the cause of the interface down.

linkUp

Indicates that the link is up. The value of ifOperStatus indicates the new link state. Value is up(1).

The port manager reactivated a port in the linkdown state during a switchover.

No action is required.

Routing Protocol Notifications

Table 4-4 lists BGP4-MIB notifications that are Border Gateway Protocol (BGP) state changes generated by the Cisco ASR 9000 Series router to indicate error conditions for routing protocols and services.

 

Table 4-4 Routing Protocol Notifications

Event
Description
Probable Cause
Recommended Action
bgpEstablished

The BGP Finite State Machine (FSM) enters the ESTABLISHED state. It becomes active on the router.

The BGP routing protocol changed status.

No action is required.

bgpBackwardTransition

Indicates BGP protocol transition from a higher-level state to a lower-level state. The prefix count for an address family on a BGP session exceeded the configured threshold value.

The BGP routing protocol changed status.

This threshold value is configured using the CLI command neighbor nbr_addr max_prefixes
[threshold] [warning-only]

Redundancy Framework Notifications

Table 4-5 lists CISCO-RF-MIB notifications that can occur in a redundant system. There are two types of notifications:

  • Switch of Activity (SWACT)—Either a forced or automatic switch of active status from the active unit to the standby unit. The former standby unit is now referred to as the active unit.
  • Progression—The process of making the redundancy state of the standby unit equivalent to that of the active unit. This includes transitioning the RF state machine through several states, which drives the clients on the active unit to synchronize any relevant data with their peer on the standby unit.

 

Table 4-5 Redundancy Framework Notifications

Event
Description
Probable Cause
Recommended Action
ciscoRFSwactNotif

Indicates that the RF state changed.

A switch of activity notification is sent by the newly active redundant unit.

A switch of activity occurs. If a SWACT event is indistinguishable from a reset event, then a network management station should use this notification to differentiate the activity.

If the switchover occurred because the active unit failed (indicated by cRFStatusLastSwactReasonCode), see if there are any hardware failures; otherwise, no action is required.

ciscoRFProgressionNotif

Indicates that the RF state changed.

The active redundant unit RF state changed or the RF state of the peer unit changed.

To avoid an increase of notifications for all state transitions, send notifications for transitions to the following RF states:

  • standbyCold(5)
  • standbyHot(9)
  • active(14)
  • activeExtraload(15)

Netsync Notifications

Table 4-6 lists CISCO-NETSYNC-MIB notifications that can occur in a system.

 

Table 4-6 Netsync Notifications

Event
Description
Probable Cause
Recommended Action
ciscoNetsyncSelectedT0Clock

Indicates that the source selected for T0 (system timing input) has changed.

Change in system timing input.

No action is required.

ciscoNetsyncSelectedT4Clock

Indicates that the source selected for a T4 output (external clock output) has changed.

Change in external clock output.

No action is required.

ciscoNetsyncInputSignalFailureStatus

Indicates that there has been a signal failure on an input

A signal going out-of-band.

The trap indicates the cause of the failure, and the user will have to investigate further.

ciscoNetsyncInputAlarmStatus

Indicates that there has been an alarm on the input

An interface going down.

The trap indicates the cause of the failure, and the user will have to investigate further.

Subscriber Session Notifications

Table 4-6 lists CISCO-SUBSCRIBER-SESSION-MIB notifications that can occur in a system.

 

Table 4-7 Netsync Notifications

Event
Description
Probable Cause
Recommended Action
csubSessionRisingThreshNotif

Indicates that the the subscriber count is exceeding the configured rising threshold value.

An instance of csubAggStatsUpSessions exceeding the corresponding instance of csubSessionRisingThresh.

No action is required.

csubSessionFallingThreshNotif

Indicates that the subscriber count drops below the configured falling threshold value.

An instance of csubAggStatsUpSessions falling below the corresponding instance of csubSessionFallingThresh.

No action is required.

csubSessionDeltaPercentThreshNotif

Indicates that tfalling percent of subscriber session exceeds the configured delta percent value in the configured evaluation time.

An instance of csubAggStatsUpSessions dropping by the percentage indicated by the corresponding csubSessionDeltaPercentLossThresh within the amount of time indicated by the corresponding subSessionThresholdEvalInterval.

No action is required.