技術情報｜SNMPによるネットワーク管理

ネットワークは本来成長する宿命を帯びているようです。人間の脳も生まれた時からその細胞数は大人と変わりませんが、年とともに成長・複雑化する脳細胞間のネットワークによって知的活動が活発になってくるということです。コンピュータのネットワークも同様です。複数のコンピュータがネットワークで結合されることにより、いままで以上の能力を発揮することが期待できるようになっています。

一方、ネットワークの成長がスムーズに行なわれているかというと決してそうではありません。特にネットワークの管理担当者にとって、ネットワークの成長・拡大はそのまま頭痛の種の拡大を意味することが多くて、管理どころかトラブル対処に追われる日々が続くのが実状のようです。

一部の大企業や著名大学を除けばコンピュータのネットワーク化がほとんど進んでいなかったわが国ですが、最近になってイーサネットを中心にＬＡＮ(Local Area Network)が一般化し、ブームを巻き起こしている感すらあります。 接続されるコンピュータの数が少なく、またそれが同じフロアにあるような小規模のＬＡＮであれば、管理者が現場で障害解析を行なうことが可能ですし、比較的容易に障害の切り分けもできます。しかし、ネットワークの拡張に伴い接続される構成機器が増加し、地理的規模も拡大してくると現場解析だけに頼るわけにはいかなくなります。通常、ネットワークの拡大はそのままシステムとしての重要度の増大も意味しますので、障害の発生を未然に防ぐ必要性も出てきます。

一方、ネットワークに接続される機器及びその構成の複雑さは年々度合いを増していて、管理者の負担は増え続けるばかりです。実際に大きなネットワークでは現在の正確な構成を把握することすら難しくなってきています。
そこでネットワーク管理システム、それもコンピュータを含めたネットワーク機器の提供メーカに依存しない、いわゆるマルチベンダー対応のシステムの必要性が叫ばれ始めたわけです。
無思慮に拡張を進めたＬＡＮは"乱"にしか過ぎず、トラブル発生の元凶になりかねないことに十分注意しておく必要があります。

図1 成長するのが宿命のネットワーク

ネットワーク管理の目的

ネットワーク管理の目的や意味付けは人に応じてさまざまですが、その基本はネットワークを支障なく動作させることを第一前提に、その保守・運用を行なうことでしょう。ここではOSI(Open Systems Interconnection)での定義(ISO 7498-4)に基づいて説明することにします。OSIではネットワーク管理の機能が以下の５つの領域に分けて考えられています(図2)。

1. 障害管理 (Fault Management)
2. 構成管理 (Configuration Information)
3. 性能管理 (Performance Management)
4. 課金管理 (Accounting Management)
5. 機密管理 (Security Management)

図2 管理機能のOSI定義

ネットワーク管理として一般的に認識されているのはモニタリング機能を中心に展開される障害管理・構成管理・性能管理の３つです。先にも述べましたが、多くの管理担当者にとってはネットワーク管理すなわち障害管理を意味することがほとんどです。また、最近になって機密管理や課金管理も重要視されはじめています。

障害管理

障害管理における主要機能は、障害の検出・障害箇所の切り放し・障害の修復の３つです。これ以外にも障害履歴管理・故障診断プログラム等が障害管理機能に含まれます。

構成管理

構成管理の主な役割は、ネットワークの構成要素の詳細情報の収集です。そこからネットワークの現在のトポロジー（接続形態図）、動作状況等が管理できます。もちろんネットワークの構成を必要に応じて変更できる機能も備えていなければなりません。
大きなネットワークになればなるほどパソコン等の端末を中心としたネットワーク機器の増設や移動には多くの作業時間が必要となりますが、構成管理機能を強化することによってその時間短縮が可能となります。これは組織変更時のネットワークのダウンタイムを短くできることを意味しますので、有用な機能のひとつと言えます。

性能管理

性能管理は障害管理と密接な関係を持っています。ネットワークが早い応答速度を維持している間は障害が発生している確率が低いのが一般的です。一方、応答速度が極端に遅くなった場合には何らかの障害が発生しているものと考えるべきでしょう。
性能管理には別の側面もあります。ネットワークの動作状態を示す種々のパラメータ（転送パケット数や衝突回数等）の収集、各ネットワーク機器の状態履歴の管理・解析等の仕事です。それらを通じてネットワークの動作条件の最適化を図ることも重要な役割の一つと考えられています。

