Cisco Unified Communications Manager マネー ジド サービス ガイド リリース 8.5(1)
簡易ネットワーク管理プロトコル
簡易ネットワーク管理プロトコル
発行日;2012/02/06 | 英語版ドキュメント(2010/12/08 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

簡易ネットワーク管理プロトコル

概要

SNMP のバージョン

SNMP および Cisco Unified CM の基本

SNMP の基本コマンド

SNMP のコミュニティ ストリングとユーザ

SNMP と Cisco MIB

SNMP のトラップとインフォーム

SNMP トレースの設定

SNMP に関するヒント

SNMP のトラブルシューティング

SNMP/R MIB

簡易ネットワーク管理プロトコル

この章では、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)の概要について説明します。内容は、次のとおりです。

「概要」

「SNMP のバージョン」

「SNMP および Cisco Unified CM の基本」

「SNMP の基本コマンド」

「SNMP のコミュニティ ストリングとユーザ」

「SNMP と Cisco MIB」

「SNMP のトラップとインフォーム」

「SNMP トレースの設定」

「SNMP に関するヒント」

「SNMP のトラブルシューティング」

概要

アプリケーション レイヤ プロトコルである簡易ネットワーク管理プロトコル(SNMP)を使用すると、ノードやルータなどのネットワーク デバイス間の管理情報を簡単に交換できます。SNMP は、TCP/IP スイートの一部を構成しています。システム管理者は、SNMP を使用して、ネットワーク パフォーマンスのリモート管理、ネットワークの問題の検出および解決、ネットワーク拡張の計画を行うことができます。

SNMP では、多数のコマンドを定義する代わりに、get-request、get-next-request、get-bulk-request、および set-request の形式ですべての操作を行います。たとえば、SNMP マネージャでは、SNMP エージェントから値を取得したり、その SNMP エージェントに値を格納したりできます。SNMP マネージャは Network Management System(NMS; ネットワーク管理システム)の構成要素になることができ、SNMP エージェントはルータなどのネットワーク デバイスに常駐できます。

SNMP は、SNMP マネージャ、SNMP エージェント、MIB という 3 つの部分から構成されています。Cisco MIB は、ネットワーク管理ソフトウェアを使用してコンパイルできます。

NMS では、Cisco MIB 変数を使用してデバイス変数を設定し、インターネットワーク上のデバイスのポーリングを行って特定の情報を取得します。ポーリングの結果はグラフの作成や分析に使用でき、インターネットワークの問題のトラブルシューティング、ネットワーク パフォーマンスの向上、デバイスの設定の確認、およびトラフィックの負荷のモニタに役立ちます。

SNMP エージェントは、デバイス パラメータおよびネットワーク データに関する情報のリポジトリである MIB からデータを収集します。また、SNMP エージェントは、特定のイベントのトラップ(通知)を SNMP マネージャに送信することもできます。Cisco トラップ ファイル「mib.traps」は、シスコのホスト //ftp.cisco.com から入手できます。このファイルに、Cisco トラップの形式が記載されています。

SNMP マネージャは MIB の情報を使用し、次の説明に従ってオペレーションを実行します。

 

オペレーション
説明

get-request

特定の変数から値を取得します。

get-next-request

名前付き変数の次の値を取得します。通常、テーブル内から変数を取得する場合に使用します。このオペレーションでは、SNMP マネージャが正確な変数名を知っている必要はありません。MIB 内から必要な変数を見つけるために、順次検索が実行されます。

get-response

NMS から送信された get-request、get-next-request、get-bulk-request、および set-request に応答します。

get-bulk-request

get-next-request と同様に、get-response に get-next インタラクションを最大繰り返し数まで格納します。

set-request

特定の変数に値を格納します。

traps

何らかのイベントが発生したことを伝えるために、SNMP エージェントから SNMP マネージャに送信されます。

SNMP のバージョン

