RFC 1157 - 簡易ネットワーク管理プロトコル (SNMP)

ネットワーク作業部会 Request for Comments: 1157 廃止: RFC 1098

著者: J. Case (SNMP Research) M. Fedor (Performance Systems International) M. Schoffstall (Performance Systems International) J. Davin (MIT Laboratory for Computer Science)

日付: May 1990

1. 本文書の位置付け
2. はじめに
3. SNMP アーキテクチャ
3.1. アーキテクチャの目標
3.2. アーキテクチャの要素
3.2.1. 管理情報の範囲
3.2.2. 管理情報の表現
3.2.3. 管理情報に対してサポートされる操作
3.2.4. プロトコル交換の形式と意味
3.2.5. 管理関係の定義
3.2.6. 管理対象オブジェクト参照の形式と意味
3.2.6.1. 曖昧な MIB 参照の解決
3.2.6.2. MIB バージョン間の参照の解決
3.2.6.3. オブジェクトインスタンスの識別
3.2.6.3.1. ifTable オブジェクト型の名前
3.2.6.3.2. atTable オブジェクト型の名前
3.2.6.3.3. ipAddrTable オブジェクト型の名前
3.2.6.3.4. ipRoutingTable オブジェクト型の名前
3.2.6.3.5. tcpConnTable オブジェクト型の名前
3.2.6.3.6. egpNeighTable オブジェクト型の名前
4. プロトコル仕様
4.1. 手順の要素
4.1.1. 共通構造
4.1.2. GetRequest-PDU
4.1.3. GetNextRequest-PDU
4.1.3.1. 表走査の例
4.1.4. GetResponse-PDU
4.1.5. SetRequest-PDU
4.1.6. Trap-PDU
4.1.6.1. coldStart Trap
4.1.6.2. warmStart Trap
4.1.6.3. linkDown Trap
4.1.6.4. linkUp Trap
4.1.6.5. authenticationFailure Trap
4.1.6.6. egpNeighborLoss Trap
4.1.6.7. enterpriseSpecific Trap
5. 定義
6. 謝辞
7. 参考文献
8. セキュリティに関する考慮事項
9. 著者の連絡先

1. 本文書の位置付け

この RFC は RFC 1098 の再リリースであり、「このメモのステータス」セクションが変更され、さらにいくつかの小さな誤植が修正されています。このメモは、論理的にリモートのユーザーがネットワーク要素の管理情報を検査または変更できる簡単なプロトコルを定義します。特に、管理情報ベースとともに管理情報の構造を説明する付随メモとともに、これらの文書は、TCP/IP ベースのインターネット、特にインターネットを管理するためのシンプルで実行可能なアーキテクチャとシステムを提供します。

インターネット活動委員会は、すべての IP および TCP 実装をネットワーク管理可能にすることを推奨しています。これは、インターネット MIB (RFC-1156) と、推奨される 2 つの管理プロトコル SNMP (RFC-1157) または CMOT (RFC-1095) のうちの少なくとも 1 つの実装を意味します。現時点では、SNMP は完全なインターネット標準であり、CMOT はドラフト標準であることに注意してください。この標準の適用可能性に関する詳細情報については、ホストおよびゲートウェイの要件 RFC も参照してください。

標準インターネットプロトコルの現状と状況に関する最新情報については、「IAB 公式プロトコル標準」RFC の最新版を参照してください。

このメモの配布は無制限です。

2. はじめに

RFC 1052、インターネットネットワーク管理標準の開発に関する IAB 勧告 [1] で報告されているように、TCP/IP ベースのインターネットのネットワーク管理に対する 2 つの側面からの戦略が実施されました。短期的には、インターネットコミュニティのノードを管理するために簡易ネットワーク管理プロトコル (SNMP) が使用されることになりました。長期的には、OSI ネットワーク管理フレームワークの使用が検討される予定でした。管理情報を定義するために 2 つの文書が作成されました。管理情報の構造 (SMI) [2] を定義した RFC 1065 と、管理情報ベース (MIB) [3] を定義した RFC 1066 です。これらのドキュメントはどちらも、SNMP および OSI ネットワーク管理フレームワークの両方と互換性があるように設計されています。

この戦略は短期的には非常に成功しました。インターネットベースのネットワーク管理テクノロジは、数か月以内に研究コミュニティと商業コミュニティの両方で実用化されました。この結果、インターネットコミュニティの一部がタイムリーにネットワーク管理可能になりました。

RFC 1109、Report of the Second Ad Hoc Network Management Review Group [4] で報告されているように、SNMP と OSI ネットワーク管理フレームワークの要件は予想よりも異なっていました。そのため、SMI/MIB と両方のフレームワーク間の互換性の要件は一時停止されました。この措置により、運用ネットワーク管理フレームワークである SNMP は、新しい MIB 項目を定義する文書を作成することで、インターネットコミュニティの新しい運用ニーズに対応できるようになりました。

IAB は、SNMP、SMI、および初期インターネット MIB を「推奨」ステータスの完全な「標準プロトコル」に指定しました。この措置により、IAB は、すべての IP および TCP 実装がネットワーク管理可能であること、およびネットワーク管理可能である実装が SMI、MIB、および SNMP を採用および実装することが期待されることを推奨します。

そのため、TCP/IP ベースのインターネットの現在のネットワーク管理フレームワークは以下で構成されます。 TCP/IP ベースのインターネットの管理情報の構造と識別。これは、MIB に含まれる管理オブジェクトが RFC 1155 [5] に規定されているように定義される方法を説明します。 TCP/IP ベースのインターネットのネットワーク管理のための管理情報ベース。RFC 1156 [6] に規定されている MIB に含まれる管理対象オブジェクトについて説明します。このメモに記載されているように、これらのオブジェクトの管理に使用されるプロトコルを定義する簡易ネットワーク管理プロトコル。

RFC 1052、インターネットネットワーク管理標準の開発に関する IAB 勧告 [1] で報告されているように、インターネットアクティビティ委員会は、インターネットエンジニアリングタスクフォース (IETF) に対し、ネットワーク管理の分野で 2 つの新しいワーキンググループを設立するよう指示しました。 1 つのグループは、管理情報ベース (MIB) に含まれる要素の詳細な仕様と定義を担当しました。もう 1 人は、ネットワークベンダーと運用コミュニティの短期的なニーズに対応し、MIB ワーキンググループの成果に合わせて、Simple Network Management Protocol (SNMP) の修正を定義する責任を負いました。

MIB ワーキンググループは 2 つのメモを作成しました。1 つは、MIB に含まれる管理オブジェクトによって使用される管理情報構造 (SMI) [2] を定義するものです。 2 番目のメモ [3] では、管理対象オブジェクトのリストが定義されています。

