3. The SNMP Architecture

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 は目的のインスタンスを識別します。

Return: RFC 1157 Home

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 オブジェクト型の名前​