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
•Enabling Notifications
•Cisco SNMP Notifications
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.
Note Most 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
Note If 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
Note In 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.
|
Feedback