SNMP 拡張機能ワーキンググループの成果物はこのメモであり、MIB ワーキンググループの成果物との整合を図るために必要な初期 SNMP 定義 [7] への変更が組み込まれています。作業グループは「SNMP をシンプルに保つ必要性に非常に敏感である」という IAB の指示と一致するために、変更は最小限にする必要があります。このメモに反映されている SNMP への変更にはかなりの注意と議論が費やされていますが、結果として得られたプロトコルは、その前身である Simple Gateway Monitoring Protocol (SGMP) [8] と下位互換性がありません。プロトコルの構文は変更されましたが、元の哲学、設計上の決定、およびアーキテクチャはそのまま残ります。混乱を避けるために、このメモで説明されているプロトコルで使用するために、新しい UDP ポートが割り当てられています。

3. SNMP アーキテクチャ

SNMP アーキテクチャモデルには、ネットワーク管理ステーションとネットワーク要素のコレクションが暗黙的に含まれています。ネットワーク管理ステーションは、ネットワーク要素を監視および制御する管理アプリケーションを実行します。ネットワーク要素は、ホスト、ゲートウェイ、ターミナルサーバーなどのデバイスであり、ネットワーク管理ステーションから要求されたネットワーク管理機能の実行を担当する管理エージェントを備えています。 Simple Network Management Protocol (SNMP) は、ネットワーク管理ステーションとネットワーク要素内のエージェントの間で管理情報を通信するために使用されます。

3.1. アーキテクチャの目標

SNMP は、管理エージェント自体によって実現される管理機能の数と複雑さを明示的に最小限に抑えます。この目標は、少なくとも 4 つの点で魅力的です。

それに応じて、プロトコルをサポートするために必要な管理エージェントソフトウェアの開発コストも削減されます。
それに応じて、リモートでサポートされる管理機能の度合いも増加し、それによって管理タスクにおいてインターネットリソースを最大限に活用できるようになります。
それに応じて、リモートでサポートされる管理機能の度合いが増加し、それによって管理ツールの形式と洗練度に対する制限が最小限に抑えられます。
簡素化された一連の管理機能は、ネットワーク管理ツールの開発者によって容易に理解され、使用されます。

このプロトコルの 2 番目の目標は、監視と制御の機能パラダイムが、ネットワークの運用と管理の予期しない追加の側面に対応できるように十分に拡張可能であることです。

3 番目の目標は、アーキテクチャが特定のホストまたは特定のゲートウェイのアーキテクチャおよびメカニズムから可能な限り独立していることです。

3.2. アーキテクチャの要素

SNMP アーキテクチャは、次の観点からネットワーク管理問題の解決策を明確に示します。

プロトコルによって通信される管理情報の範囲、
プロトコルによって伝達される管理情報の表現、
プロトコルがサポートする管理情報の操作、
管理主体間の交流の形態と意義、
管理体間の管理上の関係の定義、および
管理情報への参照の形式と意味。

3.2.1. 管理情報の範囲

SNMP の操作によって伝達される管理情報の範囲は、インターネット標準 MIB で定義されているか、インターネット標準 SMI [5] で規定されている規則に従って他の場所で定義されているすべての非集約オブジェクトタイプのインスタンスによって表されるものとまったく同じです。

MIB での集約オブジェクトタイプのサポートは、SMI に準拠するために必須ではなく、SNMP によって実現されるものでもありません。

3.2.2. 管理情報の表現

SNMP の操作によって伝達される管理情報は、SMI の非集計型の定義に指定されている ASN.1 言語 [9] のサブセットに従って表現されます。

SGMP は、ASN.1 言語の明確に定義されたサブセットを使用する規則を採用しました [9]。 SNMP は、管理対象オブジェクトの記述と、それらのオブジェクトの管理に使用されるプロトコルデータユニットの記述に、ASN.1 の適度に複雑なサブセットを利用することで、この伝統を継続および拡張しています。さらに、OSI ベースのネットワーク管理プロトコルへの最終的な移行を容易にしたいという要望により、インターネット標準の管理情報構造 (SMI) [5] および管理情報ベース (MIB) [6] が ASN.1 言語で定義されました。 ASN.1 言語の使用は、以前の取り組み、特に SGMP での ASN.1 の使用が成功したことによって一部促進されました。 SMI の一部である ASN.1 の使用に関する制限は、SGMP の経験によって支持され検証されたシンプルさに貢献します。また、簡素化のために、SNMP は ASN.1 [10] の基本的なエンコード規則のサブセットのみを使用します。つまり、すべてのエンコーディングは固定長形式を使用します。さらに、許容される場合は常に、コンストラクターエンコーディングではなく非コンストラクターエンコーディングが使用されます。この制限は、トップレベルのプロトコルデータユニットとそれに含まれるデータオブジェクトの両方について、ASN.1 エンコードのすべての側面に適用されます。

3.2.3. 管理情報に対してサポートされる操作

SNMP は、すべての管理エージェント機能を変数の変更または検査としてモデル化します。したがって、論理的にリモートのホスト上のプロトコルエンティティ (おそらくネットワーク要素自体) は、変数を取得 (取得) または変更 (設定) するために、ネットワーク要素に常駐する管理エージェントと対話します。この戦略には、少なくとも 2 つのプラスの結果があります。

これには、管理エージェントによって実現される重要な管理機能の数が 2 つに制限されるという効果があります。1 つは指定された構成またはその他のパラメータに値を割り当てる操作で、もう 1 つはそのような値を取得する操作です。
この決定の 2 番目の効果は、プロトコル定義に命令型管理コマンドのサポートを導入することを回避できることです。そのようなコマンドの数は実際には増え続けており、そのようなコマンドのセマンティクスは一般に任意に複雑になっています。

SNMP に暗黙的に含まれる戦略は、重要な詳細レベルでのネットワーク状態の監視は、主に監視センター側で適切な情報をポーリングすることによって実現されるということです。限られた数の迷惑メッセージ (トラップ) によって、ポーリングのタイミングと焦点が決まります。迷惑メッセージの数を制限することは、ネットワーク管理機能によって生成されるトラフィック量を簡素化し、最小限に抑えるという目標と一致します。

明示的にサポートされる一連の管理機能から命令型コマンドが除外されても、望ましい管理エージェントの動作が妨げられることはほとんどありません。現在、ほとんどのコマンドは、何らかのパラメータの値を設定するか、そのような値を取得するリクエストであり、現在サポートされているいくつかの命令型コマンドの機能は、この管理モデルによって非同期モードに簡単に対応できます。このスキームでは、命令的コマンドは、その後必要なアクションをトリガーするパラメーター値の設定として実現される可能性があります。たとえば、「再起動コマンド」を実装するのではなく、システムが再起動するまでの秒数を示すパラメータを設定するだけでこのアクションを呼び出すことができます。

3.2.4. プロトコル交換の形式と意味

SNMP では、管理エンティティ間の管理情報の通信は、プロトコルメッセージの交換によって実現されます。これらのメッセージの形式と意味は、以下のセクション 4 で定義されます。

管理エージェントの複雑さを最小限に抑えるという目標と一致して、SNMP メッセージの交換には信頼性の低いデータグラムサービスのみが必要であり、すべてのメッセージは単一のトランスポートデータグラムによって完全かつ独立して表現されます。この文書では UDP プロトコル [11] を介したメッセージの交換を指定していますが、SNMP のメカニズムは一般に、さまざまなトランスポートサービスでの使用に適しています。