SNMP のバージョンには、バージョン 1(SNMPv1)、バージョン 2(SNMPv2)、およびバージョン 3(SNMPv3)の 3 つがあります。SNMPv1 は、Structure of Management Information(SMI; 管理情報構造)の仕様の範囲内で機能する SNMP の初期実装で、User Datagram Protocol(UDP; ユーザ データグラム プロトコル)や IP などのプロトコルを介して動作します。

SNMPv1 SMI では、高度な構造を持つ MIB テーブルが定義されます。このテーブルは、複数の変数を含むオブジェクトのグループ化に使用されます。テーブルにはインデックスが付けられた 0 個以上の行が格納されるため、SNMP では、サポートされているコマンドを使用して、行全体を取得したり変更したりできます。

SNMPv1 では、NMS が要求を発行し、管理対象デバイスから応答が返されます。エージェントは、トラップ オペレーションを使用して、NMS に重要なイベントを非同期的に通知します。

SNMPv2c は、SNMPv1 と同様に、SMI の仕様の範囲内で機能します。MIB モジュールには、相互に関係のある管理対象オブジェクトの定義が格納されます。SNMPv1 で使用されるオペレーションと SNMPv2 で使用されるオペレーションは、ほぼ同じであることに注意してください。たとえば、SNMPv2 トラップ オペレーションは、SNMPv1 で使用する機能と同じですが、異なるメッセージ形式を使用する、SNMPv1 トラップに代わる機能です。

SNMPv2c の通知オペレーションでは、ある NMS から別の NMS にトラップ情報を送信して、その NMS から応答を受信することができます。

SNMPv3 は、次のセキュリティ機能を備えています。

認証:要求が正規の送信元から送信されたものかどうかを確認します。

プライバシー:データの暗号化を行います。

認可:要求された操作がユーザに許可されているかどうかを確認します。

アクセス コントロール:要求されたオブジェクトにユーザがアクセスできるかどうかを確認します。

SNMPv3 は、パケットがネットワーク上に公開されるのを防ぎます。SNMPv3 では、SNMPv1 や SNMPv2 のようにコミュニティ ストリングを使用するのではなく、「SNMP のコミュニティ ストリングとユーザ」で説明するように、SNMP ユーザを使用します。

SNMP および Cisco Unified CM の基本

SNMP を使用するネットワークでは、管理対象デバイス、エージェント、Network Management Software(NMS; ネットワーク管理ソフトウェア)という 3 つの主要コンポーネントが必要です。

管理対象デバイス:SNMP エージェントを含む、ネットワーク上に常駐するデバイス。管理対象デバイスは、情報の収集と格納を行います。格納された情報は、SNMP を使用して取得できます。

Cisco Unified CM クラスタの最初のノードは、管理対象デバイスとして機能します。Cisco Unified CMBE では、Cisco Unified CM がインストールされたサーバが管理対象デバイスとして機能します。

エージェント:管理情報のローカル情報を格納し、その情報を SNMP と互換性がある形式に変換するソフトウェア モジュール。

Cisco Unified CM では、マスター エージェントとサブエージェントの各コンポーネントを使用して SNMP をサポートします。マスター エージェントはエージェント プロトコル エンジンとして機能し、SNMP 要求に関連する認証、認可、アクセス コントロール、およびプライバシーの機能を実行します。マスター エージェントには、管理情報ベース(MIB)変数がいくつか格納されます。また、マスター エージェントは、サブエージェントへの接続も行います。サブエージェントでの必要なタスクが完了すると、その接続を解除します。

Cisco Unified CM は、サブエージェントを使用して、ローカルの Cisco Unified CM のみと対話します。Cisco Unified CM サブエージェントは SNMP マスター エージェントにトラップと情報メッセージを送信し、SNMP マスター エージェントは SNMP トラップ レシーバ(通知の宛先)と通信します。

NMS:PC 上で実行する SNMP 管理アプリケーション。ネットワーク管理に必要な処理リソースとメモリ リソースのほとんどを提供します。また、管理対象デバイスのモニタと制御を行うアプリケーションを実行します。Cisco Unified Communications Manager は、次の NMS と連携して動作します。

