技術情報

SNMP Protocol MIB (Manegement Information Base)

SMIが各管理グループや管理オブジェクトの管理情報の構造及び作成ルールを規定していることは既に述べましたが、MIBはそのSMI仕様に基づいて、管理あるいは制御される実際の管理オブジェクトが持つべき情報について規定しています。
これにはソフトウェアに関連した情報もハードウェアに関連した情報も含まれていますが、MIBとはネットワーク管理システムによってサポートされるべき一連のテストポイントや制御ポイントについて定義したものであると言い替えることもできるでしょう。

ここで重要なのは、MIBの定義はSNMPネットワーク管理プロトコルとは独立しているということです。これにより新しいデータ構造がMIBに追加されたり、別の管理概念のMIBが新規に考案されたとしても、SNMPプロトコル自体は変更する必要がありません。
将来、電子レンジやトースターにもMIBが設定され、ホームコンピュータによる管理が行なわれるような時代が来るのかも知れません。

●MIBの記述例
SMI仕様に基づいたMIBの記述例をリスト1に示します。

リスト1 SMI仕様にもとづいたMIBの記述例

リスト1 SMI仕様にもとづいたMIBの記述例

管理オブジェクトにおける数値表現

記述されるオブジェクトが管理グループの場合は、"OBJECT IDENTIFIER"というキーワードで定義します。また、記述されるオブジェクトが管理オブジェクトである場合は、"OBJECT-TYPE"というキーワードで定義します。各キーワードは、ASN.１マクロとして定義されています。最初の行の記述は、"mgmt"は"internet"の下位管理グループであり、その管理グループにおける数値表現による名称は"2"であることを表しています。つまり、"mgmt"は数値表現では"1.3.6.1.2"ということを定義しているわけです。
同様にそれ以下の行は、"mib"は"mgmt"の下位管理グループであることを示し、"interfaces"は"mib"の下位管理グループであることを示しています。
"OBJECT-TYPE"が使用されている"ifNumber"は、管理グループ"interfaces"に含まれている管理オブジェクトであることを示しています。その数値表現は、"1.3.6.1.2.1.2.1"となります。

管理オブジェクトのデータ形式

もう一つのキーワードである"OBJECT-TYPE"は、"SYNTAX"、"ACCESS"、"STATUS"、"DESCRIPTION"の４種の定義要素を含んでいます。
"SYNTAX"は、管理オブジェクトのデータ形式（Data Type)を定義します。リスト1では、"INTEGER"型を指定しています。SMI仕様ではこの様なASN.１表記の基本形以外に "NetworkAddress"、"IpAddress" 、"Counter" 、"Gauge"、"TimeTicks"、 "Opacue"といったデータ形式が新たに定義されています。

管理オブジェクトのアクセス権

"ACCESS"は、管理オブジェクトに対するアクセス権を示しています。読み出しだけが可能な"read-only"、読み出し/書き込み共可能な"read-write"、書き込みだけ可能な"write-only"、読み出し/書き込み共に禁止の"not-accessible"の4つのレベルが用意されています。"not-accessible"というのは意味のない定義のように思われますが、機器によってはサポートできなかったり意味がない管理オブジェクトもあるわけで、そうした管理オブジェクトが"not-accessible"になります。リスト1の"ifTable"はMIB-Iでは、"read-write"となっていましたが、MIB-IIになって"not-accessible"に変更されたものです。

管理オブジェクトのサポート要求条件

"STATUS"は、管理オブジェクトのサポートの要求条件を示しています。
要求条件には、

    1. サポートが必須のmandately
    2. サポートが任意であるoption
    3. サポートする必要がないobsolete
  2. 新たに追加されたdeprecated（※1）