3.2.5. 管理関係の定義

SNMP アーキテクチャでは、プロトコルに参加するエンティティ間のさまざまな管理関係が認められます。管理ステーションに常駐するエンティティと、SNMP を使用して相互に通信するネットワーク要素は、SNMP アプリケーションエンティティと呼ばれます。 SNMP を実装し、SNMP アプリケーションエンティティをサポートするピアプロセスは、プロトコルエンティティと呼ばれます。

SNMP エージェントと SNMP アプリケーションエンティティの任意のセットの組み合わせは、SNMP コミュニティと呼ばれます。各 SNMP コミュニティは、オクテットの文字列によって名前が付けられます。これは、そのコミュニティのコミュニティ名と呼ばれます。

SNMP アプリケーションエンティティによって発信され、そのメッセージのコミュニティコンポーネントによって指定された SNMP コミュニティに実際に属している SNMP メッセージは、本物の SNMP メッセージと呼ばれます。 SNMP メッセージが特定の SNMP コミュニティに対する本物の SNMP メッセージとして識別される一連のルールは、認証スキームと呼ばれます。 1 つ以上の認証スキームに従って本物の SNMP メッセージを識別する機能の実装は、認証サービスと呼ばれます。

SNMP アプリケーションエンティティ間の管理関係を効果的に管理するには、(暗号化またはその他の技術を使用して) 本物の SNMP メッセージを高い確実性で識別できる認証サービスが必要であることは明らかです。一部の SNMP 実装では、すべての SNMP メッセージを本物の SNMP メッセージとして識別する簡単な認証サービスのみをサポートしたい場合があります。

ネットワーク要素の場合、その要素に関連する MIB 内のオブジェクトのサブセットは、SNMP MIB ビューと呼ばれます。 SNMP MIB ビューで表されるオブジェクトタイプの名前は、オブジェクトタイプの名前空間の単一のサブツリーに属する必要はないことに注意してください。

集合 { READ-ONLY, READ-WRITE } の要素は、SNMP アクセスモードと呼ばれます。

SNMP アクセスモードと SNMP MIB ビューの組み合わせは、SNMP コミュニティプロファイルと呼ばれます。 SNMP コミュニティプロファイルは、指定された MIB ビュー内の変数に対する指定されたアクセス権限を表します。特定の SNMP コミュニティプロファイルの MIB ビュー内のすべての変数について、その変数へのアクセスは、次の規則に従ってプロファイルによって表されます。

前記変数が「Access:」が「none」の MIB で定義されている場合、その変数はどの演算子のオペランドとしても使用できません。
前記変数が「読み取り/書き込み」または「書き込み専用」の「アクセス:」を使用して MIB で定義されており、指定されたプロファイルのアクセスモードが READ-WRITE である場合、その変数は get、set、およびトラップ操作のオペランドとして使用できます。
それ以外の場合、変数は get 操作およびトラップ操作のオペランドとして使用できます。
「書き込み専用」変数が get 操作またはトラップ操作に使用されるオペランドである場合、変数に指定される値は実装固有です。

SNMP コミュニティと SNMP コミュニティプロファイルの組み合わせは、SNMP アクセスポリシーと呼ばれます。アクセスポリシーは、指定された SNMP コミュニティの SNMP エージェントによってそのコミュニティの他のメンバーに提供される、指定されたコミュニティプロファイルを表します。 SNMP アプリケーションエンティティ間のすべての管理関係は、SNMP アクセスポリシーの観点からアーキテクチャ的に定義されます。

すべての SNMP アクセスポリシーについて、指定された SNMP コミュニティの SNMP エージェントが存在するネットワーク要素が、指定されたプロファイルの MIB ビューが関係するネットワーク要素ではない場合、そのポリシーは SNMP プロキシアクセスポリシーと呼ばれます。プロキシアクセスポリシーに関連付けられた SNMP エージェントは、SNMP プロキシエージェントと呼ばれます。プロキシアクセスポリシーを不用意に定義すると管理ループが発生する可能性がありますが、プロキシポリシーを慎重に定義すると、少なくとも次の 2 つの点で役立ちます。

これにより、管理プロトコルやトランスポートプロトコルを使用してアドレス指定できないネットワーク要素の監視と制御が可能になります。つまり、プロキシエージェントは、管理ステーションが、モデム、マルチプレクサ、および異なる管理フレームワークをサポートするその他のデバイスなどのデバイスを含むすべてのネットワーク要素に一貫した管理フレームワークを適用できるようにするプロトコル変換機能を提供する場合があります。
これにより、ネットワーク要素が複雑なアクセス制御ポリシーから保護される可能性があります。たとえば、プロキシエージェントは、ネットワーク要素の複雑さを増すことなく、MIB 内の変数の多様なサブセットにさまざまな管理ステーションからアクセスできるようにする高度なアクセス制御を実装できます。

例として、図 1 は、管理ステーション、プロキシエージェント、および管理エージェントの間の関係を示しています。この例では、プロキシエージェントは、一連の管理エージェントと標準的な管理関係を持つ、ある管理ドメインの通常のインターネットネットワークオペレーションセンター (INOC) であると想定されています。

   +------------------+       +----------------+      +----------------+
   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
   |                  |       |                |      |                |
   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
   |                  |       |                |      |                |
   +------------------+       +----------------+      +----------------+
          /|\                      /|\                     /|\
           |                        |                       |
           |                        |                       |
           |                       \|/                      |
           |               +-----------------+              |
           +-------------->| Region #3 INOC  |<-------------+
                           |                 |
                           |Domain=Region #3 |
                           |CPU=super-mini-2 |
                           |PCommunity=pub,  |
                           |         slate   |
                           |DCommunity=secret|
           +-------------->|                 |<-------------+
           |               +-----------------+              |
           |                       /|\                      |
           |                        |                       |
           |                        |                       |
          \|/                      \|/                     \|/
   +-----------------+     +-----------------+       +-----------------+
   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
   +-----------------+     +-----------------+       +-----------------+

Domain: 要素の管理ドメイン PCommunity: プロキシエージェントを使用するコミュニティの名前 DCommunity: 直接のコミュニティの名前

図 1 ネットワーク管理構成の例

3.2.6. 管理対象オブジェクト参照の形式と意味

SMI では、準拠した管理プロトコルアドレスの定義が必要です。

あいまいな MIB 参照の解決、
複数の MIB バージョンが存在する場合の MIB 参照の解像度、および
MIB で定義されたオブジェクトタイプの特定のインスタンスの識別。

3.2.6.1. 曖昧な MIB 参照の解決

SNMP 操作のスコープは概念的には単一のネットワーク要素に関連するオブジェクトに限定されており、MIB オブジェクトへのすべての SNMP 参照は（暗黙的または明示的に）一意の変数名によって行われるため、MIB で定義されたオブジェクトタイプへの SNMP 参照がそのタイプの複数のインスタンスに解決される可能性はありません。

3.2.6.2. MIB バージョン間の参照の解決