CiscoWorks2000

HP OpenView

SNMP および Cisco Unified Communications Manager SNMP インターフェイスをサポートしているサードパーティ製アプリケーション

SNMP の基本コマンド

管理対象デバイスのモニタと制御は、4 つの基本的な SNMP コマンド(読み取り、書き込み、トラップ、およびトラバース オペレーション)を使用して行います。

NMS では、読み取りコマンドを使用して管理対象デバイスをモニタします。NMS は、管理対象デバイスで保持されている複数の変数を検査します。

NMS では、書き込みコマンドを使用して管理対象デバイスを制御します。NMS は、管理対象デバイス内に格納されている変数の値を変更します。

管理対象デバイスでは、トラップ コマンドを使用して、非同期的にイベントを NMS に報告します。特定の種類のイベントが発生すると、管理対象デバイスは NMS にトラップを送信します。

NMS では、トラバース オペレーションを使用して、管理対象デバイスがサポートしている変数を確認し、ルーティング テーブルなどの変数テーブルの情報を順次収集します。

SNMP のコミュニティ ストリングとユーザ

SNMP コミュニティ ストリングでは、セキュリティは確保されませんが、MIB オブジェクトへのアクセスを認証し、組み込みパスワードとして機能します。SNMP コミュニティ ストリングは、SNMPv1 または SNMPv2c の場合にのみ設定します。

SNMPv3 では、コミュニティ ストリングを使用しません。SNMPv3 では、SNMP ユーザを使用します。SNMP ユーザを使用する目的はコミュニティ ストリングと同じですが、暗号化や認証が設定されるため、セキュリティが確保されます。

デフォルトのコミュニティ ストリングやユーザは存在しません。

SNMP と Cisco MIB

SNMP を使用すると、Cisco MIB 変数にアクセスでき、ネットワーク デバイス間の管理情報を簡単に交換できます。SNMP システムは、SNMP マネージャ、SNMP エージェント、MIB という 3 つの部分で構成されています。

SNMP では、多数のコマンドを定義する代わりに、get-request、get-next-request、get-bulk-request、および set-request の形式ですべての操作を行います。たとえば、SNMP マネージャでは、SNMP エージェントから値を取得したり、その SNMP エージェントに値を格納したりできます。SNMP マネージャは Network Management System(NMS; ネットワーク管理システム)の構成要素になることができ、SNMP エージェントはルータなどのネットワーク デバイスに常駐できます。Cisco MIB は、ネットワーク管理ソフトウェアを使用してコンパイルできます。SNMP をルータに設定すると、SNMP エージェントで NMS から送信される MIB 関連のクエリーに応答できます。

NMS では、Cisco MIB 変数を使用してデバイス変数を設定し、インターネットワーク上のデバイスのポーリングを行って特定の情報を取得します。ポーリングの結果はグラフの作成や分析に使用でき、インターネットワークの問題のトラブルシューティング、ネットワーク パフォーマンスの向上、デバイスの設定の確認、トラフィックの負荷のモニタなどに役立ちます。

SNMP エージェントは、デバイス パラメータおよびネットワーク データに関する情報のリポジトリである MIB からデータを収集します。また、SNMP エージェントは、特定のイベントのトラップ(通知)を SNMP マネージャに送信することもできます。Cisco トラップ ファイル「mib.traps」は、シスコのホスト //ftp.cisco.com から入手できます。このファイルに、Cisco トラップの形式が記載されています。

SNMP マネージャは MIB の情報を使用し、次の説明に従ってオペレーションを実行します。

 

オペレーション
説明

get-request

特定の変数から値を取得します。

get-next-request

名前付き変数の次の値を取得します。通常、テーブル内から変数を取得する場合に使用します。このオペレーションでは、SNMP マネージャが正確な変数名を知っている必要はありません。MIB 内から必要な変数を見つけるために、順次検索が実行されます。

