どのようにしてネットワークを管理するのか？：監視を自動化するSNMP（2）

» 2003年03月21日 00時00分公開

　前回「なぜネットワークを管理しなければならないか」はネットワークシステム管理の意義と、SNMPというプロトコルについて概要を解説しました。今回はSNMPが実際にどのようにしてネットワークシステムを管理するか、そのアーキテクチャについて解説します。

機器の情報を蓄積するMIB（Management Information Base）

　SNMPによって何が管理できるかは、監視する機器の情報の集合である管理情報ベースによって左右されます。この管理情報ベースは一般に「MIB（Management Information Base）」と呼ばれています。

　MIBの実体は監視対象機器にあり、SNMPのエージェントはこのMIBの内容から現在の機器の状態を判断します。SNMPではMIBで管理されていない情報を取得することはできません。そのため、MIBがどのような情報を、どのように管理しているのかを知っておく必要があります。

MIBのデータはオブジェクトIDで管理される

　MIBに格納されている機器の情報は、それぞれ「オブジェクト（Object）」と呼ばれる単位で管理されます。個々のオブジェクトは情報の要素によって、ツリー構造で管理されます。オブジェクトにはそれぞれ「オブジェクトID（OID）」という識別子が割り当てられています。OIDは「1.3.6.1.2.1.1.4」のように、ピリオドで区切られた数字で、ツリーの階層ごとに枝番を割り当てる形式で採番されています（ちなみにこのOIDが示すオブジェクトは、機器の管理者のメールアドレスです）。

　SNMPではマネージャからエージェントにOIDを指定して監視対象機器の情報の取得や設定変更を要求したり、エージェントが定期的に設定されているOIDのオブジェクトの値を確認してマネージャにトラップとして通知する方法でネットワークシステムを管理します。

　MIBに含まれているオブジェクトのOIDとその意味は「MIBファイル」というテキストファイルに記述されています。監視対象機器からSNMPを使ってどのような情報を収集できるかは、その監視対象機器がサポートしているMIBファイルを確認する必要があります。

基本的な情報はMIB-2で分かる

　MIBといってもベンダや機種によってさまざまなサブツリーが定義されています。ただしRFCが定義しているMIBのサブツリーを「標準MIB」と呼び、ベンダなどが独自に拡張したMIBのサブツリーである「プライベートMIB」と区別しています。これらの標準MIBの中でも特にIPネットワークに接続されるデバイスが管理するべき情報として「RFC 1213」で定義されているMIBのサブツリーが「MIB-2」です。MIB-2に割り当てられているOIDは「1.3.6.1.2.1」です。

　このMIB-2だけでもネットワークシステム管理の多くの部分をサポートしますが、監視対象機器のサポートしている特殊な機能などを利用するのであれば、それらの機器のプライベートMIBサブツリーを確認する必要があります。

3種類の機能を5つのコマンドで実行

　SNMPのマネージャとエージェントは、SNMPメッセージによってネットワークシステムを管理します。このSNMPメッセージにはSNMPバージョン、コミュニティ名、PDU（Protocol Data Units）が含まれています。PDUはSNMPのコマンドに当たるデータで、次の5種類があります。


マネージャからエージェントに送信するSNMPメッセージのPDU
GetRequest	指定したOIDのオブジェクトの情報取得を要求
GetNextRequest	指定したOIDの階層的に次のオブジェクトの情報取得を要求
SetRequest	指定したOIDのオブジェクトの情報変更を要求


エージェントからマネージャに送信するSNMPメッセージのPDU
GetResponse	マネージャからの要求に対する返答
Trap	自発的に状態（変更）を通知
表1　5種類のPDU（Protocol Data Units）

　これらのPDUによってSNMPは次の3種類の動作を実行します。

マネージャからエージェントに情報を要求
マネージャからエージェントに情報の更新を要求
エージェントがマネージャに機器の状態変化を通知

マネージャからエージェントに情報を要求する

　マネージャから監視対象機器のエージェントに対して、OIDで指定されたオブジェクトの情報を1つまたは複数要求する機能です。監視対象機器のMIBから情報を取得するには、次の手順を実行します。

（1）マネージャは情報を取得したいオブジェクトのOIDを指定したGetRequestをエージェントに送信します。
（2）エージェントはGetRequestで指定されているオブジェクトの情報をMIBから取得し、その内容をGetResponseで通知します。

図1　GetRequestによりマネージャからエージェントに情報を要求する場合のシークエンス

　また、マネージャからの情報取得を1つまたは複数要求するPDUとしてGetNextRequestがあります。GetRequestと異なっている点は、GetNextRequestではPDU内で指定されているOIDの辞書順に見て次（階層的に次）のOIDが指定するオブジェクトの値を要求するということにあります。これは主にテーブルからオブジェクトを取得するために利用します。

（1）マネージャはGetNextRequestをエージェントに送信して、オブジェクトの情報を要求します。
（2）エージェントはGetNextRequestで指定されているOIDの、辞書順に見て次のOIDが指定するオブジェクトの情報をMIBから取得し、その内容をGetResponseで通知します。

図2　GetNextRequestによりマネージャからエージェントに情報を要求する場合のシークエンス

マネージャからエージェントに情報の更新を要求する

　あまり頻繁に実行する作業ではありませんが、SNMPのメッセージを使ってマネージャから監視対象機器のMIBの内容を更新することができます。監視対象機器のMIBは次の手順で更新します。

（1）マネージャは情報を更新したいオブジェクトのOIDと、更新したい内容を指定したSetRequestをエージェントに送信します。
（2）エージェントはSetRequestで指定されているオブジェクトの情報を更新し、その結果をGetResponseで通知します。

