よくあるご質問
CISCO-CCM-MIB について、Cisco Unified Communication Manager ノードから SNMP トラップが取得されないのはなぜですか。
CISCO-CCM-MIB の SNMP トラップを受信するには、次の MIB OID の値が適切な値に設定されていることを確認する必要があります。ccmPhoneFailedAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.2)および ccmPhoneStatusUpdateAlarmInterv(1.3.6.1.4.1.9.9.156.1.9.4)は、30 ~ 3600 に設定します。デフォルトでは、ゼロ(0)に指定されています。
Linux マシンから次のコマンドを実行します。
• snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.156.1.9.2.0 i < 値 >
• snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.156.1.9.4.0 i < 値 >
次の問題は、電話機の登録/登録解除/障害に関連しています。
• 通知の宛先の設定:通知の宛先が設定されていることを確認する必要があります。確認は Cisco Unified Serviceability Web ウィンドウから実行できます。[SNMP] > [Notification Destinations] というメニューがあります。
通知の宛先を設定する前に、必要な SNMP サービスがアクティブであり、実行されていることを確認します(SNMP Master Agent および Cisco UCM SNMP Service)。また、コミュニティ ストリング/ユーザの特権を正しく設定してあることを確認します。通知の権限も含まれている必要があります。
トラップがまだ生成されない場合は、対応するアラームが生成されるかどうかを確認します。これらのトラップはアラーム イベントに基づいて生成されるため、SNMP エージェントがこれらのアラーム イベントを取得していることを確認します。ローカル Syslog をイネーブルにします。Cisco UCM Serviceability のウィンドウ [Alarm] > [Configuration] で利用できるアラーム設定から、ローカル Syslog の宛先について Cisco UCM のアラーム設定を情報レベルに設定します。トラップを再現し、対応するアラームが CiscoSyslog ファイルにロギングされるかどうかを確認します。
• トラップとしての syslog メッセージの受信:特定の重大度を超える syslog メッセージをトラップとして受信するには、clogBasic テーブルで次の 2 つの MIB オブジェクトを設定します。
– clogNotificationsEnabled(1.3.6.1.4.1.9.9.41.1.1.2):syslog トラップ通知をイネーブルにするには、これを true ( 1 )に設定します。デフォルト値は false ( 2 )です。たとえば、 snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.41.1.1.2.0 i < 値 > とします。
– clogMaxSeverity(1.3.6.1.4.1.9.9.41.1.1.3):どの重大度を超えるとトラップが必要となるかを設定します。デフォルト値は warning ( 5 )です。通知がイネーブルの場合、設定した重大度以下のアラーム重大度の syslog メッセージはすべてトラップとして送信されます。たとえば、 snmpset -c < コミュニティ ストリング > -v 2c < トランスミッタ IP アドレス > 1.3.6.1.4.1.9.9.41.1.1.3.0 i < 値 > とします。
Cisco Unified Communication Manager に対して定義されているさまざまなトラップは何ですか。
CISCO-CCM-MIB には、次の定義済みトラップのリストが含まれています。
• ccmCallManagerFailed:Cisco UCM プロセスが重要なサブシステムの 1 つで障害を検出することを示します。ハートビート/イベント モニタリング プロセスから検出することもできます。
• ccmPhoneFailed:ccmPhoneFailedAlarmInterval で指定された間隔によって ccmPhoneFailedTable 内の少なくとも 1 つのエントリが示されることを通知します。
• ccmPhoneStatusUpdate:ccmPhoneStatusUpdateTable 内に 1 つのエントリが存在する場合に ccmPhoneStatusUpdateInterv で指定された間隔で生成される通知です。
• ccmGatewayFailed:少なくとも 1 つのゲートウェイが Cisco UCM への登録および通信を試行して失敗したことを示します。
• ccmMediaResourceListExhausted:Cisco UCM が指定されたタイプのリソースを使い果たしたことを示します。
• ccmRouteListExhausted:指定されたルート リスト内で Cisco UCM が使用可能なルートを見つけることができなかったことを示します。
• ccmGatewayLayer2Change:Skinny ゲートウェイの登録済みインターフェイスの D チャネル/レイヤ 2 で状態が変更されることを示します。
• ccmMaliciousCall:ユーザがコールを悪質としてローカル Cisco UCM サーバに登録することを示します。
• ccmQualityReport:ユーザが Quality Report Tool を使用して品質の問題を報告することを示します。
• ccmTLSConnectionFailure:Cisco Unified Communications Manager が指定されたデバイスの TLS 接続のオープンに失敗したことを示します。
トラップのアラームへのマッピングは、次のとおりです。
• ccmCallManagerFailed:CallManagerFailure
• ccmPhoneFailed:DeviceTransientConnection
• ccmPhoneStatusUpdate
• ccmGatewayFailed:DeviceTransientConnection
• ccmMaliciousCall:MaliciousCall
• ccmMediaResourceListExhausted:MediaResourceListExhausted
• ccmQualityReportRequest:QRTRequest
• ccmRouteListExhausted:RouteListExhausted
• ccmGatewayLayer2Change:DChannelOOS、
Cisco Unified Communication Manager からのさまざまな SNMP トラップはどのように確認できますか。
少数のトラップを起動する次の手順を実行します。
• ccmPhoneStatusUpdate トラップ
– ccmAlarmConfigInfo MIB テーブルで、ccmPhoneStatusUpdateAlarmInterv(1.3.6.1.4.1.9.9.156.1.9.4)を 30 以上に設定します。
– 電話機が登録されている Cisco Unified Communications Manager サーバを接続解除します。電話機が登録解除されます。
– Cisco Unified Communications Manager サーバを再接続します。電話機が再登録され、ccmPhoneStatusUpdate トラップが取得されます。
• ccmPhoneFailed トラップ
– ccmAlarmConfigInfo MIB テーブルで、ccmPhoneFailedAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.2)を 30 以上に設定します。
– 電話機を障害状態にします。電話機を Cisco Unified Communications Manager から削除し、再登録します。電話機の障害のトラップの場合、次の 2 つの異なるシナリオを試行できます。
tftp/Cisco Unified Communications Manager サーバ A を指すように電話機を設定します。異なるスイッチで Cisco Unified Communications Manager サーバ B に電話機を接続します。電話機ステータスは不明のままです。次のメッセージが表示されます。
2007-10-31:2007-10-31 14:53:40 Local7.Debug 172.19.240.221 community=public, enterprise=1.3.6.1.4.1.9.9.156.2.0.2, enterprise_mib_name=ccmPhoneFailed, uptime=7988879, agent_ip=128.107.143.68, version=Ver2, ccmAlarmSeverity=error, ccmPhoneFailures=1.
Cisco UCM で 7960 電話機を 7940 電話機として登録し、電話機障害トラップを生成する db 問題を発生させます。
• MediaResourceListExhausted トラップ
– Media Resource Group(MRG; メディア リソース グループ)を作成し、標準の ConferenceBridge リソース(CFB-2)のいずれかが含まれるようにします。
– Media Resource Group List(MRGL; メディア リソース グループ リスト)を作成し、作成した MRG が含まれるようにします。
– 実際の電話機の [電話の設定(Phone Configuration)] ウィンドウで、MRGL を電話機の [メディア リソース グループ リスト(Media Resource Group List)] として設定します。
– IPVMS を停止します。これにより、ConferenceBridge リソース(CFB-2)は機能を停止します。
– メディア リストを使用して電話機で電話会議を行います。電話機の画面に「使用可能な会議ブリッジがありません(No Conference Bridge available)」が表示されます。
– MediaListExhausted アラーム/アラート/トラップが生成されるかどうかを確認します。
• RouteListExhausted トラップ
– Route Group(RG; ルート グループ)を作成し、ゲートウェイが 1 つ含まれるようにします。
– Route Group List(RGL; ルート グループ リスト)を作成し、作成した RG が含まれるようにします。
– 9XXXX コールを RGL によって再ルーティングするルート パターン(9.XXXX)を作成します。
– ゲートウェイを登録解除します。
– 電話機の 1 つで 9XXXX をダイヤルします。
– RouteListExhausted アラーム/アラート/トラップが生成されるかどうかを確認します。
• MaliciousCallFailed トラップ
– ソフトキー テンプレートを作成します。テンプレートで、使用可能なすべての [迷惑呼(MaliciousCall)] ソフトキーを電話機ステータスに追加します。
– この新しいソフトキー テンプレートを実際の電話機に割り当てます。電話機をリセットします。
– 電話をかけ、コール中およびコール後に電話機の画面で MaliciousCall を選択します。
– MaliciousCallFailed アラーム/アラート/トラップが生成されるかどうかを確認します。
• GatewayFailed トラップ
– 方法 1:Web Admin を使用してデータベースからゲートウェイ設定を削除するか、ゲートウェイ MAC アドレスを無効な値に変更して更新します。ゲートウェイをリブートします。または、ゲートウェイが接続されている Cisco UCM サービスを再起動します。
– 方法 2:ccmAlarmConfigInfo MIB テーブルで、GatewayAlarmEnable=true を設定します。Cisco Unified Serviceability で、SNMP の設定ウィンドウに移動し、SNMP コミュニティ ストリングおよびトラップの宛先が正しく設定されていることを確認します。ゲートウェイ障害イベントを作成すると、トラップ受信側にトラップが表示されます。ゲートウェイ障害およびフェールオーバーを発生させるには、Cisco UCM を再起動します。ゲートウェイが冗長 Cisco UCM サーバにフェールオーバーします。冗長 Cisco UCM サーバのデータベース内にゲートウェイを設定しないでください。
• ccmGatewayLayer2Change トラップ
– ccmGatewayLayer2Change トラップは、Cisco UCM からの D-Channel Out Of Service(DChannelOOS)または D-Channel Inservice(DChannelISV)中に起動されます。テスト目的で、そのようなイベントが起動されるかどうかを確認します。
• ccmCallManagerFailed トラップ
– Cisco UCM 障害アラームは、内部エラーの発生時に生成されます。これらのアラームには、CPU 不足、タイマーの問題などによる内部スレッド停止が含まれます。これは、Cisco UCM チームがこれらのいずれかを意図的に発生させないかぎり再現が難しいトラップです。
Cisco UCM Agent の高い CPU 消費が継続する場合、何を行う必要がありますか。
分析用のログを収集し、障害 CSCsm74316 を参照します。使用している Cisco UCM リリースに障害の修正が追加されているかどうかを確認します。
CTI Routepoint が Cisco Unified CM の管理から削除された場合、ccmCTIDeviceTable mib 内に対応するエントリがあります。なぜですか。
「RIS Unused Cisco CallManager Device Store Period」というサービス パラメータによって、未登録デバイスが RIS データベースおよび MIB 内に残される時間が定義されています。[Cisco UCM の管理(Cisco UCM Administration)] ウィンドウと SNMP MIB は同期していない場合があります。[Cisco UCM の管理(Cisco UCM Administration)] ウィンドウにはデータベースからの情報が表示され、SNMP では RIS データベースが使用されるためです。
ccmPhoneType を Cisco-CCM-MIB 内の ccmPhoneTable から照会すると、情報が返されません。なぜですか。
これは、ccmPhoneType が古いことを意味します。CcmProductTypeEntry に対する ccmPhoneProductTypeIndex から、同じ情報を取得できます。テーブルでは、インデックスはそのテーブルにリストされているインデックスおよび名前に対応しています。
次のリストに、その他の古い OID の一部と、参照する必要がある代替 OID を示します。
• ccmGatewayType は古いため、ccmGateWayProductTypeIndex を参照する必要があります。
• ccmMediaDeviceType は古いため、ccmMediaDeviceProductTypeIndex を参照する必要があります。
• ccmCTIDeviceType は古いため、ccmCTIDeviceProductTypeIndex を参照する必要があります。
ccmPhoneProductTypeIndex の照会でゼロが返されます。なぜですか。
使用している Cisco Unified Communications Manager リリースにこの機能があることを確認します。
WALK が ccmPhoneTable に対して実行されていますが、ccmPhoneUserName によって値が返されません。ユーザ名は IP Phone にどのように関連付けられていますか。
エンド ユーザを作成し、登録済みの電話機に移動して、オーナーのユーザ ID を関連付けます。これを実行したあとに、SNMP Walk 内の OID によってユーザが表示されます。
SNMP を使用して各電話機のファームウェア バージョンを取得するにはどうすればいいですか。
ccmPhoneTable 内の ccmPhoneLoadID オブジェクトによって、各電話機のファームウェア バージョンが示されます。新しいイメージ ダウンロードが失敗した場合にはこの値が異なることがあります。SNMP では、設定済みのファームウェア ID(ccmPhoneLoadID)と実際に実行されているファームウェア(ccmPhoneActiveLoad)の両方が示されるためです。
CCM MIB によって ccmVersion が 5.0.1 として返されますが、これは間違いです。
使用している Cisco Unified Communications Manager リリースにこの機能があることを確認します。機能がない場合は、アップグレードします。
CCM MIB によって正しくない ccmPhoneLoadID が返されます。
ccmPhoneLoadID の値は RIS データベースから取得されます。このデータベースには、電話機の登録中に受信されたアラームに基づいて情報が入力されます。次の手順を実行し、詳細な分析用のログを収集します。
ステップ 1 Cisco Unified Serviceability で、[Alarm] > [Configuration] を選択します。サーバを選択します。次に、[Go] をクリックします。サービス グループの [CM Services] を選択します。次に、[Go] をクリックします。サービスの [Cisco CallManager] を選択します。次に、[Go] をクリックします。
ステップ 2 [Local Syslog]、[SDI Trace]、および [SDL Trace] の [Enable Alarm] をオンにします。それぞれの [Alarm Event Level] ドロップダウン リスト ボックスから [Informational] を選択します。
ステップ 3 [Trace Configuration] ウィンドウで、Cisco UCM サービスの [Debug Trace Level] を [Detailed] に設定します。
ステップ 4 正しくない LoadID が表示されている電話機をリセットします。
ステップ 5 Syslog および Cisco UCM トレースを収集します。
ステップ 6 電話機の詳細を収集します。
Cisco Call Manager のステータス(START/STOP)はどのように監視されますか。
サービス監視には次のオプションがあります。
• SYSAPPL MIB
• HOST-RESOURCE-MIB
• CISCO-CCM-MIB(ccmStatus)
• SOAP インターフェイス
• Real-TimeMonitoringTool(RTMT)アラート
Cisco UCM サービス障害用に ccmCallManagerFailed トラップがあります。ただし、通常のサービス停止および不明なクラッシュはその対象ではありません。
ポーリングされたデバイスのデバイス プール情報が正しくないように見えます。なぜですか。使用された OID は ccmPhoneDevicePoolIndex です。
CISCO-CCM-CAPABILITY MIB に記述されているように、ccmPhoneDevicePoolIndex はサポートされていないためゼロ(0)が返されます。Cisco UCM デバイス登録アラームには、現在はデバイス プール情報は含まれていません。