get-response

NMS から送信された get-request、get-next-request、get-bulk-request、および set-request に対する応答。

get-bulk-request

get-next-request と同様に、get-response に get-next インタラクションを最大繰り返し数まで格納します。

set-request

特定の変数に値を格納します。

traps

SNMP エージェントから SNMP マネージャに送信される、何らかのイベントが発生したことを伝える割り込みメッセージ。

SNMP のトラップとインフォーム

SNMP エージェントは、重要なシステム イベントを識別するために、トラップ形式またはインフォーム形式で通知を送信します。トラップ形式の場合は宛先からの確認応答を受信しませんが、インフォーム形式の場合は確認応答を受信します。


) Cisco Unity Connection では、SNMP トラップはサポートされていません。


対応するトラップ フラグが有効な場合、すべての通知のトラップが即座に送信されます。syslog エージェントの場合、Cisco Unified CM アラームとシステム レベルのログ メッセージが syslog デーモンに送信され、ログに記録されます。また、一部の標準的なサードパーティ製アプリケーションでもログ メッセージが syslog デーモンに送信され、ログに記録されます。これらのログ メッセージはローカルの syslog ファイルに記録され、SNMP トラップまたは通知への変換も行われます。

次に、設定済みのトラップの宛先に送信される、Cisco Unified CM の SNMP トラップとインフォーム メッセージを示します。

Cisco Unified CM failed(Cisco Unified CM で障害が発生)

Phone failed(電話機で障害が発生)

Phones status update(電話機ステータスの更新)

Gateway failed(ゲートウェイで障害が発生)

Media resource list exhausted(メディア リソース リストが使い果たされた)

Route list exhausted(ルート リストが使い果たされた)

Gateway layer 2 change(ゲートウェイ レイヤ 2 の変更)

Quality report(品質レポート)

Malicious call(悪質なコール)

Syslog message generated(syslog メッセージの生成)

SNMP トレースの設定

Cisco Unified CM で SNMP エージェントのトレースを設定するには、Cisco Unified Serviceability の [トレース設定(Trace Configuration)] ウィンドウで、[パフォーマンスおよびモニタリング サービス(Performance and Monitoring Services)] サービス グループの [Cisco Unified CM SNMP サービス(Cisco Unified CM SNMP Service)] を選択します。デフォルトの設定は、すべてのエージェントに対して存在します。Cisco CDP Agent および Cisco Syslog Agent の場合、Command Line Interface(CLI; コマンドライン インターフェイス)を使用し、『 Command Line Interface Reference Guide for Cisco Unified Solutions 』に従ってトレース設定を変更します。

SNMP に関するヒント

「CISCO-CCM-CAPABILITY-MIB」( http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-CCM-CAPABILITY または 「CISCO-CCM-CAPABILITY」)を参照してください。「CISCO-CCM-CAPABILITY-MIB」で説明されているとおり、ccmPhoneDevicePoolIndex はサポートされていないため、0 を返します。現在、Callmanager デバイス登録アラームには、デバイス プール情報は含まれていません。

Cisco CallManager SNMP サービスが実行されていない場合、MIB の次のテーブルのみが応答します。

ccmGroupTable

ccmRegionTable

ccmRegionPairTable

ccmDevicePoolTable

ccmProductTypeTable

ccmQualityReportAlarmConfigInfo

ccmGlobalInfo

Cisco CallManager SNMP サービスを実行するには、Cisco Unified Serviceability でサービスをアクティブにし、起動します。SYSAPPL-MIB で、次のテーブルを照会します。

システムにインストールされている Cisco Unified Communications Manager アプリケーションのコンポーネントを取得するには、SysApplInstallPkgTable を照会します。