課金管理

課金管理は、ネットワーク中の資源の使用に関するデータを収集し、課金用基礎データを生成する役割を持ちます。事業部制や部門別に独立採算制を導入している企業では重要な機能の一つに数えられます。

機密管理

機密管理は、機密機能の設定・解除、機密関連情報の配布、機密違反の発生報告等をその主な役割としています。ハッカーによるネットワークへの不正侵入やコンピュータウィルスの媒介のニュースが数多く伝えられているように、ここ数年で機密管理の強化が強く叫ばれるようになりました。ネットワーク構築ではオープン性が重要視される一方で、相反する機能である機密管理を避けて通ることができなくなってきたわけです。特に企業ユーザにとっては、機密管理は企業の死活を左右する重要課題でもあり、その必要性の高さは言うまでもありません。

ネットワーク管理を目的としたプロトコル（通信規約）として業界標準の地位を確立した感のあるSNMP(Simple Network Management Protocol)ですが、その開発は米国国防総省主導で進められたインターネットに端を発していて、TCP/IP(Transmission Control Protocol/Internet Protocol)上での動作を目的として開発されたものです。
SNMPがネットワーク管理機能そのものを提供するのではないことに注意して下さい。SNMPはネットワーク管理システムを構築する上での枠組みであり、またその土台となるものなのです。

インターネット

インターネットは1969年にARPANET(Advanced Research Projects Agency Network)として誕生しましたが、この時点ではまだTCP/IPプロトコルは存在してなく、特殊なパケット交換ノードを介して接続されたシステムでした。インターネットの代名詞ともいうべきＴＣＰ／ＩＰは1970年代中頃から研究が開始され、1977年から1979年にかけて現在の形態となりました。TCP/IPへの移行は、1983年に完了しています。
TCP/IPにより種々の物理伝送媒体への接続が可能となったためインターネットの拡大は急速に進み、1990年には世界中で3,000以上のネットワークと200,000台以上のコンピュータを接続する規模に達しています。そして、現在もなお成長を続けています。

SNMPの誕生

急速な成長が続くインターネットでは、1980年代中頃には接続されるネットワークの数が毎年倍の勢いで増え続けていました。また、インターネットは階層型の構成が取られているため、各階層レベルでそれぞれのネットワーク部分を管理する組織が存在していました。残念なことにそれらの組織では意見の食い違いが多く発生していました。

こうした状況に危機感を感じた研究者を中心にSGMP(Simple Gateway Monitoring Protocol)と呼ばれるゲートウェイ（ルータ）管理用のプロトコルが提案されました。それがインターネットにおける管理プロトコルの始まりです。これ以前にもHEMS(High-level Entity Management System)と呼ばれるプロジェクトが存在していましたが普及には至っていませんでした。

また、OSIの提案であるCMIP(Common Management Information Protocol)のTCP/IPへの実装を目的としたCMOT（CMIP Over TCP)も同時期に提案されていました。
結局、ネットワーク管理プロトコルとしてSGMP/HEMS/CMOTを提案する３団体が存在することになり、それぞれのいがみ合いが続いたわけですが最終的には３者間での合意を得ることに成功しました。
その結果、HEMSは開発継続が断念されることになりました。また、SGMPを手直ししたプロトコルを当面のインターネットにおけるネットワーク管理プロトコルとして位置づけ、CMOTについては最終移行目標として開発を継続することになりました。

ここでSGMPの改良版として誕生したのがSNMPなのです。ＳＮＭＰは、1988年8月にドラフト版が公示され、1990年5月にインターネット標準になりました。

SNMPの規格の制定は、インターネットを管理運営する委員会であるIAB（Internet Activities Board）の下部組織であるIETF（Internet Engineering Task Force）内に設けられているワーキンググループで行なわれています。

SMIはインターネット文書RFC 1155で標準化されていますが、管理情報構造の作成ルールを定めているものです。つまり、管理される装置に関連する種々の情報が後述するMIB内でどのように表現（名前付け）されているか、またその構造はどう表現すべきかを定義しています。（※）