SNMP 操作によって参照されるオブジェクトインスタンスは、まさに操作リクエストの一部として指定されたもの、または (get-next 操作の場合) MIB 全体におけるその直接の後続のものです。特に、インターネット標準 MIB のあるバージョンの一部としてのオブジェクトへの参照は、要求された操作が get-next であり、指定されたオブジェクト名がインターネット標準 MIB の前記バージョンの一部として提示されるすべてのオブジェクトの名前の中で辞書順に最後にある場合を除き、インターネット標準 MIB の前記バージョンの一部ではないオブジェクトには解決されません。

3.2.6.3. オブジェクトインスタンスの識別

MIB のすべてのオブジェクトタイプの名前は、インターネット標準の MIB、または SMI の命名規則に準拠する他のドキュメントで明示的に定義されます。 SMI では、適合管理プロトコルが、特定のネットワーク要素のオブジェクトタイプの個々のインスタンスを識別するためのメカニズムを定義することを要求しています。

MIB で定義されたオブジェクトタイプの各インスタンスは、SNMP 操作で「変数名」と呼ばれる一意の名前によって識別されます。一般に、SNMP 変数の名前は、x.y 形式の OBJECT IDENTIFIER です。ここで、x は MIB で定義された非集約オブジェクトタイプの名前であり、y は、名前付きオブジェクトタイプに固有の方法で目的のインスタンスを識別する OBJECT IDENTIFIER フラグメントです。

この命名戦略では、GetNextRequest-PDU のセマンティクス (セクション 4 を参照) を最大限に活用できます。これは、MIB で知られているすべての変数名の辞書順で連続するように、関連する変数の名前が割り当てられるためです。

オブジェクトインスタンスのタイプ固有の名前付けは、オブジェクトタイプの多数のクラスに対して以下で定義されます。次の命名規則が適用されないオブジェクトタイプのインスタンスは、x.0 形式のオブジェクト識別子によって名前が付けられます。ここで、x は MIB 定義内のオブジェクトタイプの名前です。

たとえば、変数 sysDescr のインスタンスを識別したいとします。sysDescr のオブジェクトクラスは次のとおりです。

             iso org dod internet mgmt mib system sysDescr
              1   3   6     1      2    1    1       1

したがって、オブジェクトタイプ x は、インスタンスサブ識別子 0 が追加された 1.3.6.1.2.1.1.1 になります。つまり、1.3.6.1.2.1.1.1.0 は、sysDescr の唯一のインスタンスを識別します。

3.2.6.3.1. ifTable オブジェクト型の名前

サブネットインターフェイスの名前 s は、i 形式の OBJECT IDENTIFIER 値です。ここで、i には、s に関連付けられた ifIndex オブジェクトタイプのインスタンスの値が入ります。

オブジェクトタイプ t ごとに、定義名 n のプレフィックス ifEntry が付いており、t のインスタンス i は、n.s という形式の OBJECT IDENTIFIER によって名前が付けられます。s は、i が情報を表すサブネットインターフェイスの名前です。

たとえば、インターフェイス 2 に関連付けられた変数 ifType のインスタンスを識別したいとします。したがって、ifType.2 は目的のインスタンスを識別します。

3.2.6.3.2. atTable オブジェクト型の名前

AT キャッシュされたネットワークアドレスの名前 x は、1.a.b.c.d 形式の OBJECT IDENTIFIER です。ここで、a.b.c.d は、x に関連付けられた atNetAddress オブジェクトタイプの値 (おなじみの「ドット」表記) です。

アドレス変換同等の名前 e は、s.w 形式の OBJECT IDENTIFIER 値です。s は e に関連付けられた atIndex オブジェクトタイプのインスタンスの値であり、w は e に関連付けられた AT キャッシュネットワークアドレスの名前です。オブジェクトタイプ t ごとに、定義名 n のプレフィックス atEntry が付いており、t のインスタンス i は、n.y 形式の OBJECT IDENTIFIER によって名前が付けられます。ここで、y は、i が情報を表すアドレス変換同等の名前です。

たとえば、89.1.1.42 の IP アドレスとインターフェイス 3 に関連付けられたアドレス変換テーブル (ARP キャッシュ) 内のエントリの物理アドレスを見つけたいとします。したがって、atPhysAddress.3.1.89.1.1.42 は目的のインスタンスを識別します。

3.2.6.3.3. ipAddrTable オブジェクト型の名前

IP アドレス指定可能なネットワーク要素の名前 x は、a.b.c.d 形式の OBJECT IDENTIFIER であり、a.b.c.d は、x に関連付けられた ipAdEntAddr オブジェクトタイプのインスタンスの値 (おなじみの「ドット」表記) になります。

オブジェクトタイプ t ごとに、定義名 n のプレフィックス ipAddrEntry が付いており、t のインスタンス i は、n.y 形式の OBJECT IDENTIFIER によって名前が付けられます。ここで、y は、i が情報を表す IP アドレス指定可能なネットワーク要素の名前です。

たとえば、IP アドレス 89.1.1.42 に関連付けられた IP インターフェイステーブル内のエントリのネットワークマスクを見つけたいとします。したがって、ipAdEntNetMask.89.1.1.42 は目的のインスタンスを識別します。

3.2.6.3.4. ipRoutingTable オブジェクト型の名前

IP ルートの名前 x は、a.b.c.d 形式の OBJECT IDENTIFIER であり、a.b.c.d は、x に関連付けられた ipRouteDest オブジェクトタイプのインスタンスの値 (おなじみの「ドット」表記) になります。

オブジェクトタイプ t ごとに、定義名 n のプレフィックス ipRoutingEntry が付いており、t のインスタンス i は、n.y 形式の OBJECT IDENTIFIER によって名前が付けられます。ここで、y は、i が情報を表す IP ルートの名前です。

たとえば、89.1.1.42 の宛先に関連付けられた IP ルーティングテーブル内のエントリのネクストホップを見つけたいとします。したがって、ipRouteNextHop.89.1.1.42 は目的のインスタンスを識別します。

3.2.6.3.5. tcpConnTable オブジェクト型の名前

TCP 接続の名前 x は、a.b.c.d.e.f.g.h.i.j 形式の OBJECT IDENTIFIER であり、a.b.c.d は x に関連付けられた tcpConnLocalAddress オブジェクトタイプのインスタンスの値 (よく知られた「ドット」表記) で、f.g.h.i はそのインスタンスの値 (よく知られた「ドット」表記) になります。 x に関連付けられた tcpConnRemoteAddress オブジェクトタイプ。e は x に関連付けられた tcpConnLocalPort オブジェクトタイプのインスタンスの値、j は x に関連付けられた tcpConnRemotePort オブジェクトタイプのインスタンスの値になります。

オブジェクトタイプ t ごとに、定義名 n のプレフィックス tcpConnEntry が付いており、t のインスタンス i は、n.y 形式の OBJECT IDENTIFIER によって名前が付けられます。ここで、y は、i が情報を表す TCP 接続の名前です。

たとえば、TCP ポート 21 のローカルアドレス 89.1.1.42 と TCP ポート 2059 のリモートアドレス 10.0.0.51 の間の TCP 接続の状態を検索したいとします。したがって、tcpConnState.89.1.1.42.21.10.0.0.51.2059 は目的のインスタンスを識別します。