システムで実行中の Cisco Unified Communications Manager アプリケーションのコンポーネントを取得するには、SysApplRunTable を照会します。


) Cisco Unified Communications Manager では、次の Web アプリケーションのサービスとサーブレットを使用します。Cisco CallManager Admin、Cisco CallManager Cisco IP Phone Service、Cisco CallManager Personal Directory、Cisco CallManager Serviceability、Cisco CallManager Serviceability RTMT、Cisco エクステンション モビリティ、Cisco エクステンション モビリティ アプリケーション、Cisco RTMT Reporter Servlet、Cisco Tomcat Stats Servlet、Cisco Trace Collection Servlet、Cisco AXL Web Service、Cisco Unified Mobile Voice Access Service、Cisco IP Manager Assistant、Cisco Web Dialer サービス、Cisco CAR Web Service、Cisco Dialed Number Analyzer。


SNMP のトラブルシューティング

まず、すべての機能とネットワーク サービスが実行されていることを確認してください。また、Cisco Unified CM システムで、コミュニティ ストリングまたは SNMP ユーザが適切に設定されていることを確認してください。SNMP コミュニティ ストリングまたは SNMP ユーザを設定するには、Cisco Unified Serviceability で、[SNMP] > [V1/V2] > [コミュニティ ストリング(Community String)] または [SNMP] > [V3] > [ユーザ(User)] を選択します。

その他のヒントは、次のとおりです。

システムから MIB をポーリングできない:コミュニティ ストリングまたは SNMP ユーザがシステムで設定されていません。または、MIB が、システムで設定されているものと一致していません。必要に応じて、設定の確認および再設定を行ってください。


) デフォルトでは、コミュニティ ストリングまたはユーザはシステムに設定されていません。


システムから通知を受信できない:システムで通知の宛先が正しく設定されていません。[通知の宛先(V1/V2c または V3)の設定(Notification Destination (V1/V2c or V3) Configuration)] ウィンドウで通知の宛先が適切に設定されていることを確認してください。

Cisco Unified Communications Manager ノードから SNMP トラップを受信できない:電話機の登録/未登録/障害に関する次の MIB Object IDentifier(OID; オブジェクト ID)が、次の値に設定されていることを確認してください(デフォルト値は両方とも 0 です)。

ccmPhoneFailedAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.2)が 30 ~ 3600 に設定されていること。次の CLI コマンドを使用できます。 snmpset -c <community string> -v2c <transmitter ipaddress> 1.3.6.1.4.1.9.9.156.1.9.2 .0 i <value>

ccmPhoneStatusUpdateAlarmInterval(1.3.6.1.4.1.9.9.156.1.9.4)が 30 ~ 3600 に設定されていること。次の CLI コマンドを使用できます。 snmpset -c <community string> -v2c <transmitter ipaddress> 1.3.6.1.4.1.9.9.156.1.9.4.0 i <value>

[通知の宛先(V1/V2c または V3)の設定(Notification Destination (V1/V2c or V3) Configuration)] ウィンドウで通知の宛先が適切に設定されていることを確認してください。

[コミュニティ ストリング(V1/V2c)またはユーザ(V3)の設定(Community String (V1/V2c) or User (V3) Configuration)] ウィンドウで、コミュニティ ストリングまたはユーザの権限(通知権限など)が正しく設定されていることを確認します。

システム アプリケーション エージェントでは、アクティブまたは非アクティブになっているサービスを表示したり、Web アプリケーションのサービスやサーブレットをモニタしたりすることができないため、システムの健全性や Cisco Unified Communications Manager アプリケーションのサービス ステータスをモニタするには、次の方法を使用します。

Web アプリケーションと非 Web アプリケーションの両方の完全なステータス情報(アクティベーション ステータスなど)を取得するには、Serviceability API の getservicestatus を使用します。詳細については、『 AXL Serviceability API Guide 』を参照してください。

CLI コマンド utils service list を使用して、サービス ステータスを確認します。

syslog を使用して、servM で生成されたメッセージをモニタします(次の例を参照)。