上記4つの条件が定義されています。"deprecated"は、MIBの将来の変更に対する準備のために使用されるものです。これに該当する管理オブジェクトは現在サポートしなくてはなりませんが、次のバージョンアップ時にはサポートする必要がなくなるのが普通です。
既存の管理オブジェクトと同等もしくはそれ以上の機能をもった管理オブジェクトが新しく定義されたときは、既存の管理オブジェクトは常に"deprecated"の状態におかれます。ＭＩＢ－ＩＩではアドレス変換グループがこれに該当していますが、これはアドレス変換情報が他の管理グループに移されたためです。
"DESCRIPTION"は説明文用のキーワードで、定義した管理グループもしくは管理オブジェクトに対する説明文を記述します。

（※1）"不賛成"と訳されている場合がありますが、"軽視"あるいは同義語の"depreciated"として"価値低下"と訳した方が意味的には合うように思われます。

●MIBの標準化作業 

インターネットではMIBの標準化作業が順次進められています。その成果は以下のRFC文書として公開されています。その中から主要なものを以下に示しておきます。

表1 MIBに間するRFC文章

表1 MIBに間するRFC文章

●MIB-I (RFC 1156) 

MIB-I(RFC 1156)は、最初のインターネット標準MIBです。そこでは、インターネットの管理に有効と思われる最小限の管理オブジェクトが定義されました。その管理オブジェクトは以下の基本方針に基づいて選択されましたが、実用性に重点がおかれています。

  1. 障害管理もしくは構成管理のために必須である。
  2. セキュリティ機能が十分でないため、制御機能を持つ管理オブジェクトについては、その制御機能が弱い（制限されている）ものに限る。
  3. 実際に使用され、その有効性が証明済みである。
  4. ベンダー（機器提供者）が機器に登載しやすいように、管理オブジェクトは総数で100個程度にする。
  5. 冗長的な変数をなくすために、他の管理オブジェクトから類推できるような管理オブジェクトであってはならない。
  6. 特定の開発環境及び機器に依存した管理オブジェクトは除外する。
  7. クリチカルセクション（時間的制限が厳しい領域）のプログラミングが難しくならないように、一つのクリチカルセクション当たりカウンタ的な管理オブジェクトは１つしか設けないことを原則とする。

管理の対象となる全てのネットワーク機器はインターネット標準のMIBを登載しなければなりませんが、定義された全ての管理オブジェクトがそれらの機器で必要なわけではありません。そこで、MIB-Iでは管理オブジェクトを8つの管理グループに分類しています。
管理の対象となる機器が分類された各グループの機能を持っている場合にのみ、その機器はそのグループとして定義されている全ての管理オブジェクトをサポートしなければなりません。例えば、その機器がEGP(Exterior Gateway Protocol)プロトコルを使用している場合にのみ、EGP管理グループの管理オブジェクトをサポートすれば良いのです。

●MIB-II (RFC 1213) 

MIB-II(RFC 1213)は、MIB-Iとの上位互換性を考慮して制定されたもので、MIB-Iに取って替わるものです。そのため、オブジェクト識別子もテキスト表記こそ"mib-2"となってはいますが、その定義は

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

で、MIB-Iと同一になっています。
MIB-IIの第一目標は新しい管理オブジェクトの定義でしたが、その他にもマルチプロトコル機器のサポートのための改良や、MIB定義の正確さや読み易さを改善するための文書校正等が行なわれています。
MIB-IIのでの大きな変更点を以下に示します。

  1. at管理グループが "desprecated"状態になった（将来のMIB-IIIでは"obsolete"になる見込み）。
  2. 新たに、transmissionグループとsnmp管理グループが追加された。

●MIB-IとMIB-IIの比較

MIB-IとMIB-IIの比較表を表2に、各管理グループの役割を表3に示します。

表2 MIB-IとMIB-IIの管理項目数の比較

表2 MIB-IとMIB-IIの管理項目数の比較

表3 各管理グループの役割

表3 各管理グループの役割

●802.3リピータMIB 

LANの代名詞ともいえるイーサネットは、IEEE(Institute of Electrical and Electronics Engineers)で規格化されIEEE802.3規格になりました。これはご存知のように、10Mbpsの転送速度をもったベースバンド変調のCSMA/CD(Carrier Sense Multiple Access with Collision Detection)方式のLANです。その転送媒体も当初はイエローケーブルとして知られる太い同軸ケーブル(10BASE5規格)だけでしたが、その後チーパネットとかシンイーサネットとか呼ばれる細めの同軸ケーブル(10BASE2規格)の仕様が追加され、現在ではツイストペア線(10BASE-T規格)へと発展しています。