3.2.6.3.6. egpNeighTable オブジェクト型の名前

EGP ネイバーの名前 x は、a.b.c.d 形式の OBJECT IDENTIFIER であり、a.b.c.d は、x に関連付けられた egpNeighAddr オブジェクトタイプのインスタンスの値 (おなじみの「ドット」表記) になります。

オブジェクトタイプ t ごとに、定義名 n にプレフィックス egpNeighEntry が付き、t のインスタンス i は、n.y 形式の OBJECT IDENTIFIER によって名前が付けられます。ここで、y は、i が情報を表す EGP ネイバーの名前です。

たとえば、89.1.1.42 の IP アドレスの近隣状態を見つけたいとします。したがって、egpNeighState.89.1.1.42 は目的のインスタンスを識別します。

4. プロトコル仕様

ネットワーク管理プロトコルは、エージェントの MIB の変数を検査または変更できるアプリケーションプロトコルです。

プロトコルエンティティ間の通信はメッセージの交換によって実現され、各メッセージは ASN.1 の基本的なエンコード規則を使用して単一の UDP データグラム内で完全かつ独立して表現されます (セクション 3.2.2 で説明)。メッセージは、バージョン識別子、SNMP コミュニティ名、およびプロトコルデータユニット (PDU) で構成されます。プロトコルエンティティは、トラップを報告するメッセージを除くすべてのメッセージ (つまり、Trap-PDU を含むメッセージを除くすべてのメッセージ) について、プロトコルエンティティが関連付けられているホスト上の UDP ポート 161 でメッセージを受信します。トラップを報告するメッセージは、さらに処理するために UDP ポート 162 で受信される必要があります。このプロトコルの実装では、長さが 484 オクテットを超えるメッセージを受け入れる必要はありません。ただし、可能な限り実装でより大きなデータグラムをサポートすることをお勧めします。

SNMP のすべての実装は、GetRequest-PDU、GetNextRequest-PDU、GetResponse-PDU、SetRequest-PDU、および Trap-PDU の 5 つの PDU をサポートすることが必須です。

    RFC1157-SNMP DEFINITIONS ::= BEGIN

     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1155-SMI;

     -- top-level message

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }
     -- protocol data units

             PDUs ::=
                     CHOICE {
                         get-request
                             GetRequest-PDU,

                         get-next-request
                             GetNextRequest-PDU,

                         get-response
                             GetResponse-PDU,

                         set-request
                             SetRequest-PDU,

                         trap
                             Trap-PDU
                          }

     -- the individual PDUs and commonly used
     -- data types will be defined later

     END

4.1. 手順の要素

このセクションでは、SNMP を実装するプロトコルエンティティのアクションについて説明します。ただし、準拠した実装の内部アーキテクチャを制約するものではないことに注意してください。

以下のテキストでは、トランスポートアドレスという用語が使用されます。 UDP の場合、トランスポートアドレスは IP アドレスと UDP ポートで構成されます。 SNMP をサポートするために他のトランスポートサービスが使用される場合があります。このような場合、トランスポートアドレスの定義はそれに応じて行う必要があります。

メッセージを生成するプロトコルエンティティのトップレベルのアクションは次のとおりです。

まず、適切な PDU (GetRequest-PDU など) を ASN.1 オブジェクトとして構築します。
次に、この ASN.1 オブジェクトをコミュニティ名とともに、その送信元トランスポートアドレスと宛先トランスポートアドレスを、目的の認証スキームを実装するサービスに渡します。この認証サービスは、別の ASN.1 オブジェクトを返します。
次に、プロトコルエンティティは、コミュニティ名と結果の ASN.1 オブジェクトを使用して、ASN.1 メッセージオブジェクトを構築します。
この新しい ASN.1 オブジェクトは、ASN.1 の基本的なエンコード規則を使用してシリアル化され、トランスポートサービスを使用してピアプロトコルエンティティに送信されます。

同様に、メッセージを受信するプロトコルエンティティのトップレベルのアクションは次のとおりです。

受信データグラムの基本的な解析を実行して、ASN.1 メッセージオブジェクトに対応する ASN.1 オブジェクトを構築します。解析が失敗した場合、データグラムは破棄され、それ以上のアクションは実行されません。
次に、SNMP メッセージのバージョン番号を検証します。不一致がある場合、データグラムは破棄され、それ以上のアクションは実行されません。
次に、プロトコルエンティティは、ASN.1 メッセージオブジェクトで見つかったコミュニティ名とユーザーデータを、データグラムの送信元および宛先トランスポートアドレスとともに、必要な認証スキームを実装するサービスに渡します。このエンティティは別の ASN.1 オブジェクトを返すか、認証の失敗を通知します。後者の場合、プロトコルエンティティはこの失敗を認識し、（おそらく）トラップを生成し、データグラムを破棄し、それ以上のアクションは実行しません。
次に、プロトコルエンティティは、認証サービスから返された ASN.1 オブジェクトに対して基本的な解析を実行し、ASN.1 PDU オブジェクトに対応する ASN.1 オブジェクトを構築します。解析が失敗した場合、データグラムは破棄され、それ以上のアクションは実行されません。それ以外の場合は、名前付き SNMP コミュニティを使用して、適切なプロファイルが選択され、それに応じて PDU が処理されます。この処理の結果、メッセージが返された場合、応答メッセージの送信元トランスポートアドレスは、元の要求メッセージの送信先トランスポートアドレスと同一である必要があります。

4.1.1. 共通構造

プロトコルの 6 つの PDU タイプを紹介する前に、頻繁に使用される ASN.1 構造のいくつかを考慮することが適切です。

                  -- request/response information

                  RequestID ::=
                          INTEGER

                  ErrorStatus ::=
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4)
                              genErr(5)
                          }

                  ErrorIndex ::=
                          INTEGER

                  -- variable bindings

                  VarBind ::=
                          SEQUENCE {
                              name
                                  ObjectName,

                              value
                                  ObjectSyntax
                          }

                  VarBindList ::=
                          SEQUENCE OF
                              VarBind

RequestID は、未処理のリクエストを区別するために使用されます。 RequestID を使用すると、SNMP アプリケーションエンティティは受信応答を未処理の要求と関連付けることができます。信頼性の低いデータグラムサービスが使用されている場合、RequestID は、ネットワークによって複製されたメッセージを識別する簡単な手段も提供します。

ErrorStatus のゼロ以外のインスタンスは、リクエストの処理中に例外が発生したことを示すために使用されます。このような場合、ErrorIndex は、リスト内のどの変数が例外を引き起こしたかを示すことで追加情報を提供することがあります。

変数という用語は、管理対象オブジェクトのインスタンスを指します。変数バインディング (VarBind) は、変数の名前と変数の値の組み合わせを指します。 VarBindList は、変数名と対応する値の単純なリストです。一部の PDU は変数の名前のみを考慮し、その値は考慮しません (例: GetRequest-PDU)。この場合、バインディングの値部分はプロトコルエンティティによって無視されます。ただし、値の部分には有効な ASN.1 構文とエンコーディングが必要です。このようなバインディングの値部分には、ASN.1 値 NULL を使用することをお勧めします。

