Simple Network Management Protocol

巨大なネットワーク上で、数多くの機器の状態を把握するためには、この規格化されたプロトコルを使い、機器からの情報を集めて監視や制御を行う。コンピュータ等の能動的な機器以外にもルータやハブなどもSNMPを使って監視することが出来る。

SNMPに関する最初のRFCは1988年に登場した。

プロトコルを管理情報の構造から分離することにより、SNMPはネットワーク上の非常に多種多様なサブシステムを容易にモニターできるようになった。それはOSI参照モデルの全ての層を超えて、データベースやe-mail、J2EE参照モデルなどにまでその範囲を拡大している。

SNMPのフレームワークの構造は、マスターエージェント、サブエージェント、マネージャからなる3つの主要な要素から構成されている。

マスターエージェント

IPアドレスによって特定可能なネットワーク上のノード上のシステムで、ルータやホストといったようなものがマスターエージェントと呼ばれる。典型的なマスターエージェントはプロトコルの構文解析や出力の整形などを行うのみである。

サブエージェント

あるシステム内に複数の管理可能なサブシステムが含まれている場合、マスターエージェントは受け取った要求を、一つまたは複数のサブエージェントに渡す。各サブエージェントはそれぞれがサブシステムに対応していて、サブシステムに対する監視や管理のインタフェースとなっている。マスターエージェントとサブエージェントが外部から見たときに単純な一つのエージェントとみなせるような場合には、それらの役割はまとめて扱われることもある。

マネージャ

クライアント・サーバ型で言うところのクライアントに相当する。管理者やアプリケーションによる管理操作はここからリクエストとして送出される他、各エージェントからのトラップを受信したりする。

Summarize Timeline Fact Check

SNMP v1 (SNMP version 1) で、次の5つのProtocol Data Unit (PDU) が定義されている。

• GET REQUEST: 一部の管理情報を取得するときに使用する
• GETNEXT REQUEST: 連続する管理情報を取得するときに使用する
• GET RESPONSE
• SET REQUEST: 管理するサブシステムに対して変更を加えるときに使用する
• TRAP (トラップ): 管理するサブシステムに関する警告や非同期イベントの通知に使用する

それ以降のバージョンで、次のPDU が追加されている。

• GETBULK REQUEST: 高速に複数の管理情報を取得するときに使用する
• INFORM: マネージャからマネージャへの通信するときに使用する

SNMP は、OSI参照モデルのアプリケーション層 (第7層) に相当する。

SNMP は、下位プロトコルとしてUDP を使用する。一般的に、エージェントが161番ポートを、マネージャが162番ポートを使用している。

管理対象の機器をエージェントと呼ぶ (スイッチ、ルータ、ホストなど)。

エージェントは、その役割から次の2つに分類される。

1. マスター・エージェント
2. サブ・エージェント

マスター・エージェントは、1つ以上のサブ・エージェントを監視することができる。

エージェントは、Management Information Base(MIB; 管理情報ベース) と呼ばれる一種のデータベースを持つ。

ネットワークを管理するシステムをマネージャ (管理ステーション) と呼ぶ。これはクライアント・サーバ型のクライアントに相当する。

マネージャは、主に次のような管理操作を行う。

• エージェントへリクエスト (要求) を送信し、そのレスポンス (応答) を受信する
• エージェントからトラップ (通知) を受信する

SNMP v1 は、主に次のRFCで定義されている。

• RFC 1065 - TCP/IPネットワーク上の管理情報の種類と構造
• RFC 1066 - TCP/IPネットワーク管理のためのMIBの最初の定義
• RFC 1156 - RFC1066の改訂
• RFC 1158 - MIB-II と呼ばれるネットワーク機器の持つべき標準データ構造の定義
• RFC 1213 - RFC1158の改訂
• RFC 1067 - 簡易ネットワーク管理プロトコル (SNMP)の最初の定義（現在はobsoleted）
• RFC 1157 - 簡易ネットワーク管理プロトコル (SNMP) RFC1067を置き換えてこちらが現在の標準

SNMP v1 は、パスワードに相当するコミュニティ文字列がクリア・テキストで通信されるため、セキュリティの脆弱性が指摘されている。

SNMP v2、SNMP v2p (RFC 1441 - RFC 1452) は、機能性、セキュリティ、機密性が改善され、マネージャからマネージャへの通信をサポートしている。SNMP v2は、GETNEXT の代わりとしてGETBULK を導入した。しかし、SNMP v2 のセキュリティ・システムは複雑であり、広く採用されていない。

SNMP v2c (RFC 1901 - RFC 1908) は、論争の多かったSNMP v2 の新しいセキュリティ・モデルを採用する代わりに、SNMP v1 のコミュニティを改善している。このドラフト案がSNMP v2 のデファクトスタンダードとなっている。

SNMP v2u (RFC 1909 - RFC 1910) は、SNMP v2 の複雑さを受けないように、セキュリティに最大限の妥協を試みている。この変形はSNMP v2* として商品化され、SNMP v3 のセキュリティの枠組みとして採用されている。

SNMP v3 (RFC 3411 - RFC 3418, STD0062) は、SNMP の最新版である (2004年現在)。IETF は、SNMP v3 の登場によって旧式のSNMP が不要 (Obsolete) になると考えている。

実際にSNMP を実装するときは、複数のバージョンをサポートすることが多い (RFC 3584 参照)。

SNMPv3は以下の点でセキュリティレベルがSNMPv2cと比較して向上している。

• メッセージの完全性（メッセージが改ざんされていないかのチェック）
• 認証（HMAC-MD5やHMAC-SHAを使ったメッセージ送信元の認証）
• 暗号化（DESや3DES、ないしはAESによるメッセージの暗号化）

• 典型的なマスター・エージェントはプロトコルの構文解析や出力の整形などを行うのみである。
• マスター・エージェントとサブ・エージェントが外部から見たときに単純な一つのエージェントとみなせるような場合には、それらの役割はまとめて扱われることもある。
• プロトコルを管理情報の構造から分離することにより、SNMP は多種多様なサブシステムを容易に監視できるようになった。それはOSI参照モデルの全ての層を超えて、データベースや電子メール、J2EE参照モデルなど、その範囲を拡大している。
• Request for Comments (RFC) は、Internet Engineering Task Force (IETF) によって公開されている規格文書である。
• SNMP に関する最初のRFC は1988年に提出された。
• SNMP v2 はセキュリティに関する意見の不一致によって、広く採用されていない。
• SNMP v2c は"Community-Based Simple Network Management Protocol version 2"であり、非公式だがSNMP v1.5 として知られていた。
• SNMP v2u は"User-Based Simple Network Management Protocol version 2"である。