Table Of Contents
Cisco Unified MeetingPlace SNMP
About Cisco Unified MeetingPlace SNMP
Setting Up Contact and Location Information
Setting Up Community Information
About SNMP Traps
Cisco Unified MeetingPlace Exceptions Supported by the SNMP Trap
Cisco Unified MeetingPlace SNMP
This appendix describes the Simple Network Management Protocol (SNMP) traps and Cisco Unified MeetingPlace exceptions supported by the SNMP trap.
•About Cisco Unified MeetingPlace SNMP
•About SNMP Traps
•Cisco Unified MeetingPlace Exceptions Supported by the SNMP Trap
About Cisco Unified MeetingPlace SNMP
The Cisco Unified MeetingPlace SNMP feature lets you monitor Cisco Unified MeetingPlace the same way you manage other devices on the network. By using a Simple Network Management Protocol (SNMP) management tool, and configuring it appropriately, you can obtain network status information and gain access to the system.
The SNMP feature supports all the standard "MIB II" queries and a set of Cisco Unified MeetingPlace MIB traps. The MIB II queries include information such as the Cisco Unified MeetingPlace server name, location, and contact name, plus various statistics regarding the network interface.
Table D-1 describes the conditions that generate Cisco Unified MeetingPlace MIB traps.
Table D-1 Cisco Unified MeetingPlace SNMP
This Alarm
|
Is Generated Whenever
|
T1 status
|
A T1 line goes down
|
Gateway System Integrity Manager (SIM)
|
The Gateway SIM registers an alarm
|
Server startup
|
The server restarts or crashes (cold start)
|
Major hardware alarm
|
A major hardware failure occurs
|
Major software alarm
|
A major software failure occurs
|
Minor hardware alarm
|
A minor hardware failure occurs
|
Minor software alarm
|
A minor software failure occurs
|
Each major and minor hardware and software notification includes an integer alarm code that indicates which software module and server reported the alarm. For hardware alarms, four additional codes identify the device type, the device address, slot number, and port number. The MIB defines these fields.
A MIB file, named lattraps.mib (which is in SNMP version 1 format) contains all the MIB alarms. You must load this MIB file into your monitoring system and configure it to enable the trap messages to display properly. To download lattraps.mib, go to: http://www.cisco.com/pcgi-bin/tablebuild.pl/meetingplace-serv.
For a list of major and minor alarms, go to: http://www.cisco.com/en/US/products/sw/ps5664/ps5669/
products_tech_note09186a0080232316.shtml.
Remember the following information:
•Normally, each alarm instance generates a separate notification. In some cases, however, one specific incident could trigger multiple types of alarms.
•The MeetingPlaceConfs MIB is reserved for future use. It responds to queries but contains no information about conferences on the Cisco Unified MeetingPlace servers.
Setting Up Contact and Location Information
With the Cisco Unified MeetingPlace SNMP option installed, you can see Cisco Unified MeetingPlace servers from any SNMP Management station without supplying special configuration information. To control access to the SNMP module and set up SNMP data exchange, however, you must supply information in the Network Management Information and Network Management Communities topics of the Configure tab.
Network Management Information controls high-level access to the SNMP module and allows Cisco Unified MeetingPlace to exchange SNMP data with the rest of your network. To ensure the SNMP system administrator contacts the right person for any issues related to the Cisco Unified MeetingPlace system, enter data in the System contact and System location fields.
Tip The Cisco Unified MeetingPlace system contact and location can also be set from the SNMP management station.
Step 1 In MeetingTime, select the Configure tab.
Step 2 Select the Network Management Info topic, and configure the following parameters.
Parameter
|
Configure
|
IP "port number"
|
The port on which Cisco Unified MeetingPlace can find incoming SNMP messages. Port 161 is most commonly used.
|
System contact
|
The name of the Cisco Unified MeetingPlace system administrator.
|
System location
|
The physical location of the Cisco Unified MeetingPlace system.
|
Disable SNMP Queries?
|
The ability to turn off all SNMP queries.
|
Setting Up Community Information
Using the Network Management Communities topic in the Configure tab, you can define SNMP communities for controlling access to Cisco Unified MeetingPlace through SNMP. The Network Management Communities topic also shows you the network information available from the SNMP module.
You can configure two types of network management communities:
•Trap community Defines a host to which Cisco Unified MeetingPlace sends standard MIB II traps.
•Non-trap community Controls the type of access that is provided in response to an SNMP message: read-write, read only, or no access.
If a problem exists, contact the administrator of hosting.
Caution The SNMP agent does not accept queries on trap communities. So, for example, to make queries using the public community, do not designate public to be a trap community.
Step 1 In MeetingTime, select the Configure tab.
Step 2 Select the Network Mgmt Info topic.
You will configure the following attributes (described in these steps).
Attribute
|
Configure
|
Name
|
The name of the network management community. Standard "public" and "private" communities are predefined. They are called MeetingPlace-public and MeetingPlace-private. You may use these values or replace them with your own.
|
IP address
|
The IP address to which traps are sent for trap communities. This parameter is ignored for non-trap communities.
|
Read-write?
|
When set to Yes, SNMP messages for this community can modify stored SNMP data. (Ignored for trap communities.) Typically, administrators choose read-only in the public community; private communities are often used for read-write access.
|
Is it a trap?
|
SNMP agents can proactively notify the administrator through a "trap" (for example, "I am restarting"). The SNMP module can activate traps when the system restarts, when a network link changes state, or when an SNMP message that fails authentication is received.
|
Step 3 Delete the private community and rename the public and trap communities, as shown in the following table.
To
|
Do This
|
Delete the private community
|
Click the Query button, then click the < or > button to find the private community. Click Delete, then click Save Changes.
|
Rename the public community
|
Click the Query button, and click the < or > button to find the public community. Type the following name exactly as shown (it is case sensitive):
rwcHP1
Then click Save Changes.
Note This value is the same on all servers; it does not change.
|
Rename the trap community
|
Set the IP address to the current server value. Then click Save Changes.
|
Step 4 Restart the Cisco Unified MeetingPlace 8106 or 8112 for these changes to take effect.
Traps appear on SNMP management tools as events with a trap code. Because most SNMP management tools permit configuration of both the event message and the alarm severity, we recommend that system administrators configure T1 and Gateway SIM traps so that they are easy to spot and understand. For a list of generic codes, see the "About SNMP Traps" section.
For a sample trap configuration, see "Obtaining Technical Assistance" in the Guide to Cisco Conferencing Documentation and Support for assistance.
About SNMP Traps
The following table describes the SNMP traps supported by the Cisco Unified MeetingPlace SNMP service.
Whenever a Cisco Unified MeetingPlace server generates an alarm condition, it categorizes that condition as either hardware of software and major or minor. It then generates the appropriate trap for that alarm. These traps contain additional information, including the actual alarm code, as a payload.
For information on the format of the major and minor hardware and software traps, see the lattraps.mib, located at http://www.cisco.com/pcgi-bin/tablebuild.pl/meetingplace-serv.
These traps are generated in addition to any T1 or GWSIM traps, and the same condition may generate more than one trap as a result.
Note The MeetingPlaceConfs MIB is reserved for future use. It responds to queries but contains no information about conferences on the Cisco Unified MeetingPlace servers.
Table D-2 describes each trap type and its value.
Table D-2 SNMP Traps
Trap Type
|
Trap Value
|
Description
|
coldStart
|
SNMP_TRAP_COLDSTART (0)
OID=1.3.6.1.6.3.1.1.5, trap type 0
|
Generic trap for all devices. Signifies the sending protocol entity is re-initializing itself such that the agent's configuration or the protocol entity implementation may be altered.
Normally encountered when the conference server is restarted.
|
T1
|
OID-1.3.6.1.4.1.7185.3.1.3.0, trap type 1
|
Signifies the sending protocol entity recognizes that some event occurred.
This trap value indicates any Gateway exception (described in "Cisco Unified MeetingPlace Exceptions Supported by the SNMP Trap" section), which are detected from the Cisco Unified MeetingPlace system. When you receive such a trap, check the exception log to see what happened.
|
Major hardware
|
OID=1.3.6.1.4.1.7185.3.1.3.0, trap type 3
|
See lattraps.mib for details
|
Minor hardware
|
OID=1.3.6.1.4.1.7185.3.1.3.0, trap type 4
|
See lattraps.mib for details
|
Major software
|
OID=1.3.6.1.4.1.7185.3.1.3.0, trap type 5
|
See lattraps.mib for details
|
Minor software
|
OID=1.3.6.1.4.1.7185.3.1.3.0, trap type 6
|
See lattraps.mib for details
|
Cisco Unified MeetingPlace Exceptions Supported by the SNMP Trap
The following exceptions are generated from the Cisco Unified MeetingPlace Gateway SIM and received by the SNMP server. The SNMP server then sends the trap to the SNMP client. The exceptions are described in the alternate log file cm_alt.log.
Table D-3 describes each exception code an d its value.
Table D-3 Exceptions Supported by SNMP Trap
Exception Code
|
Numeric Value
|
Event Description
|
EX_SPAN_RED_ALARM
|
EX_TV_BASE+120
(Ex_TV_BASE 0xB000)
|
Red Alarm detected on this T1 span ([%d], card %d, [%d], span %d)
|
EX_MPDATASVC_STATUSNOTRESP
|
EX_GWERR_BASE+258
(EX_GWERR_BASE 0x120000)
|
WebPub Data Service (Unit %d) Not Responding
|
EX_MPAGENT_STATUSNOTRESP
|
EX_GWERR_BASE+322
|
WebPub Agent (Unit %d) Not Responding
|
EX_MPAUDIO_STATUSNOTRESP
|
EX_GWERR_BASE+386
|
WebPub Audio Service (Unit %d) Not Responding
|
EX_SMTP_STATUSNOTRESP
|
EX_GWERR_BASE+514
|
SMTP Gateway (Unit %d) Not Responding
|
EX_OUTLOOK_STATUSNOTRESP
|
EX_GWERR_BASE+1026
|
Outlook Gateway (Unit %d) Not Responding
|
EX_NOTES_STATUSNOTRESP
|
EX_GWERR_BASE+1282
|
Notes Gateway (Unit %d) Not Responding
|
EX_MPNOTIFY_STATUSNOTRESP
|
EX_GWERR_BASE+1346
|
MPNotify Service (Unit %d) Not Responding
|
EX_DATACONF_STATUSNOTRESP
|
EX_GWERR_BASE+1538
|
DataConf Gateway (Unit %d) Not Responding
|
EX_DATACONFGCC_STATUSNOTRESP
|
EX_GWERR_BASE+1602
|
DataConf GCC Service (Unit %d) Not Responding
|
EX_DATACONFMCS_STATUSNOTRESP
|
EX_GWERR_BASE+1666
|
DataConf MCS Service (Unit %d) Not Responding
|
EX_DATACONFSAMETIME_STATUSNOTRESP
|
EX_GWERR_BASE+1730
|
DataConf Sametime Service (Unit %d) Not Responding
|
EX_VOIPMPSTREAM_STATUSNOTRESP
|
EX_GWERR_BASE+1858
|
VoIP MPStream Service (Unit %d) Not Responding
|
EX_DCDIR_STATUSNOTRESP
|
EX_GWERR_BASE+2050
|
MP Directory Service (Unit %d) Not Responding
|
EX_GWSIMAGENT_STATUSNOTRESP
|
EX_GWERR_BASE+3842
|
Gateway SIM Agent (Unit %d) Not Responding
|
EX_UNITFAULT
|
EX_SI_BASE+129
|
Communication lost with unit %d
An active unit was down
|
EX_CRASH
|
EX_SI_BASE+73
|
System crashed: power fail, reset, or watchdog timer
(This is not a Gateway SIM-related exception. It occurs when the server crashes, reboots, then realizes it has crashed.)
|