これらのLANではセグメントの延長距離にそれぞれ限界があり、10BASE2規格で最大185m、10BASE5規格で最大500m、10BASE-T規格で最大100mとなっています。これ以上の距離が必要になった時に使用するセグメント延長用の機器がリピータと呼ばれるもので、データ信号の中継動作を行なうものです。
リピータも現在はマルチポートのものが主流です。特に10BASE-T規格はマルチポートリピータを中心に展開されるもので、6ポートから50ポートあるいはそれ以上のものまで商品化され、集線装置的な意味合いも含めてハブ(Hub)と呼ばれることの方が多くなっています。ハブ/マルチポートリピータは各ポートを切り放す機構を備えているのが普通ですので、これをSNMPで有効利用すればネットワークの状況を監視しながら障害セグメントの切り放しが可能になるわけです。
このリピータに関するMIBの規格化は現在まだ暫定版（ドラフトレベル）であり、定義内容もまだ流動的なようですのでここでの説明は省略しますが、参考までに現在定義されている管理グループのツリー構造(RFC 1368)を図5に示します。

図5 IEEE802.3リピータMIBのツリー構造

図5 IEEE802.3リピータMIBのツリー構造

●RMON MIB(RFC 1271) 

RMON MIB(RFC 1271)のRMONは、Remote Network Monitoringの略ですが、ネットワーク上のトラフィックの状況をSNMP管理プロトコルを用いて監視するために定義されたものです。現在はまだイーサネット主体の定義しかなされていませんが、順次トークンリングやFDDI等のサポートも行なわれる予定です。
RMON MIBをサポートしたネットワーク機器には色々な形態があります。ローカルなSNMP管理システムの場合もありますし、専用の監視装置の場合やルータ等の場合も考えられます。いずれの場合も、標準化されたRMON MIBによりその機器が接続されているネットワークの状況をSNMPプロトコルによって監視することが可能になります。これは、さまざまなベンダー（いわゆるマルチベンダー）の監視装置をSNMPにより一括管理できることを意味し、RMON MIBの最も重要なポイントです。こうした種々の機器間での相互接続性は、分散型ネットワーク管理システムを構築する際には必須の条件になります。

●RMON MIBのグループ構成 

RMON MIBは以下の9つのグループに分けられています(表4)。

表4 RMON MIBのグループ

表4 RMON MIBのグループ

上記グループのサポートは全てオプションですが、既に述べたMIB-IIと同様に、サポートした管理グループではそこに含まれる全ての管理オブジェクトがサポートされなければなりません。また、RMON MIBをサポートしている機器は、MIB-IIのsystemグループとinterfacesグループもサポートしていなければなりません。
RMON MIBのツリー構造とトラップ設定例を図6に示します。

図6 RMON MIBのツリー構造とトラップ設定例

図6 RMON MIBのツリー構造とトラップ設定例

●ベンダ固有のMIB 

MIB-I、MIB-II等の標準MIBで定義されているのは、共通の核となるべき管理オブジェクトにすぎません。それだけでは不十分なネットワーク機器も当然存在します。
これらはネットワーク機器を提供するベンダーの設計方針に依存する部分が多いので、各ベンダー固有のMIBが定義できるように規格上で配慮されています。
ベンダー固有のMIBは、MIBのツリー構造では管理グループ"private"の下位管理グループである"enterprises"の下に配置されます。ベンダー固有のMIBを必要とするベンダーはIANA(Internet Assigned Numbers Authority)に申請して企業番号を取得する必要があります。
フジクラ製の超小型SNMPハブであるFN1600シリーズはベンダー固有のMIBをサポートしていますので、ベンダー固有管理オブジェクトの例として図7に示しておきます。

図7 ベンダ固有のMIBの例

図7 ベンダ固有のMIBの例