Mar 18 16:40:52 ciscart26 local7 6 : 92: Mar 18 11:10:52.630 UTC : %CCM_SERVICEMANAGER-SERVICEMANAGER-6-ServiceActivated: Service Activated. Service Name:Cisco CallManager SNMP Service App ID:Cisco Service Manager Cluster ID: Node ID:ciscart26
 

SNMP 要求で複数の OID を指定し、変数が空のテーブルを指している場合、タイムアウトの問題により、NO_SUCH_NAME(SNMPv1 の場合)または GENERIC ERROR(SNMPv2c または SNMPv3 の場合)が返されることがあります。Cisco Unified Communications Manager 処理エンジンを保護するために制御を強化すると、タイムアウトが発生することがあります。

スカラ オブジェクトを使用すると、CCMH323DeviceTable および ccmSIPDeviceTable のエントリ数を取得できます。そのため、SNMP マネージャ(クライアント)は、エントリが存在しない場合に、これらのテーブルでの不要な get/getnext オペレーションをしなくて済みます。SNMP 開発者は、この問題に対する次の回避策を使用できます。

使用可能なスカラ変数(1.3.6.1.4.1.9.9.156.1.5)を使用して、テーブルにアクセスする前にテーブル サイズを確認するか、目的のテーブルに対して get オペレーションを実行してから、空でないテーブルを照会します。

1 回の要求で照会する変数の数を減らします。たとえば、空のテーブルに対して管理アプリケーションのタイムアウトが 3 秒に設定されている場合、OID を 1 つだけ指定します (空でないテーブルの場合、1 つのデータ行の取得に 1 秒かかります)。

応答タイムアウトの値を大きくします。

再試行回数を減らします。

getbulk SNMP API を使用しないようにします。 getbulk API では MaxRepetitions で指定されているレコード数が取得されるため、次のオブジェクトがテーブルまたは MIB の外にある場合でも、そのオブジェクトが取得されます。空のテーブルの場合は、さらに遅延が大きくなります。テーブルが空でなく、レコード数が既知の場合は、 getbulk API を使用します。このような場合には、MaxRepetitions を 5 秒に設定し、5 秒以内の応答を要求します。

既存の制限に適合させるには、SNMP クエリーを作成します。

Cisco CallManager に登録されている電話機が多数ある場合は、定期的に PhoneTable をウォークするために、複数の getbulk を実行しないでください。電話機の更新が存在する場合に更新を行う ccmPhoneStatusUpdateTable を使用すると、PhoneTable をウォークするかどうかを決定できます。

MIB およびトラブルシューティングの詳細については、次の章を参照してください。

「シスコ管理情報ベース」

「業界標準の管理情報ベース」

「ベンダー固有の管理情報ベース」

SNMP/R MIB

SNMP/R バイナリに CPU のスパイクが生じている場合、次のログおよび情報を収集して分析します。

CPU 使用率が高い処理を確認します。

SNMP ポーリングが発生しているかどうかを確認し、アプリケーションのポーリング間隔を取得します。

show packages active snmp コマンドを使用して、SNMP バージョンを確認します。

show process using-most cpu コマンドを実行して、その出力を収集します。

file get activelog /cm/log/ris/csv/ コマンドを実行して、Perfmon ログを収集します。

SNMP マスター エージェントのトレースと、CPU 使用率の高いその他のバイナリを収集します。

さらに詳細にトラブルシューティングするには、上記の情報をテクニカル サポートに送信します。

SNMP マスター エージェントが起動しない場合は、ポート 161 が開いているかどうかを確認します。ポートが開いている場合は、SNMP マスター エージェントのトレースを収集して、さらに分析します。

Cisco Unified CM を Windows 版から Linux 版に移行する際には、Cisco Unified CM Release 5.x 以降では ccmH323DevRmtCM1InetAddress が OctetString で定義されていることに注意してください。そのため、IP アドレスが 16 進数で表示されます(Cisco Unified CM Release 4.x ではドット付き 10 進表記で表示されます)。