（※）SMIの規定ではすべての管理対象がツリー構造を構成するノードである各管理グループも含めてオブジェクト(Object)というひとつの概念でまとめられています。管理グループと実際の管理要素の違いはそのオブジェクトのタイプの違いだけです。ここでは理解を助けるために、オブジェクト識別子のタイプを持ったオブジェクトは"管理グループ"と表現し、その他の整数(INTEGER)、文字列(OCTEST STRINGS)等のタイプを持った実際の管理要素は"管理オブジェクト"と区別して表現することにします。

管理グループ作成のルール

ここでは階層的なデータ構造を実現するためにツリー構造が採択され、個々の管理グループはオブジェクト識別子(Object Idntifier)による名前付けがされています。名前はその管理対象が絶対的に定まるように、つまり世界に一つしか存在しないように、その名前付けルールが規定されています。
図4にインターネットのMIBツリーの一部を示します。

(　)内の番号は、オブジェクト識別子と呼ばれSMIで定義されているオブジェクトとにつけられた数値

図4 インターネットのMIBツリー

ツリー構造の始まりであるルート(ROOT)は特に名前付けされていませんが、その下に３つの管理グループ(CCITT/ISO/JOINT-ISO-CCITT)が位置づけられています。各管理グループにはテキストによる名称と整数による名称の両方が割当られていますが、テキストによる表現は人間がオブジェクトの名前を理解するのを助けるための補助的なものです。

各管理グループの名前はルートから各管理グループ名称をたどった形で表現され、各管理グループ名称間はドット(.)で区切られています。これはコンピュータで言えばディスクのディレクトリの階層表現そのものですので、コンピュータユーザには理解が簡単と思われます。

例えば、図3で管理グループ"ip"は、テキスト表現ではiso.org.dod.internet.mgmt.mib.ipとなり、数値表現では 1.3.6.1.2.1.4 となります。テキスト表現から数値表現を計算によって求めることはできないことに注意して下さい。テキスト表現と数値表現の対応には、規格書をもとに対応表を作成する必要があります。

管理グループの管理情報の構造

データ構造の表現形式には、ISO(International Organization for Standardization)の抽象構文記述法であるASN.1Abstract Syntacs Notation 1 ... ISO 8824)が用いられています。抽象構文は機器に依存したデータ構造や制限から、目的としているデータが影響を受けないように、厳密なデータ構造定義を提供するものです。この厳密な定義によって通常の文書による曖昧さをなくすことができます。厳密に定義された管理データ項目とその名前は相互運用性を保証することにもつながります。
ASN.1自体の説明はここでは紙面の都合上省略しますが、興味のある方は参考文献を参照して下さい。

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

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

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

リスト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. 1. サポートが必須のmandately
   2. サポートが任意であるoption
   3. サポートする必要がないobsolete
2. 新たに追加されたdeprecated（※1）

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

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

●MIBの標準化作業 

インターネットでは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の管理項目数の比較

表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のツリー構造

●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のグループ

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

図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の例

SNMPプロトコルは、管理対象の機器側に登載されるSNMPエージェントとネットワーク管理システム側に登載されるSNMPマネージャのエージェント/マネージャ形式を取っています(図8)。これはLANでよく耳にするクライアント/サーバーに相当し、分散処理化の流れに対応するものです。

図8 SNMPプロトコル階層

SNMPはTCP/IPのコネクションレス型のトランスポートサービスであるUDP(User datagram Protocol)を使用します。これは最も低機能のトランスポートサービスでありデータの到達も保証されていない信頼性の低いものですが、一方で再送レベルを自分で決められる利点もあります。つまり、ネットワークが混雑している時はパケットの再送間隔を伸ばして、管理パケットによるネットワークの更なる混雑を防ぐといった工夫が可能になる訳です。
SNMPはSNMPマネージャがコマンドを発行し、該当するSNMPエージェントがそれに応答するポーリング方式を基本にしていますが、管理対象機器に特定の事象が発生した場合にエージェント側から通知を行なうこともでき、トラップと呼ばれています。トラップも無制限に発生するとネットワークの使用効率が低下しますので、不必要なトラップの発生は制限されなければなりません。そこでSNMPではトラップはマネージャがポーリングのタイミング調整や管理対象に焦点を当てるために利用されると規定しています。
先にも述べた通り、SNMPではGetRequest/GetNextRequest/GetResponse/SetRequest/Trapの５つのコマンドしかサポートされていませんが、ポーリング主体であることと、管理の本質はMIBにあることを考えると必要かつ十分と言えるのではないでしょうか。