図3　マネージャからエージェントに情報の更新を要求する場合のシークエンス

エージェントがマネージャに機器の状態変化を通知する

　3番目はエージェントが特定のオブジェクトの状態を常に監視し、オブジェクトの値が事前に指定した状態に変化した場合、その旨をマネージャに通知する機能です。この機能を実現するSNMPのメッセージがTrapであるため、一般にTrap通知やTrap監視などと呼ばれています。

（1）エージェントは指定されたOIDのオブジェクトを常に監視し、その値が指定された状態に変化した場合、その旨をTrapでマネージャに通知します。

図4　マネージャからエージェントに情報の更新を要求する場合のシークエンス

SNMPメッセージの構造とPDU

　先ほども述べましたが、基本的にSNMPはUDPによって実現されます。そのためそのデータグラムは次の図のようになります。

図5　転送フレームでのSNMPメッセージ

　現在主に使用されているSNMPのバージョンはSNMPv1で、SNMPメッセージ内のSNMPバージョンの値は0となります。もしSNMPv2を利用する場合には、この値は1とセットします。

　コミュニティは、マネージャとエージェントの間でパスワードとして利用されます。SNMPにおける唯一のセキュリティと呼べる部分ですが、「public」などのデフォルトの状態で利用しているシステムも多いようです。

　PDUは前述のとおりGetRequest、GetNextRequest、SetRequest、GetResponse、Trapの5種類ですが、このうちTrapだけがその用途からPDU構造が異なります。

Get、Set、ResponseのPDU構造

　GetRequest、GetNextRequest、SetRequest、GetResponseのPDU構造は次の図6のとおりです。

図6　GetRequest／GetNextRequest／SetRequest／GetResponseのPDU構造

PDU Typeフィールド
PDU Typeフィールドには、それぞれ次の値をセットします。


PDU Typeフィールドの値
0	GetRequest
1	GetNextRequest
2	GetResponce
3	SetRequest#6699FF
4	Trap
表2　PDU Typeフィールドの値

Request IDフィールド
Request IDフィールドには、マネージャからの要求とエージェントからの応答を関連付けるための値をセットします。
Error Statusフィールド
Error Statusフィールドには、正常な動作（NoError）あるいは、定義されている5種類のエラーのコードを設定します。Error Statusフィールドには、それぞれ次の値をセットします。


Error Statusフィールドの値
0	noError	エラーなし
1	TooBig	PDUサイズが制限を越えた
2	noSuchName	要求されたオブジェクトが存在しない
3	badValue	SetRequestに矛盾する値が含まれている
4	readOnly	未定義
5	GenErr	定義されていないエラー
表3　Error Statusフィールドの値

Error Indexフィールド
Error Indexフィールドには、エラーが発生した場合、PDU内に含まれるどのデータにエラーが発生したのかを示す値をセットします。

TrapのPDU構造

　TrapのPDU構造は図7のとおりです。前述したようにTrapのPDU Typeフィールドの値は“4”です。

図7　TrapのPDU構造

Enterpriseフィールド
Enterpriseフィールドには、このTrapを定義した管理エンタープライズの値をセットします。
AgentAddressフィールド
AgentAddressフィールドには、Trapの送信元のIPアドレスをセットします。
Trap Typeフィールド
Generic Trap TypeおよびSpecific Trap Typeフィールドには、マネージャにTrapで通知される監視対象機器のイベントを示す値をセットします。Generic Trap Typeフィールドには次の値をセットします。


Generic Trap Typeフィールドの値
0	coldStart	送信プロトコルエンティティの再初期化を検知した。そのためエンティティの実装が変更された可能性がある
1	warmStart	送信プロトコルエンティティの再初期化を検知したが、エンティティの実装に変更はない
2	linkDown	通信linkの障害を検知
3	linkUp	通信linkの回復を検知
4	authenticationFailure	コミュニティー名の一致しないSNMPメッセージの受信
5	egpNeighborLoss	EGPピアのノードダウン
6	enterpriseSpecific	Genericに定義されていないTrap
表4　Generic Trap Typeフィールドの値

　Generic Trap Typeフィールドの値が“6”の場合、つまりGenericに定義されていないTrapを利用する場合、Specific Trap TypeフィールドにそのTrapの値をセットします。これらのTrapを受信したマネージャは、EnterpriseフィールドとSpecific Trap Typeフィールドの値を参照してTrapの通知内容が何を示しているのかを判断します。

Timestampフィールド
Timestampフィールドには、エージェントが最後に起動（再初期化）してからTrapが発生するまでの経過時間をセットします。

MIBに拡張されるSNMP

　その名前のとおりにSNMPは非常にシンプルなプロトコルです。コマンドは5種類しかありませんし、それらのコマンドによって実現する機能は3種類です。ところが管理情報ベース（MIB）によって、SNMPで取得できる情報の種類は非常に広範囲に及びます。最近では家庭にも広く普及している低価格ルータの大半はMIB-2をサポートしていますし、独自に拡張した機能から得られる情報を活用できるようプライベートMIBを用意しているベンダも少なくありません。

　このようにMIBとSNMPはより身近な存在になりつつあるといっても過言ではないでしょう。しかしSNMPを使ってネットワークシステムを監視するだけでは、本当の意味でネットワークシステムを管理したことにはなりません。ネットワークシステムの管理にとって本当に重要なのはSNMPそのものではなく、SNMPによって取得（あるいは更新）できるデータをいかに管理に活用するかということにあります。

次回へ→

「監視を自動化するSNMP」バックナンバー