SNMP Tips 2007

まずは、SNMPの概要について、簡単な説明をします。

SNMPは「Simple Network Management Protocol」の略称で、直訳すると「簡易ネットワーク管理プロトコル」となります。プロトコルですから、本来の意味としては主に「情報交換手順」のことを指しますが、「SNMPという情報交換手順で、データの送信および受信をおこなうことが可能な仕組み」のことを指す場合の方が一般的です。（「プロトコル」＝「通信規約」が正しい解釈ですね） SNMPはTCP/IPネットワーク環境（オープンなネットワーク環境）の管理プロトコルとして規定され、主にネットワーク中継装置（ルータやスイッチなど）やTCP/IPプロトコルを利用する機器の情報を収集することを目的に作られています。最近ではSNMPの普及（もう業界標準と呼んでもよいでしょう）によって単にネットワーク管理に限らず、システム管理などを行うためにSNMPを使用する場合もあります。

では、管理者はSNMPをどのように使ってネットワークの情報を収集し管理を行うのでしょうか？

繰り返しますが、SNMPはあくまでプロトコルですから管理者は通信する相手（管理対象）が必要です。一般的に、「管理装置」のことを「マネージャ」，管理対象のことを「エージェント」と呼び、マネージャとエージェントの通信イメージは図1のようになります。

このように、マネージャはエージェントに対して情報の問い合わせを行い、エージェントはマネージャに応答します。また、エージェントからマネージャに対して情報を通知する手順もあります。このエージェントが持っている情報の集まりをMIB（Management Information Base)と言い、MIBに規定された個々の情報のことをオブジェクトと呼びます。そして、マネージャはエージェントの情報（MIB）を収集し、それらをもとにネットワークの状態を判断し管理することができます。

例えば、あるルータのインタフェース（ポート）の状態を確認したい場合は、ルータのインタフェースの状態を表すMIB情報に対してリクエストを行い、返り値（応答してきた値）を評価することで状態を確認できます。ただ、返り値の評価を行うためには、エージェントが動作している機器の機能や、ネットワークに関する知識が必要になります。また、SNMPマネージャには、あらかじめ評価を行うための設定（アラーム通知や性能情報収集の設定など）がされているものも多くあります。

ネットワーク管理用プロトコルであるSNMPは、ほとんどのネットワーク機器でサポートされています。一昔までは前は、SNMP対応機器は「インテリジェントXXXX」と呼ばれ差別化が図られていましたが、最近ではそのような呼び方はほとんどしなくなりましたね。実売価格が1万円前後の安価なルータ（ブロードバンドルータ）にもSNMPをサポートしているものもあります。ただ、最近はネットワーク機器の管理コンソールとしてSNMPを利用せずWebブラウザを利用する場合が増えてきています。ハイエンド機器でもSNMPだけではなく、構成情報はSOAPを利用するものもあるようです。ネットワーク機器以外でも各種サーバの監視（プロセスの稼動状態や、各種使用率などの監視）用にもSNMPが利用されています。

個々の機器の構成情報を管理するためのコンソールとしてWebブラウザを利用することは非常に便利なのですが、複数の機器のイベント（故障など）や性能情報を自動的に管理/収集するとなると、やはりSNMPを利用するほうが便利です。

SNMPが1990年に策定されてから既に15年が過ぎておりますが、SNMPの次の管理手順の本命が出てきていないようです。TCP/IPが残っている限りSNMPは残り続けるのではないでしょうか。

SNMPには、大きく分けて3つのバージョンがあります。

RFC-3410にSNMPv1からSNMPv3までの情報がまとめて記述してあります。概要を把握したい方にはお勧めのRFCです。

最初に策定されたSNMPです。

策定された当時は、SNMPv1とは呼ばずに「SNMP」と呼んでいました。ただ、SNMPのプロトコルのPDUのバージョン情報にはしっかりと「1」と定義されています。（最初のガンダムが、今では「ファーストガンダム」と呼ばれるようになったのと同じようなものですね:P)

SNMPv1については、以前の「SNMPtips」に詳細が記述してありますので参考にしてください。

SNMPv2は、現在ではSNMPv2cとして普及しています。

SNMPv2を構成するRFCは沢山ありますが、情報交換手順としての記述はRFC1901(Community-basedSNMPv2)として定義されています。

また、SNMPv1からの主な変更点は以下の通りです。

SNMPv1でのデータタイプ定義のあいまいさの修正やネットワークインタフェースの帯域幅の拡張などによるより大きな値の取り扱いの必要性などから、データタイプの拡張が行われています。

変更された代表的な型は以下の通りです

• Counter32の定義：Objectの値を明示的に 2^32-1として再定義されています
• Counter64の定義：Objectの値として 2^64-1の値まで定義することができるようになりました。

SNMPv1とSNMPv2ではエラーの定義が大幅に変更されています。

SNMP対応機器でも、MIB-2のすべてのObjectを実装していないもの、実装する必要のないものがあります。

SNMPv2ではSNMPv1と比較して、それらの機器に対してリクエストを行ったときに、Objectの実装状況を判別しやすくなっています。

ただし、これはSNMPエージェントからのエラー応答をマネージャソフトウェアが、どう表示するかによって異なりますので、あまり違いを意識する必要はないでしょう。

SNMPv1 get-requestは、1回のリクエストで複数の情報を収集するために、いちいち通信しています。