●SNMPパケット形式 

SNMPのパケット形式を図9に示しますが、SNMPメッセージ部分のコマンドが含まれている領域はPDU(Prototocol Data Unit)と呼ばれています。また、SNMPメッセージの先頭部分にはバージョン番号(Version)とコミュニティ名(Community)が定義され、SNMPマネージャとSNMPエージェントの管理関係の確認に利用されています。バージョン番号とコミュニティ名部分とを合わせて認証ヘッダー(Authentication Header)と呼ぶ場合もあります。

図9 SNMPパケットの構成

SNMPメッセージはASN.1表記の定義に基づいてコマンドや変数類で校正されていますが、一種の符号化が施されています。これはBER(Basic Encoding Rules)と呼ばれるもので、ASN.1の値をオクテット列（バイトデータ列）に変換する規則を定義しています。BERについての詳細はここでは省略します。
PDUには通常用途とトラップ用途の２つの形式が用意されていますが、ここでは通常のPDUの各フィールドについて説明しておきます。

Request-ID

このフィールドにはあるオペレーション要求を他と区別するための整数値がセットされ、SNMPエージェントはマネージャからの要求に対して同じRequest-ID値で応答します。この仕組みによりマネージャ側は要求したオペレーションに対するエージェント側の応答を簡単に対応づけることができますので、連続したコマンドの発行が可能になります。

Error-Status

このフィールドが"0"の場合は要求したオペレーションが正常に実行されたことを示しますが、それ以外の場合には何らかのエラーが発生しています。
エラーには次の5つが用意されています。