4.1.2. GetRequest-PDU

GetRequest-PDU の形式は次のとおりです。

                  GetRequest-PDU ::=
                      [0]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

GetRequest-PDU は、SNMP アプリケーションエンティティの要求があった場合にのみ、プロトコルエンティティによって生成されます。

GetRequest-PDU を受信すると、受信プロトコルエンティティは、以下のリストにある該当するルールに従って応答します。

variable-bindings フィールドで指定されたオブジェクトの名前が、該当する MIB ビューで get 操作に使用できるオブジェクトの名前と正確に一致しない場合、受信エンティティは受信メッセージの送信元へ同じ形式の GetResponse-PDU を送信します。ただし、error-status フィールドの値は noSuchName、error-index フィールドの値は受信メッセージ内の当該オブジェクト名コンポーネントのインデックスとします。
variable-bindings フィールドで名前が付けられたオブジェクトの場合、そのオブジェクトが集約型 (SMI で定義されている) である場合、受信側エンティティは、error-status フィールドの値が noSuchName であり、error-index フィールドの値が受信メッセージ内のオブジェクト名コンポーネントのインデックスであることを除いて、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。メッセージ。
以下で説明するように生成された GetResponse-PDU のサイズがローカル制限を超える場合、受信エンティティは、error-status フィールドの値が tooBig であり、error-index フィールドの値がゼロであることを除いて、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。
variable-bindings フィールドで名前が指定されたオブジェクトについて、前述の規則のいずれにも当てはまらない理由でオブジェクトの値を取得できない場合、受信側エンティティは、error-status フィールドの値が genErr であり、error-index フィールドの値が受信メッセージ内のオブジェクト名コンポーネントのインデックスであることを除き、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。メッセージ。

前述のルールがいずれも適用されない場合、受信プロトコルエンティティは、受信メッセージの変数バインディングフィールドで指定されたオブジェクトごとに、GetResponse-PDU の対応するコンポーネントがその変数の名前と値を表すように、受信メッセージの発信者に GetResponse-PDU を送信します。 GetResponse-PDU の error-status フィールドの値は noError で、error-index フィールドの値は 0 です。 GetResponse-PDU の request-id フィールドの値は、受信したメッセージの値です。

4.1.3. GetNextRequest-PDU

GetNextRequest-PDU の形式は、PDU タイプの表示を除き、GetRequest-PDU と同一です。 ASN.1 言語:

                  GetNextRequest-PDU ::=
                      [1]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

GetNextRequest-PDU は、SNMP アプリケーションエンティティの要求があった場合にのみ、プロトコルエンティティによって生成されます。

GetNextRequest-PDU を受信すると、受信プロトコルエンティティは、以下のリストにある該当するルールに従って応答します。

variable-bindings フィールド内のいずれかのオブジェクト名について、その名前が辞書編集上、関連する MIB ビューで取得操作に使用できるオブジェクトの名前より前にない場合、受信側エンティティは、error-status フィールドの値が noSuchName であることを除き、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。 error-index フィールドは、受信メッセージ内のオブジェクト名コンポーネントのインデックスです。
以下で説明するように生成された GetResponse-PDU のサイズがローカル制限を超える場合、受信エンティティは、error-status フィールドの値が tooBig であり、error-index フィールドの値がゼロであることを除いて、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。
variable-bindings フィールドで指定されたオブジェクトについて、前述のどの規則にも該当しない理由により、そのオブジェクトの辞書順の後続オブジェクトの値を取得できない場合、受信エンティティは受信メッセージの送信元へ同じ形式の GetResponse-PDU を送信します。ただし、error-status フィールドの値は genErr、error-index フィールドの値は受信メッセージ内の当該オブジェクト名コンポーネントのインデックスとします。

前述のルールがいずれも適用されない場合、受信プロトコルエンティティは、受信メッセージの発信者に GetResponse-PDU を送信します。これにより、受信メッセージの variable-bindings フィールドの名前ごとに、GetResponse-PDU の対応するコンポーネントが、関連する MIB ビューで取得操作に使用できるすべてのオブジェクトの名前の辞書編集順に、その名前を持つオブジェクトの名前と値が値とともに表示されます。指定されたコンポーネントの名前フィールドの、その値の直接の後継者。 GetResponse-PDU の error-status フィールドの値は noError であり、errorindex フィールドの値は 0 です。 GetResponse-PDU の request-id フィールドの値は、受信したメッセージの値です。

4.1.3.1. 表走査の例

GetNextRequest-PDU の重要な用途の 1 つは、MIB 内の情報の概念テーブルを横断することです。このタイプの SNMP メッセージのセマンティクスと、MIB 内のオブジェクトタイプの個々のインスタンスを識別するプロトコル固有のメカニズムにより、あたかも表形式の構成を享受しているかのように、MIB 内の関連オブジェクトにアクセスできます。

以下に示す SNMP 交換により、SNMP アプリケーションエンティティは、特定のネットワーク要素のルーティングテーブル内の各エントリの宛先アドレスとネクストホップゲートウェイを抽出する可能性があります。このルーティングテーブルに 3 つのエントリがあるとします。

         Destination                     NextHop         Metric

         10.0.0.99                       89.1.1.42       5
         9.1.2.3                         99.0.0.3        3
         10.0.0.51                       89.1.1.42       5

管理ステーションは、指定された OBJECT IDENTIFIER 値を要求された変数名として含む GetNextRequest-PDU を SNMP エージェントに送信します。

   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

SNMP エージェントは GetResponse-PDU で応答します。

                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
                         ( ipRouteMetric1.9.1.2.3 = 3 ))

管理ステーションは次のように続けます。

                 GetNextRequest ( ipRouteDest.9.1.2.3,
                         ipRouteNextHop.9.1.2.3,
                         ipRouteMetric1.9.1.2.3 )

SNMP エージェントは次のように応答します。

                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.51 = 5 ))

管理ステーションは次のように続けます。

                 GetNextRequest ( ipRouteDest.10.0.0.51,
                         ipRouteNextHop.10.0.0.51,
                         ipRouteMetric1.10.0.0.51 )

SNMP エージェントは次のように応答します。

                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.99 = 5 ))

管理ステーションは次のように続けます。

                 GetNextRequest ( ipRouteDest.10.0.0.99,
                         ipRouteNextHop.10.0.0.99,
                         ipRouteMetric1.10.0.0.99 )

テーブルにはそれ以上のエントリがないため、SNMP エージェントは、既知のオブジェクト名の辞書編集順で次にあるオブジェクトを返します。この応答は、ルーティングテーブルの終了を管理ステーションに通知します。

4.1.4. GetResponse-PDU

GetResponse-PDU の形式は、PDU タイプの表示を除き、GetRequest-PDU と同一です。 ASN.1 言語:

                  GetResponse-PDU ::=
                      [2]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status
                                  ErrorStatus,

                              error-index
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