そこで、SNMPv2ではGetBulkRequestが定義されています。以下に GetBulkRequest のシーケンスを示します。

ただし、セキュリティ機能については、（盛りだくさんにしすぎたため？）ほとんど普及せず、セキュリティ機能を簡略化したものとして SNMPv2cが現在普及しています。

SNMPv2を構成するRFCは沢山ありますが、情報交換手順としての記述はRFC3412で定義されています。

このRFCは、SNMPv3の情報交換手順というより、SNMPv1からSNMPv3の情報交換手順について記述されています。

SNMPv3では、「マネージャ」と「エージェント」という考えではなく「SNMPエンジン」という考え方が採用され、「SNMPエンジン」と「SNMPエンジン」が通信を行うというような表現となっています。

SNMPv3については、別途紹介できればと思っています。

SMIは管理情報（MIB）を定義するためのルールのようなものです。ですから、開発者以外はあまり気にする必要はありません。ただし、MIBの定義について規定されているものなので、興味のある方は目を通しておくとよいかもしれません。また、SNMPマネージャを利用するときにMIBのコンパイルエラー（パースエラー）となるときなどは、SMIについて理解していると、自力で修正できる場合もあります。

メーカが提供する拡張MIBにはSMIやASN.1の規則違反やタイプミス（！）などの原因で、SNMPマネージャソフトウェアにMIBを追加できない場合があります。このような時は、SMIやASN.1を確認する必要があります。（メーカ等に問い合わせても、答えが返ってこない場合ですが．．．）

一時期は拡張MIBの規則違反は少なくなっていたのですが、SNMPv2やSNMPv3の登場で、大手のネットワーク機器ベンダのMIBファイルでさえ規則違反の拡張MIBが増えてきています。

SMIにも SNMPv1用SMIとSNMPv2用SMIがあります。後者は SMIv2 と表現する場合が多いですね。

MIBは管理情報の集まりのことで、一種のデータベースのようなものです。個々の管理情報（MIBの構成要素）のことをオブジェクト（Object）と呼びます。

MIBといっても、メーカや機種別に様々なものがありますが、「TCP/IPデバイスが実装すべきMIB」として定義してあるのがMIB-2（RFC1213)です。RFCでは、MIB-2以外にも、HUBやBridgeなどの機種別やFDDI用やATM用などの様々なMIBが定義されています。また、SNMPv2用のMIBとしてMIB-2を定義し直したもの(RFC1902)も定義されています。

これらの、RFCで規定されているMIBのことを標準MIBと言います。一方、メーカ独自の管理情報が定義されたものは拡張MIBやベンダMIBなどと呼ばれ、実装されている機器についての詳しい情報が定義されています。

MIBの構成要素であるオブジェクトにはそれぞれ識別子（ID）が割り振られています。オブジェクトIDは必ず一意でなければいけません。たとえば、MIB-2のsysDiscrというオブジェクトには、「1.3.6.1.4.2.1.1.1」というIDが割り振られています。オブジェクトIDの体系をツリー状に表したのがMIBツリーと呼ばれるものです。(図4)
ただし、実際の管理者にとってはオブジェクトIDやその関係より、オブジェクトの意味の方が重要です。

MIBツリーについて記述すると

「なんのことだかよくわからない」
という声をよく聞きます。

SNMPの解説にはMIBツリーの記述はつきものですが、利用者にとってMIBのツリー自体にはさほど気にする必要はありません。OBJECT-IDとOBJECT名の対応が一意となるようにするためのものと考えておけばよいと思います。DNSとIPアドレスの関係みたいなものですね。

例えば、エクサという会社が拡張MIBを定義しようとしたときに、勝手にObjectのIDを付けると、どこか別の会社の拡張MIBのObjectIDと重複する可能性があります。

そこで、まずIANAに対して Enterprise IDの取得を申請し、会社のEnterpriseIDを取得します。（エクサのEnterpriseIDは1030 です）

この EnterpriseID以下に独自にIDを付加していけば、他社のObjectIDと重複することはなくなります。

SMIとASN.1(※)に則って記述されているドキュメントのことをMIBファイルと呼びます。

MIBファイルには、そのMIBに含まれるオブジェクトIDやその意味などが記述されています。

SNMPで管理対象からどのような情報を収集できるかどうかは、管理対象がサポートしているMIBファイルを見る必要があります。

※ASN.1（抽象構文記法タイプ１）：（「ISO 8824」もしくは「JIS X 5603」）ISOが規定するデータ標記等のルール。SNMPでは、そのサブセットを利用しています。

SNMPv2やSNMPv3のMIBの書式は、SNMPv1との互換性はありません。これは、MIBの書式を定義するSMIが異なるためです。

ただ、世の中に出回っているMIBには、SNMPv2用のMIBとして定義しているものの、一部がSNMPv1の書式で記述されていたり、SNMPv1の定義を利用していたりしているものがあります。

厳密なMIBコンパイラーを利用するとこのようなMIBはコンパイルエラーとなってしまいます。この場合、MIBファイルを正しいMIBとして定義しなおす（編集する）のは至難の業です。また、SMIv1とSMIv2では一部の型の定義が異なりますので、SNMPマネージャが正しく型を判断できなくなる可能性もあります。

ぜひとも、このようなMIBファイルの定義はやめていただきたいものですね。