1. (エージェントが指定されたオペレーションの結果を１つのSNMPメッセージに入れることができなかったことを示す"tooBig(1)"
2. 指定した管理オブジェクトが存在していない場合の"noSuchName(2)"
3. 管理オブジェクト変数に対する変更要求値が適切でない場合の"badValue(3)"
4. 書き込みが禁止されている管理オブジェクト変数に対して変更要求を行なった場合の"readOnly(4)"
5. 他のエラーが発生した場合の"genErr(5)"

Error-Index

エラー発生時に、要求されたオペレーションに含まれているどの管理オブジェクト変数でエラーが発生したかを示すオフセット値です。先頭の変数が"1"となります。

Variable-Bindings

このフィールドには変数のリストが含まれ、複数の変数を指定することが可能です。リストは変数名とその値で１セットになっています。複数の変数を指定した場合、その中でエラーが一つでも発生すると、全ての要求が無効になるので注意が必要です。変数は管理オブジェクトに対応している訳ですが、このフィールドではテーブル変数の様な変数の集合体は定義できません。つまり、MIBの定義でテーブル変数になっている管理オブジェクトは、個々の要素に分けてアクセスしなければなりません。そこで管理オブジェクトの変数要素（インスタンスと呼ばれています）を指定するのに管理オブジェクト名に数字を付加する方式が取られています。管理オブジェクトがテーブルでなければ、".0"を付加します。例えば、"sysDescr.0" と表します。また、テーブルの場合はMIBでの定義に応じた数字の付加が行なわれます。例えば、IPアドレス関連のテーブルではIPアドレスを付加して、"ipAdEntNetMask.128.10.2.3"と表記します。
SNMPのメッセージ長に対しては、484バイト以下のメッセージが受信できることと規定されているだけですが、送信側もこの規約に準じた方が無難と思われます。

始めにも述べましたが、SNMPはCMIPへの移行を前提に過渡的なプロトコルとして制定されたものですので、その将来像はCMIPというのが建て前になっています。ところがCMIPのCは"Common(共通)"ではなく"Complex(複雑)"だとからかわれているようにCMIPへの移行はまだまだ先の話の様です。また最近、SMP（Simple Management Protocol）として開発が進められてきたものがSNMPv2（SNMP version 2）として公表され注目を浴びています。

SNMPの最大の弱点は、ネットワークの規模が大きくなった時に、管理のための通信量が大きくなることです。これはポーリング手法であることと単純なデータ検索手法しか提供されていないことに起因しています。また、マネージャ間通信のサポートやセキュリティ機能の強化もSNMPの課題の一つです。
CMIPもSNMPv2もSNMPの弱点を補う機能を持っていますが、既に業界標準の地位にあるSNMPが急に置き替わることはなく、しばらくは共存状態が続くものと思われます。では、CMIPとSNMPv2について簡単に紹介することにしましょう。

CMIP(CMOT/CMOL)

CMIPのTCP/IP対応であるCMOTのプロトコル階層を図10に示します。

図10 CMOT(CMIP Over TCP)のプロトコル階層

また、以下のコマンド（CMOTではサービスと呼ばれています）がサポートされています(表5)。

表5 CMIPのコマンド

SNMPでは管理オブジェクトはMIBとして固定的に定義されていなければだめでしたが、CMIPではこの機能により、管理オブジェクトの生成／削除を動的に行なうことができ、ネットワークの動的な管理が可能になります。CMIPではアプリケーションプログラムも管理オブジェクトとして生成することができ、その起動/停止等が可能になります。これはシステム運営上の管理能力のアップも期待できることを意味しています。

●CMIP独自の機能 

これ以外にもCMIPには、"Scoping"と"Filtering"の２つの強力な機能が付加されています。

＜Scoping機能＞
"Scoping"はマネージャからの管理操作が機器の一部分を対象にするか全体を対象にするかを指定できる機能です。
例えば、ある製品のシリアル番号管理を想定した場合に、製品全体でのシリアル番号だけとするか、その製品を構成しているボード群のシリアル番号まで含めるかといった区別が可能になります。

＜Filtering機能＞
"Filtering"は管理オブジェクトの値に応じた条件設定を提供する機能です。
例えば、ルータが使用するルーティングテーブルから"ipRouteAge > 100"の条件を満足するもののみ検索するといったことが行なえ、ＳＮＭＰより効率的な運用が可能です（管理のためのデータのトラフィック量を減少できます）。
また、ＣＭＩＰにおける管理オブジェクトにはオブジェクト指向の考えが強く導入されており、これも特色の一つになっています。

●CMIPの課題と対策 

以上の様に、機能的には期待できるCMIPですが、残念なことにその複雑さから実際の機器への登載は遅れ気味です。この現状を打破するためにプロトコルスタックの階層を減らしたアプローチがCMOL(CMIP over Logical Link Control)として提唱されていますので、それについても簡単に触れて置きましょう(図11)。

図11 CMIPとCMOLのプロトコル階層

通常のCMIPはネットワークの最上位レベルであるアプリケーション層（OSIモデルの第７層）で動作しますので、全ての階層のプロトコルの実装が必要となり、実装上非常に多くのメモリとCPUパワーを必要とします。これがCMIPの普及上最も大きな障害になってきた訳です。

＜CMOLの特徴(利点＞
CMOLはCMIPを第２層のデータリンク層までで実現することによりこの障害を克服しようとするもので、CMOLエージェントはわずか20Kバイト以下のメモリしか必要としないと言われています。このレベルであればMS-DOSマシンでも十分登載可能でしょう。SNMPでも70Kバイトから80Kバイトのメモリを必要としますし、通常のCMIPでは数百Kバイトが必要となりますので、魅力的なアプローチであると思われます。

＜CMOLの特徴(欠点)＞
ところがCMOLには大きな欠点があります。それはCMOLがデータリンク層での実装ですので、ルーティングができないことです。大きなネットワークでルーティングができないのは致命的ですが、OSIルータがCMOLの転送をサポートすることによる解決が期待されています。
CMOLの実際の導入には他にもソフトウェアに絡んだ問題等種々あるようですが、IEEEでの規格化が進んでいますので注目しておく必要があるでしょう。

SNMPv2

SNMPでは管理データを収集する時に多数のパケットのやりとりが発生し、ネットワークの有効利用率が低下することについては既に述べましたが、SNMPv2ではこれを改善するためにGetBulkRequestというコマンドが追加になりました。このコマンドを利用すればSNMPにおけるGetNextRequestを使用したトライ＆エラー型のデータ収集のかわりに大量データの一括収集が可能となり、管理データパケットによるネットワーク利用率の低下が緩和されます。

不要なパケットのやりとりを防ぐという観点では、GetResponseにも改善が見られます。SNMPでは管理オブジェクトの複数のインスタンスを検索した場合、その中の一つでもエラーが発生すると全体がダメになっていましたが、SNMPv2ではエラーが発生しなかったインスタンスは有効であると同時に、エラーが発生したインスタンスではインスタンス毎にエラーコードが通知される様になりました。

SNMPではエラーが複数発生した場合にはエラーが発生したインスタンスの特定が困難ですが、再検索の際にはエラー要因を排除した上でGetRequestを発行しなければならないというジレンマがあります。これはSNMPではトライ＆エラー方式でしか解決できませんので、結果として余分なトラフィックが発生してしまう訳です。

SNMPv2ではマネージャ間通信用のコマンドとしてInformRequestも新たにサポートされました。このコマンドを使用すれば、サブマネージャを配置して階層的な分散管理システムの構築が可能になります。また、セキュリティ機能のサポートも大きな特徴です。SNMPv2ではMIBは、３つのグループに分けて考えられています(表6)。

表6 SNMPv2のMIBのグループ分け

SNMPv2とSNMPとはPDUは上位互換ですが、セキュリティ機能に関連してメッセージ形式が変更され、パケットとしての互換性はありませんので注意が必要です(図12,13)。

図12 SNMPv2 メッセージ構成

図13 SNMPv2 のPDUの構成

ＳＮＭＰを廃止して一挙にSNMPv2へ移行するとことは不可能ですので、まずはSNMPとSNMPv2の両方のエージェントをサポートしたマネージャを登場させ、順次移行していく形態が考えられています。

SNMPはあくまでもネットワーク管理のためのプロトコルですので、実際のネットワーク管理のためには何らかのネットワーク管理ソフトを購入しなければなりません。
ネットワーク管理ソフトは管理アプリケーションまで含んだパッケージ型と、アプリケーション開発のためのプラットフォーム及びそのプラットフォーム向けの管理アプリケーションに大別できます。
最近はプラットフォーム型をベースに管理アプリケーションを提供する形式が主流で、パソコン対応ではHP社のOpenView、ワークステーション対応ではSUN社のSunNet Managerがプラットフォームとして大きなシェアを占めています。

参考文献

1. "Internetworking with TCP/IP Volume I" DOUGLAS E. COMER, Prentice-Hall (邦訳:TCP/IPによるネットワーク構築、共立出版)
2. "The Simple Book" MARSHALL T. ROSE, Prentice-Hall (邦訳:TCP/IP ネットワーク管理入門、トッパン)
3. "Troubleshooting TCP/IP" MARK A. MILLER, Prentice-Hall
4. "SNMP Opens New Lines of Sight" Data Communication, Mar 21 1990
5. "Considering CMIP" Data Communication, Mar 21 1990
6. "SNMP Management Goes Down to the Wire" Data Communication, May 1992
7. "Can CMOL Cahllenge SNMP?" Data Communication, May 21 1992
8. "Proactive LAN Management" Data Communication, Mar 21 1993
9. "Coming Soon to a Network Near You (SNMP-2)" Data Communication, Nov 1992 (邦訳:日経コミュニケーション 1993.3.1)
10. "Network Management From the Ground Floor" Data Communication, Apr 1993
11. "A Management Framework" LAN Magazine, Apr 1993
12. RFC 1021: The High-Level Entity Management System (HEMS)
13. RFC 1022: The High-Level Entity Management Protocol (HEMP)
14. RFC 1028: A Simple Gateway Monitoring Protocol
15. RFC 1095: CMIP over TCP/IP (CMOT)
16. RFC 1155: Structure and Identification of Management Information (SMI)
17. RFC 1157: A Simple Network Management Protocol (SNMP)
18. RFC 1283: SNMP over OSI
19. RFC 1298: SNMP over IPX
20. RFC 1228: SNMP Distributed Program Interface
21. RFC 1352: SNMP Security Protocols
22. RFC 1156: Management Information Base (MIB-I)
23. RFC 1213: Managament Information Base (MIB-II)
24. RFC 1214: OSI Internet Management MIB
25. RFC 1230: IEEE 802.4 Token Bus MIB
26. RFC 1231: IEEE 802.5 Token Ring MIB
27. RFC 1243: Appletalk MIB
28. RFC 1271: RMON MIB
29. RFC 1285: FDDI MIB
30. RFC 1368: IEEE 802.3 Repeater MIB