Monitoring Notifications
This chapter describes the Cisco 7200 router notifications supported by the MIB enhancements feature introduced in Cisco IOS Release 12.2SB REL4. SNMP uses notifications to report events on a managed device. The notifications are traps or informs for different events. The router also supports other notifications not listed.
Note
Many commands use the keyword traps in the command syntax. The keyword traps refers to notifications that are either traps, informs, or both. The tables in this chapter use the term traps even though the event might be an inform.
This chapter contains the following sections:
•
Notification Overview
•
Enabling Notifications
•
Cisco SNMP Notifications
Notification Overview
An SNMP agent can notify the 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 either:
•
Traps—Unreliable messages, which do not require receipt acknowledgement from the SNMP manager.
•
Informs—Reliable messages, which are stored in memory until the SNMP manager issues a response. Informs use more system resources than traps.
To use SNMP notifications on your system, you must specify trap recipients. These recipients indicate where Network Registrar notifications are directed. By default, all notifications are enabled, but no trap recipients are defined. Until you define the recipients, no notifications are sent.
Many commands use the word traps in the command syntax. Unless there is an option in the command to select either traps or informs, the keyword traps refers to either traps, informs, or both. Use the snmp-server host command to specify whether to send SNMP notifications as traps or informs. The types of traps can be specified in both commands.
Note
Most notification types are disabled by default. However, some notification types cannot be controlled with the snmp command. For example, some notification types are always enabled and other types are enabled by a different command. The linkUpDown notifications are controlled by the snmp trap link-status command. If you enter this command with no notification-type keywords, the default is to enable all notification types controlled by this command.
Specify the trap types if you don't want all traps to be sent. Then use multiple snmp-server enable traps commands, one for each of the trap types that you used in the snmp host command. The Event Table must have an entry that specifies the action that is to be performed.
For detailed information about notifications and a list of notification types, go to the following URLs:
•
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_1/
•
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a008021de3e.shtml
•
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf014.html
Enabling Notifications
You can enable MIB notifications using either of the following procedures:
Command line interface (CLI)—Specify the recipient of the trap message and specify the types of traps sent. This command also specifies which types of informs are enabled.
•
For detailed procedures, go to:
–
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a008021de3e.shtml
–
http://www.cisco.com/en/US/docs/ios/11_3/feature/guide/snmpinfm.html
•
Performing an SNMP SET operation using the setany command— To enable or disable MIB notifications, perform an SNMP SET operation on the a specific object.
–
To enable the notifications set the object to true(1)
–
To disable the notifications, set the object to false(2)
Foe detailed procedures, go to:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/6.x/configuration/guide/snmp.html
Note
If you issue the snmp-server enable 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:
•
Text string—The event display
•
Brief 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 required is documented, there might be instances where an application, such as trouble ticketing (An application that processes certain alarms and generates a ticket for a person or a system to manage before that ticket closes for some event.) occurs. For example, if a field replaceable unit (FRU) is replaced, then a message must be sent to close the trouble ticket according to operations and processes installed in your system.
Environmental or Functional Notifications
Table 4-1 lists notifications generated for events that might indicate the failure of the Cisco 7200 router or conditions that might affect the router's functionality.
Table 4-1 Environmental Notifications
|
|
|
|
|
Indicates that the status of a module has changed. |
Module has unknown state |
Enter the show module 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. |
|
Indicates that the power status of a field replaceable unit has changed. |
FRU is powered off because of an unknown problem. |
Enter the show power 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 because available system power is insufficient |
Enter the show power command to check the actual power usage. |
|
Indicates that a FRU was inserted. |
A new field replaceable unit like a GBIC, fan, port, power supply, or redundant power supply was added. |
No action is required. |
|
Indicates that a FRU was removed. |
A field replaceable unit like GBIC, fan, ports, power supply, or redundant power supply was removed. |
Replace the field replaceable unit. |
|
Indicates that a FRU status has changed. The chassisTempAlarm, chassisMinorAlarm, or chassisMajorAlarm object in this MIB has changed to the on (2) state. |
The chassis temperature is too high, a minor or major alarm has been detected. |
Inspect the indicated component closely to determine why it is operating out of the normal operating temperature range and whether it will eventually exceed the allowed operating temperature range. |
|
|
A redundant power supply has been powered off. |
Replace the FRU. |
|
|
One or more fans in the system fan tray have failed. Although this is a minor alarm, system components could overheat and be shut down. |
Replace the system fan tray. |
|
Indicates that a FRU status has changed. The chassisTempAlarm, chassisMinorAlarm, or chassisMajorAlarm object in this MIB has changed to the off (1) state. |
A redundant power supply has been powered on. |
No action required. |
cefcMIBEnableStatusNotification
|
Operational status changed. Indicates whether the system produces the cefcMIBNotifications. |
|
|
Cisco 7200 Port Adapter Notifications
Table 4-2 lists notifications generated by Cisco 7200 router port adapters (PA). These traps indicate the failure of a port adapter or error conditions on the PA card that might affect the functionality of all interfaces and connected customers. All of the sensors generate traps if the voltage passes the threshold level.
Table 4-2 Cisco 7200 Port Adapter Notifications
|
|
|
|
|
There has been an informational configuration change. An entry for the card is removed from the entPhysicalTable (which causes the value of entLastchangeTime to change). |
A card was removed. |
Replace the field replaceable unit. |
|
|
A PA card was added. |
No action required. |
|
|
A PA card operational status change occurred. |
No action required. |
entSensorThresholdNotification
|
Indicates that the sensor value crossed the threshold listed in entSensorThresholdTable. This variable reports the most recent measurement seen by the sensor and This variable indicates the value of the threshold. |
A specific module exceeded major sensor thresholds. |
Remove the configuration that bypasses the module shutdown due to sensor thresholds being exceeded. Shut down the module after removing the configuration. It exceeded major sensor thresholds. The command that shuts down the module in the event of a major sensor alarm has been overridden, so the specified module will not be shut down. The command used to override the shutdown is no environment-monitor shutdown. |
|
Sent when the alarm Card Stopped Responding OIR is asserted. |
You manually shut down the PA card, then you get the error. |
|
|
A previously asserted alarm is cleared. |
The agent generates this trap when a physical entity clears a previously asserted alarm. |
|
Interface Notifications
Table 4-3 lists IF-MIB notifications generated by the router for link-related (interface) events.
Table 4-3 Link Notifications
|
|
|
|
|
An interface is down. This is cleared by one or more Link Up traps for the same interface It can not transmit or receive traffic. The ifOperStatus object shows the link's previous state. Value is down(2). |
|
To see if link traps are enabled or disabled on an interface, check ifLinkUpDownTrapEnable (IF-MIB) for the interface. To enable link traps, set ifLinkUpDownTrapEnable to enabled(1). Enable the IETF (RFC 2233) format of link traps by issuing the CLI command snmp-server trap link ietf. |
|
An interface is now up after being down. Indicates that a link's status is no longer down. The value of ifOperStatus indicates the link's new state. Value is up(1). |
The port manager reactivated a port in the link-down state during a switchover. A port is only reactivated when the port data structures lack consistency between the active and standby supervisor engines. |
No action is required. |
Threshold Notifications
Table 4-4 lists MPLS-VPN-MIB notifications which are traps and informs that can occur when an environmental threshold is exceeded. Indicates that a threshold violation occurred.
Table 4-4 MPLS-VPN Notifications
|
|
|
|
mplsNumVrfRouteMidThreshExceeded
|
Indicates that the warning threshold is exceeded. |
The system limit of four route processors per VPN has been exceeded. The number of routes created has crossed the warning threshold. This warning is sent only at the time the warning threshold is exceeded. |
The configured RPs are too large to fit in the DF table for one VPN. Try to configure the groups among existing RPs in the hardware, or configure the RP in another VPN. |
mplsNumVrfRouteMaxThreshExceeded
|
Indicates that the maximum route limit was reached. |
A route creation was unsuccessful because the maximum route limit was reached. Another notification is not sent until the number of routes falls below the maximum threshold and reaches the maximum threshold again. |
Set the threshold value. The max-threshold value is determined by the maximum routes command in VRF configuration mode. |
mplsLdpFailedInitSessionThreshold
Exceeded
|
Indicates that a local LSR and an adjacent LDP peer attempt to set up an LDP session between them, but fail to do so after a specified number of attempts. |
Eight failed attempts occurred to establish an LDP session between a local LSR and an LDP peer, due to some type of incompatibility between the devices. Cisco routers support the same features across multiple platforms. Therefore, the most likely incompatibility to occur between Cisco LSRs is a mismatch of their respective ATM VPI/VCI label ranges. |
If you specify a range of valid labels for an LSR that does not overlap the range of its adjacent LDP peer, the routers will try eight times to create an LDP session between themselves before the mplsLdpFailedInitSessionThresholdExceedednotification is generated and sent to the NMS as an informational message. Operationally, the LSRs whose label ranges do not overlap continue their attempt to create an LDP session between themselves after the eight retry threshold is exceeded. In such cases, the LDP threshold exceeded notification alerts the network administrator to the existence of a condition in the network that may warrant attention. |
Service Notifications
Table 4-5 lists MPLS service notifications (MPLS-TE-MIB, MPLS-LDP-MIB,MPLS-VPN-MIB) which generated by the router to indicate conditions for services.
Table 4-5 MPLS-Service Notifications
|
|
|
|
|
Indicates that a VPN routing or forwarding instance (VRF) was assigned to an interface that is operational or for the transition of a VRF interface to the operationally up state. |
A VPN routing or forwarding instance (VRF) was assigned to an interface that is operational or a VRF interface transitions to the up state. |
No action is required. |
|
Indicates that a VRF was removed from an interface or a VRF interface transitioned to the operationally up state.
|
A VRF was removed from an interface or a VRF of an interface transitioned to the down state. |
Check the operation state of the interface OR the state of the connected interface on the adjacent router OR add the removed VRF. |
|
Indicates that the MPLS LDP session is in the up state. |
Trap generated when an LDP entity (a local LSR) establishes an LDP session with another LDP entity (an adjacent LDP peer in the network). |
No action is required. |
mplsLdpSessionDown |
Indicates that the MPLS LDP session is in the down state. |
Trap generated when an LDP session between a local LSR and its adjacent LDP peer is terminated. |
Check if the LDP session exists between the local LSR and adjacent LDP peer. |
|
Indicates that a local LSR establishes an LDP session with its adjacent peer LSR, but the two LSRs have dissimilar path vector limits. |
An LDP session has two adjacent peer LSRs with dissimilar path vector limits. The value of the path vector limit can range from 0 through 255; a value of "0" indicates that loop detection is off; any value other than zero up to 255 indicates that loop detection is on. |
Configure all LDP-enabled routers in the network with the same path vector limit. Accordingly, the mplsLdpPathVectorLimitMismatch object exists in the MPLS LDP MIB to provide a warning message to the NMS when two routers engaged in LDP operations have a dissimilar path vector limit. |
|
Indicates that a mplsTunnelOperStatus object for a configured tunnel is about to transition from the Down state to any state except NotPresent. |
A configured tunnel transitioned from the Down state to any state except NotPresent. May be caused by an administrative or operational status check of the tunnel. |
No action is required. |
|
Indicates that the mplsTunnelOperStatus object for a configured MPLS traffic engineering tunnel is about to transition to the up(1) or the down(2) respectively. |
A configured tunnel is transitioning to the down state. May be caused by an administrative or operational status check of the tunnel. |
To see the operational status of the tunnel. |
|
Indicates that the signalling path for an MPLS traffic engineering tunnel changed. |
A tunnel was rerouted or reoptimized. |
If you use the actual path, then write the new path to mplsTunnelRerouted after the notification is issued. |
Routing Protocol Notifications
Table 4-6 lists BGP4-MIB notifications generated by the Cisco 7200 router to indicate error conditions for routing protocols and services.
Table 4-6 Routing Protocol Notifications
|
|
|
|
|
Indicates that the BGP protocol becomes active on the router (it enters the Established state). |
The BGP routing protocol changed status. |
No action is required. |
|
Indicates that the BGP protocol transitions from a higher-level state to a lower-level state. |
The BGP routing protocol changed status. |
|
RTT Monitor Notifications
Table 4-7 lists CISCO-RTTMON-MIB notifications that can occur during round-trip time (RTT) monitoring.
Table 4-7 RTT Monitor Notifications
|
|
|
|
rttMonConnectionChangeNotification
|
Sent when the value of rttMonCtrlOperConnectionLostOccurred changes. |
Occurs when the connection to a target has either failed to be established or was lost and then re-established. |
Check for the connectivity to the target. There could be link problems to the target through different hops. |
rttMonTimeoutNotification
|
A timeout occurred or was cleared. |
An RTT probe occurred and the system sends the notice when the value of rttMonCtrlOperTimeoutOccurred changes. |
Check for the end-to-end connectivity if rttMonCtrlOperTimeoutOccurred if the notification returns true. No action is required if rttMonCtrlOperTimeoutOccurred is false. |
rttMonThresholdNotification
|
Threshold violation occurred. |
An RTT probe occurred or a previous violation has subsided in a subsequent RTT operation. |
Check for the end-to-end connectivity if rttMonCtrlOperOverThresholdOccurred in the notification is true otherwise no action required. |
Environmental Notifications
Table 4-8 lists CISCO-ENVMON-MIB notifications generated for events that might indicate the failure of the Cisco 7200 router or conditions that might affect the router's functionality.
Table 4-8 Environmental Notifications
|
|
|
|
ciscoEnvMonShutdownNotification
|
Indicates a status change or failure. Critical condition. Shutdown imminent. |
A test point nears a critical state and the router is about to shut down (for example, if auto-shutdown is enabled and the chassis core or inlet temperature reaches critical state and remains there for more than 2 minutes). This message indicates that the system has a configuration to shut down a module if its operating temperature exceeds a temperature threshold. This configuration has been bypassed, and a module will still operate in an over-temperature condition. Operating at an over-temperature condition can damage the hardware. |
Do not override the sensor alarms that act on an over-temperature condition. Enter the environment-monitor shutdown temperature command to bring the system back to standard temperature detection. |
ciscoEnvMonRedundantSupplyNotification
|
Sent if the redundant power supply (if available) fails. |
An environmental condition, an over-temperature condition, or inconsistent voltage to the module occurred. Since such a notification is usually generated before the shutdown state is reached, it can convey more data and has a better chance of being sent than does the ciscoEnvMonShutdownNotification. |
Ensure that the system power supplies are optimally redundant. Use power supplies with identical output ratings or reduce system power consumption. |
ciscoEnvMonTemperatureNotification |
The core or inlet temperature is outside its normal range, when ciscoEnvMonState is at the Warning or Critical state. |
During previous reloads, this module experienced a timeout while accessing the temperature sensor. All further access to the temperature sensor will be disabled. This condition indicates a possible problem with the temperature sensor. |
Copy the error message exactly as it appears on the console or in the system log, contact your Cisco technical support representative, and provide the representative with the gathered information. |
|