GetResponse-PDU は、このドキュメントの他の場所で説明されているように、GetRequest-PDU、GetNextRequest-PDU、または SetRequest-PDU の受信時にのみプロトコルエンティティによって生成されます。

GetResponse-PDU を受信すると、受信側プロトコルエンティティはその内容を SNMP アプリケーションエンティティに提示します。

4.1.5. SetRequest-PDU

SetRequest-PDU の形式は、PDU タイプの表示を除き、GetRequest-PDU と同一です。 ASN.1 言語:

                  SetRequest-PDU ::=
                      [3]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

SetRequest-PDU は、SNMP アプリケーションエンティティの要求があった場合にのみ、プロトコルエンティティによって生成されます。

SetRequest-PDU を受信すると、受信側エンティティは、以下のリストにある該当するルールに従って応答します。

variable-bindings フィールドで名前が指定されたオブジェクトについて、そのオブジェクトが関連する MIB ビューでのセット操作に使用できない場合、受信側エンティティは、error-status フィールドの値が noSuchName であり、error-index フィールドの値が受信メッセージ内のオブジェクト名コンポーネントのインデックスであることを除いて、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。メッセージ。
variable-bindings フィールドで指定されたオブジェクトの場合、値フィールドの内容が、ASN.1 言語に従って、変数に必要な型、長さ、および値と一致しない場合、受信側エンティティは、error-status フィールドの値が badValue であることを除き、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。 error-index フィールドは、受信したメッセージ内のオブジェクト名のインデックスです。
以下で説明するように生成された Get Response タイプのメッセージのサイズがローカル制限を超える場合、受信エンティティは、error-status フィールドの値が tooBig であり、error-index フィールドの値がゼロであることを除いて、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。
variable-bindings フィールドで指定されたオブジェクトについて、前述の規則のいずれにも当てはまらない理由で、指定されたオブジェクトの値を変更できない場合、受信側エンティティは、error-status フィールドの値が genErr であり、error-index フィールドの値が受信メッセージ内のオブジェクト名コンポーネントのインデックスであることを除き、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。メッセージ。

前述のルールがいずれも当てはまらない場合、受信メッセージの variable-bindings フィールドで指定されたオブジェクトごとに、対応する値が変数に割り当てられます。 SetRequest-PDU で指定された各変数の割り当ては、同じメッセージで指定された他のすべての割り当てに関して同時に設定されたかのように実行される必要があります。

次に、受信エンティティは、生成されたメッセージの error-status フィールドの値が noError であり、error-index フィールドの値がゼロであることを除き、同じ形式の GetResponse-PDU を受信メッセージの発信者に送信します。

4.1.6. Trap-PDU

Trap-PDU の形式は次のとおりです。

     Trap-PDU ::=
         [4]

              IMPLICIT SEQUENCE {
                 enterprise          -- type of object generating
                                     -- trap, see sysObjectID in [5]
                     OBJECT IDENTIFIER,

                 agent-addr          -- address of object generating
                     NetworkAddress, -- trap

                 generic-trap        -- generic trap type
                     INTEGER {
                         coldStart(0),
                         warmStart(1),
                         linkDown(2),
                         linkUp(3),
                         authenticationFailure(4),
                         egpNeighborLoss(5),
                         enterpriseSpecific(6)
                     },

                 specific-trap     -- specific code, present even
                     INTEGER,      -- if generic-trap is not
                                   -- enterpriseSpecific

                 time-stamp        -- time elapsed between the last
                   TimeTicks,      -- (re)initialization of the network
                                   -- entity and the generation of the
                                      trap

                 variable-bindings   -- "interesting" information
                      VarBindList
             }

Trap-PDU は、SNMP アプリケーションエンティティの要求時にのみプロトコルエンティティによって生成されます。 SNMP アプリケーションエンティティが SNMP アプリケーションエンティティの宛先アドレスを選択する手段は実装固有です。

Trap-PDU を受信すると、受信側プロトコルエンティティはその内容を SNMP アプリケーションエンティティに提示します。 Trap-PDU の variable-bindings コンポーネントの重要性は実装に固有です。

generic-trap フィールドの値の解釈は次のとおりです。

4.1.6.1. coldStart Trap

coldStart(0) トラップは、エージェントの構成またはプロトコルエンティティの実装が変更される可能性があるように、送信側プロトコルエンティティが自身を再初期化していることを示します。

4.1.6.2. warmStart Trap

warmStart(1) トラップは、エージェント構成もプロトコルエンティティの実装も変更されないように、送信側プロトコルエンティティ自体が再初期化されていることを示します。

4.1.6.3. linkDown Trap

linkDown(2) トラップは、送信側プロトコルエンティティが、エージェントの構成で表される通信リンクの 1 つでの障害を認識したことを示します。

linkDown タイプの Trap-PDU には、variable-bindings の最初の要素として、影響を受けるインターフェイスの ifIndex インスタンスの名前と値が含まれます。

4.1.6.4. linkUp Trap

linkUp(3) トラップは、エージェントの構成で表される通信リンクの 1 つが起動したことを送信側プロトコルエンティティが認識したことを示します。

linkUp タイプの Trap-PDU には、variable-bindings の最初の要素として、影響を受けるインターフェイスの ifIndex インスタンスの名前と値が含まれます。

4.1.6.5. authenticationFailure Trap

authenticationFailure(4) トラップは、送信プロトコルエンティティが適切に認証されていないプロトコルメッセージのアドレスであることを示します。 SNMP の実装はこのトラップを生成できなければなりませんが、実装固有のメカニズムを通じてそのようなトラップの送信を抑制できなければなりません。

4.1.6.6. egpNeighborLoss Trap

egpNeighborLoss(5) トラップは、送信プロトコルエンティティが EGP ピアであった EGP ネイバーがダウンとしてマークされ、ピア関係が取得されなくなったことを示します。

egpNeighborLoss タイプの Trap-PDU には、variable-bindings の最初の要素として、影響を受けるネイバーの egpNeighAddr インスタンスの名前と値が含まれます。

4.1.6.7. enterpriseSpecific Trap

enterpriseSpecific(6) トラップは、送信側プロトコルエンティティが企業固有のイベントが発生したことを認識していることを示します。 specific-trap フィールドは、発生した特定のトラップを識別します。

