Simple Network Management Protocol (SNMP) governs the management and monitoring of network devices and their functions. The SNMP agent communicates with SNMP-compatible Network Management Stations and supports industry-standard MIB-II definitions as well as proprietary SNMP extensions designed to maximize the manageability and configurability of the 3300 ICP.
Note: When the system is rebooted, the SNMP Agent sends a coldStart standard trap to the SNMP Managers when the system is ready.
SNMP defines asynchronous messages called "traps". SNMP traps are generated to alert the administrator when significant network or server events, such as alarms triggered or cleared, take place.
Traps are sent by an SNMP agent to an SNMP manager usually to report error conditions but other types of messages can also be transmitted.
Mitel resiliency SNMP traps provide the information about the status of sets during the failure of the 3300 primary ICP. These traps are independent of the 3300 ICP Alarm system, and 3300 ICP alarms on the primary or secondary ICP are not generated specifically under these resilient conditions.
The System Name is included in all Mitel proprietary SNMP traps to enable the identification of multiple systems behind single address NAT.
The SNMP agent queries the number of IP user licenses being used. These values are obtained from the System Capacity form.
The resiliency SNMP traps include the Cluster Element Index of the primary ICP. An ICP can be a secondary ICP to many primary ICPs. Using this trap information, the system administrators can detect which primary ICP has failed.
The Network Element Name is unique across the network. The Network Element Name of the primary ICP is included in the SNMP resiliency traps to provide unique identification for SNMP Managers to identify the resilient events.
The detected time of the trap indicates the timestamp on the secondary ICP when it detects a resiliency event. This may be different from the SNMP Manager's timestamp due to a delay in processing or different time zones.
The following traps are provided:
Accepting set registration from another 3300 (mitelIpera3000NotifResiltFirstSetFailover)
When a primary 3300 ICP fails, all the sets re-register with their secondary ICPs. When the first set on the failed 3300 ICP registers at the secondary ICP, an SNMP trap will to be sent by the secondary ICP. This trap is sent from the secondary ICP for each primary ICP that has set failure.
Sets being re-diverted to originating 3300 (mitelIpera3000NotifResiltHealthCheckComplete)
When the system detects that the primary ICP is active and is able to accept set registrations after a failure, the secondary ICP sends this trap for each primary ICP that becomes active.
Re-diversion completed (mitelIpera3000NotifResiltHandoffComplete)
When the last failover set has been re-directed back to its primary ICP, the secondary ICP generates this SNMP trap.
The 3300 ICP supports the following SNMP traps:
|
Trap |
Indication |
Definition |
|
coldStart |
Cold Start |
This standard MIB-II trap is sent when the sending protocol entity reinitializes itself in a way that the agent's configuration or the protocol entity implementation may be changed. |
|
almMinor |
Minor Alarm |
This proprietary Mitel trap is sent when a minor alarm is raised, or when the status of an alarm changes to minor, as determined by the alarm thresholds. |
|
almMajor |
Major Alarm |
This proprietary Mitel trap is sent when a major alarm is raised, or when the status of an alarm changes to major, as determined by the alarm thresholds. |
|
almCritical |
Critical Alarm |
This proprietary Mitel trap is sent when a critical alarm is raised, or when the status of an alarm changes to critical, as determined by the alarm thresholds. |
|
almClear |
Alarm Cleared |
This proprietary Mitel trap is sent when all the alarms in the system are cleared. |
|
mitelIpera3000NotifResiltFirstSetFailover |
Primary 3300 ICP fails |
This proprietary Mitel trap is sent after a primary 3300 ICP fails and the first set has registered with the secondary ICP. |
|
mitelIpera3000NotifResiltHealthCheckComplete |
Primary 3300 ICP recovers |
This proprietary Mitel trap is sent when the primary ICP has recovered. |
|
mitelIpera3000NotifResiltHandoffComplete |
All sets re-directed back to primary 3300 ICP |
This proprietary Mitel trap is sent when all sets from the primary ICP that failed have re-directed back to the primary ICP from the secondary ICP. |
Certain MIBs require the Layer 2 switch IP address to be configured and the controller rebooted before they will work on a CXi, CXi II or MXe.
Values of type Counter64 can only be retrieved with the SNMP management system in V2 mode.
The SNMP agent supports GET-BULK PDUs in V2 mode. If the management system can be configured to use GET-BULK instead of GET it should be as this will result in less network traffic and quicker data retrieval.
Some
of the objects will never change
Writing to the standard MIB objects (RFCs) using SET is not supported and the agent will reply with the error status readOnly.
Some generic MIB browsers present MIB objects which do not have any ACCESS or MAX-ACCESS clause (such as group identifiers, trap OIDs, etc.). Both HP Openview and Adventnet (Mitel Enterprise Manager) fall into this category. An attempt to retrieve data from these objects, or to walk the tree below a node containing only these kinds of objects will fail (the agent will respond noSuchName/noSuchInstance).
When the end of MIB view is encountered the agent will return endOfMib as an error status. Often generic MIB browsers will not handle this correctly or will not display it in a nice fashion. mitelBCMChipType is currently the last OID in the MIB view. If a MIB walk traverses this OID in adventnet browser (EMgr) it will report an error. This can be misleading, allowing the user to form a conclusion that a problem exists where there is none.
If the user generates a request that could take a long time to satisfy (for example a GET-BULK request with a large number of OIDs and/or repeaters), the user must also increase the timeout to allow the 3300 ICP enough time to formulate the response.
Attempts to retrieve data about interfaces (especially Layer 2 switched interfaces) early in the system startup sequence may return noSuchName or noSuchInstance while the hardware is starting up and the tables are being populated. This is normal. Ideally, one should wait for the RFC1215 restart trap before trying to retrieve data from the 3300 ICP.
When loading MIB files, MIB dependencies may be an issue. Generic MIB browsers vary in their strictness with respect to dependencies. HP Openview, for example, can load all the MIBs currently supported; the only dependency is RFC1213. Adventnet, by comparison, has complex dependencies; however, if the right-click menu of a 3300 ICP icon (or the action menu item) Browse MIBs is used, the MIBs are all loaded in the correct order and the MIB browser will remember the dependencies in the future).
Program the SNMP Configuration form.
Program the SNMP Trap Forwarding form.
None.