Cisco MCS-7825-H3-IPC1, Руководство по обслуживанию

Страница: 758 / 974

7-116
Cisco Unified Communications Manager Managed Services Guide
OL-22523-01
Chapter 7 Cisco Management Information Base
CISCO-CCM-MIB
•
Workaround:
– Use the available scalar variables (1.3.6.1.4.1.9.9.156.1.5) to determine the table size before
accessing the table. Or do the get operation on the desired table first and then query the non
empty tables.
–
Reduce the number of variables queried in a single request. For example, for empty tables. if
Management application has timeout set at 3 sec, then recommendations is to specify no more
than 1 OID. For non-empty tables it takes 1 second to retrieve 1 row of data.
– Increase the response timeout.
–
Reduce the number of retries.
– Avoid using getbulk SNMP API. Getbulk API gets number of records specified by
MaxRepetitions. This means even if the next object goes outside the table or MIB, it gets those
objects. So if the CISCO-CCM -MIB has empty tables then it goes to next MIB and so will more
time to respond. Use getbulk API when it is known that the table is not empty, and also know
the number of records. Under this condition limit the max repetition counts to 5 to get response
within 5 sec.
–
Structured SNMP queries to adapt to current limits.
– Avoid doing a number of getbulks on the PhoneTable in case there are a number of phones
registered to the Cisco Unified CM, walking it periodically may not be optimal. In such a
scenario whenever there is an update, ccmPhoneStatusUpdateTable will be updated, use this
information to decide whether to walk the PhoneTable.
Frequently Asked Questions
Not getting any SNMP traps from the Cisco Unified Communication Manager node for the CISCO-CCM-MIB.
For receiving SNMP traps in CISCO-CCM-MIB, you need to ensure that the value of the following MIB
OIDs are set to appropriate values:
ccmPhoneFailedAlarmInterval (1.3.6.1.4.1.9.9.156.1.9.2) and
ccmPhoneStatusUpdateAlarmInterv (1.3.6.1.4.1.9.9.156.1.9.4) are set between 30 and 3600. The
default is set to 0.
Execute the following commands from any Linux machine:
•
snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.156.1.9.2.0 i
< value >
• snmpset -c < Community String > -v 2c < transmitter ip address > 1.3.6.1.4.1.9.9.156.1.9.4.0 i
< value >
These are related to registration/deregistration/failure of phones.
You need to ensure that notification destinations are configured. This can be done from the Serviceability
Web window. There is a menu for SNMP > Notification destination.
Before you configure notification destination, verify that the required SNMP services are activated and
running (SNMP Master Agent and Cisco CallManager SNMP Services). Also, make sure that you
configured the privileges for the community string/user correctly which should contain Notify
permissions as well.
If still Traps are not generated check if corresponding alarms are generated. Since these traps are
generated based on the alarm events, ensure that SNMP agents are getting these alarm events. Enable
'Local Syslog', setup the Cisco Unified CM Alarm configuration to 'Informational' level for 'Local