5. 定義

     RFC1157-SNMP DEFINITIONS ::= BEGIN

      IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
              FROM RFC1155-SMI;

          -- top-level message

          Message ::=
                  SEQUENCE {
                      version          -- version-1 for this RFC
                          INTEGER {
                              version-1(0)
                          },

                      community        -- community name
                          OCTET STRING,

                      data             -- e.g., PDUs if trivial
                          ANY          -- authentication is being used
                  }

          -- protocol data units

          PDUs ::=
                  CHOICE {
                              get-request
                                  GetRequest-PDU,

                              get-next-request
                                  GetNextRequest-PDU,

                              get-response
                                  GetResponse-PDU,

                              set-request
                                  SetRequest-PDU,

                              trap
                                  Trap-PDU
                          }
          -- PDUs

          GetRequest-PDU ::=
              [0]
                  IMPLICIT PDU

          GetNextRequest-PDU ::=
              [1]
                  IMPLICIT PDU

          GetResponse-PDU ::=
              [2]
                  IMPLICIT PDU

          SetRequest-PDU ::=
              [3]
                  IMPLICIT PDU

          PDU ::=
                  SEQUENCE {
                     request-id
                          INTEGER,

                      error-status      -- sometimes ignored
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4),
                              genErr(5)
                          },

                      error-index       -- sometimes ignored
                         INTEGER,

                      variable-bindings -- values are sometimes ignored
                          VarBindList
                  }

          Trap-PDU ::=
              [4]
                 IMPLICIT SEQUENCE {
                      enterprise        -- type of object generating
                                        -- trap, see sysObjectID in [5]

                          OBJECT IDENTIFIER,
                      agent-addr        -- address of object generating
                          NetworkAddress, -- trap

                      generic-trap      -- generic trap type
                          INTEGER {
                              coldStart(0),
                              warmStart(1),
                              linkDown(2),
                              linkUp(3),
                              authenticationFailure(4),
                              egpNeighborLoss(5),
                              enterpriseSpecific(6)
                          },

                      specific-trap  -- specific code, present even
                          INTEGER,   -- if generic-trap is not
                                     -- enterpriseSpecific

                      time-stamp     -- time elapsed between the last
                          TimeTicks, -- (re)initialization of the
                                        network
                                     -- entity and the generation of the
                                        trap

                       variable-bindings -- "interesting" information
                          VarBindList
                  }

          -- variable bindings

          VarBind ::=
                  SEQUENCE {
                      name
                          ObjectName,

                      value
                          ObjectSyntax
                  }

         VarBindList ::=
                  SEQUENCE OF
                     VarBind

         END

6. 謝辞

このメモは、IETF SNMP Extensions ワーキンググループの影響を受けています。

      Karl Auerbach, Epilogue Technology
      K. Ramesh Babu, Excelan
      Amatzia Ben-Artzi, 3Com/Bridge
      Lawrence Besaw, Hewlett-Packard
      Jeffrey D. Case, University of Tennessee at Knoxville
      Anthony Chung, Sytek
      James Davidson, The Wollongong Group
      James R. Davin, MIT Laboratory for Computer Science
      Mark S. Fedor, NYSERNet
      Phill Gross, The MITRE Corporation
      Satish Joshi, ACC
      Dan Lynch, Advanced Computing Environments
      Keith McCloghrie, The Wollongong Group
      Marshall T. Rose, The Wollongong Group (chair)
      Greg Satz, cisco
      Martin Lee Schoffstall, Rensselaer Polytechnic Institute
      Wengyik Yeong, NYSERNet

7. 参考文献

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.

8. セキュリティに関する考慮事項

このメモでは、セキュリティの問題については説明しません。

9. 著者の連絡先

Jeffrey D. Case SNMP Research P.O. Box 8593 Knoxville, TN 37996-4800

電話: (615) 573-1434

Email: [email protected]

Mark Fedor Performance Systems International Rensselaer Technology Park 125 Jordan Road Troy, NY 12180

電話: (518) 283-8860

Email: [email protected]

Martin Lee Schoffstall Performance Systems International Rensselaer Technology Park 165 Jordan Road Troy, NY 12180

電話: (518) 283-8860

Email: [email protected] James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139

電話: (617) 253-6020

Email: [email protected]

目次​

1. 本文書の位置付け​

2. はじめに​

3. SNMP アーキテクチャ​

3.1. アーキテクチャの目標​

3.2. アーキテクチャの要素​

3.2.1. 管理情報の範囲​

3.2.2. 管理情報の表現​

3.2.3. 管理情報に対してサポートされる操作​

3.2.4. プロトコル交換の形式と意味​

3.2.5. 管理関係の定義​

3.2.6. 管理対象オブジェクト参照の形式と意味​

3.2.6.1. 曖昧な MIB 参照の解決​

3.2.6.2. MIB バージョン間の参照の解決​

3.2.6.3. オブジェクトインスタンスの識別​

3.2.6.3.1. ifTable オブジェクト型の名前​

3.2.6.3.2. atTable オブジェクト型の名前​

3.2.6.3.3. ipAddrTable オブジェクト型の名前​

3.2.6.3.4. ipRoutingTable オブジェクト型の名前​

3.2.6.3.5. tcpConnTable オブジェクト型の名前​

3.2.6.3.6. egpNeighTable オブジェクト型の名前​

4. プロトコル仕様​

4.1. 手順の要素​

4.1.1. 共通構造​

4.1.2. GetRequest-PDU​

4.1.3. GetNextRequest-PDU​

4.1.3.1. 表走査の例​

4.1.4. GetResponse-PDU​

4.1.5. SetRequest-PDU​

4.1.6. Trap-PDU​

4.1.6.1. coldStart Trap​

4.1.6.2. warmStart Trap​

4.1.6.3. linkDown Trap​

4.1.6.4. linkUp Trap​

4.1.6.5. authenticationFailure Trap​

4.1.6.6. egpNeighborLoss Trap​

4.1.6.7. enterpriseSpecific Trap​

5. 定義​

6. 謝辞​

7. 参考文献​

8. セキュリティに関する考慮事項​

9. 著者の連絡先​

目次

1. 本文書の位置付け

2. はじめに

3. SNMP アーキテクチャ

3.1. アーキテクチャの目標

3.2. アーキテクチャの要素

3.2.1. 管理情報の範囲

3.2.2. 管理情報の表現

3.2.3. 管理情報に対してサポートされる操作

3.2.4. プロトコル交換の形式と意味

3.2.5. 管理関係の定義

3.2.6. 管理対象オブジェクト参照の形式と意味

3.2.6.1. 曖昧な MIB 参照の解決

3.2.6.2. MIB バージョン間の参照の解決

3.2.6.3. オブジェクトインスタンスの識別

3.2.6.3.1. ifTable オブジェクト型の名前

3.2.6.3.2. atTable オブジェクト型の名前

3.2.6.3.3. ipAddrTable オブジェクト型の名前

3.2.6.3.4. ipRoutingTable オブジェクト型の名前

3.2.6.3.5. tcpConnTable オブジェクト型の名前

3.2.6.3.6. egpNeighTable オブジェクト型の名前

4. プロトコル仕様

4.1. 手順の要素

4.1.1. 共通構造

4.1.2. GetRequest-PDU

4.1.3. GetNextRequest-PDU

4.1.3.1. 表走査の例

4.1.4. GetResponse-PDU

4.1.5. SetRequest-PDU

4.1.6. Trap-PDU

4.1.6.1. coldStart Trap

4.1.6.2. warmStart Trap

4.1.6.3. linkDown Trap

4.1.6.4. linkUp Trap

4.1.6.5. authenticationFailure Trap

4.1.6.6. egpNeighborLoss Trap

4.1.6.7. enterpriseSpecific Trap

5. 定義

6. 謝辞

7. 参考文献

8. セキュリティに関する考慮事項

9. 著者の連絡先