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.)