A trap message processed for analysis purposes pertains to a device that has been discovered and therefore is already in the modeled topology. IP Availability Manager extracts the information from the trap message and updates the appropriate device attributes.

Note:

IP Availability Manager uses trap messages and the results obtained from periodic SNMP polling to diagnose network failures that interrupt network connectivity.

SNMP traps that IP Availability Manager processes for analysis lists the SNMP traps that IP Availability Manager processes for analysis purposes.

Table 1. SNMP traps that IP Availability Manager processes for analysis

Trap type

Trap name

MIB module

Generic traps

coldStart

Standard SNMP (RFC 1215 MIB)

warmStart

linkUp

linkDown

Enterprise-specific traps for Applied Innovation

<Smart Line Card> Down

For example: AI294 Down

AI198CLC-MIB

<Smart Line Card> Up

Enterprise-specific traps for Cisco

cefcModuleStatusChange

CISCO-ENTITY-FRU-CONTROL-MIB

cHsrpStateChange

CISCO-HSRP-MIB

ciscoConfigManEvent

CISCO-CONFIG-MAN-MIB

demandNbrlayer2Change

CISCO-ISDN-MIB

moduleDown

CISCO-STACK-MIB

moduleUp

sysConfigChangeTrap

Enterprise-specific traps for MRV Communications

(Card fault)

NSTACK-MIB

(port fault)

Enterprise-specific traps for Riverstone Networks

rsEnvirBackupControl-ModuleOnline (Card fault)

RIVERSTONE-NOTIFICATIONS-MIB

Upon receiving a coldStart, warmStart, ciscoConfigManEvent, or sysConfigChangeTrap trap for a device already in the modeled topology, IP Availability Manager places the device on the Pending Devices list and generates a SystemRestarted or ConfigChange trap for input to the Service Assurance Manager Adapter Platform (Adapter Platform). During the next pending discovery, IP Availability Manager will send SNMP polls to the device to rediscover the device and its components.