１課の技術書_SNMP編

この春また一つ年を取りました、tnk(32)です。

前回記事（1課の技術書全体では前前前前前前回？）に引き続き、SMAPの勉強です。勉強の基本は繰り返しです。視点を変えて、言葉を変えて、時間をおいて学びなおせば理解が深まります。人生もまた繰り返しです。お顔を変えて、性格を変えて、時代を変えて新生すれば学びが深まります（たぶん）。前前前前前前世ではきっとパピルスを繙いていたことでしょう。サーバやL2スイッチの稼働状況など一ミリも気にすることはなかったでしょう。私たちは新しい時代の技術についていかなければなりません。前回の内容を振り返りながら、今日はより詳しく学びなおしたいと思います。

さて、SMAPのリーダーと言えば、そう、中居くん…。

違いました。今日のテーマは「SNMP」です。

SNMP

SNMP（Simple Network Management Protocol）はSNMPマネージャ（管理する側）とSNMPエージェント（管理される側）が故障情報やトラフィック情報などをやり取りするためのプロトコルです。細かく言えば、SNMPエージェントは管理対象機器上で実行されるプロセスのことですが、ここでは管理対象機器のことと理解して差し支えありません。
SNMPはRFC（※）で定義された標準規格であり、サーバやネットワーク機器のベンダーや種類を問わずに利用可能です。

※RFCとは、IETF（インターネット技術の標準化を推進する任意団体）によって編纂されている、 インターネットのさまざまな技術文書やルール集のこと。多種多様なコンピュータシステムを共通の仕様のもとに構築運用することで、それらを相互接続して利用するメリットが得られる。インターネット技術の研究成果をより良いものにするために、インターネットに関わる人々から「コメントを募集する＝Request For Comments」ためのドキュメントとして公開が始まった。

SNMPには以下４つのバージョンがあります。
SNMPv1（RFC 1157）
SNMPv2（RFC 1448）
SNMPv2c（RFC 1901）
SNMPv3（RFC 2570）

SNMPv2は殆ど使用されておらず、SNMPv1の仕様をそのまま引き継ぐ、SNMPv2c（Community-based SNMPv2）が広く使用されています。SNMPv2cまでは平文認証のためセキュリティに懸念がありますが、SNMPv3ではユーザ単位で暗号化されたパスワード認証が可能です。SNMPv3の仕様は、RFC 3410～3418にまとめて新たに定義しなおされています。

◆PDU（Protocol Data Unit）

SNMPマネージャとSNMPエージェントとの間でやり取りされるメッセージはPDU（Protocol Data Unit）と呼ばれます。SNMPv1のPDUには、get-request、get-next-request、set-request、get-response、trapという5つのタイプがありましたが、SNMPv2ではさらに、get-bulk-request、inform-requestが追加されています。 SNMPは通信の効率性を重視するので、トランスポート層プロトコルにはUDP（User Datagram Protocol）を使用します。SNMPマネージャからSNMPエージェントへの問い合わせ（get系PDU）にはポート番号「161」が使用され、SNMPエージェントからSNMPマネージャへのトラップ（trap PDU）にはポート番号「162」が使用されます。

SNMPマネージャとSNMPエージェント間の要求・応答の動きを「ポーリング」と言い、SNMPエージェントが自発的に状態変化を通知する動きを「トラップ」（trap）と言うのでした。ちなみに、trapはSNMPv2ではsnmpV2-trap（trapV2）と名前が少し変わっています。

get-request、get-next-request、get-bulk-request という3つのPDUは、SNMPマネージャが、SNMPエージェントが持つMIB（Management Information Base）と呼ばれるデータベースからポーリングによって情報を読み出す際に使用されます。MIBとオブジェクト識別子についても前回やりました。オブジェクトをMIBツリー上の階層パスで示したものがOID（Object ID）です。このOIDを指定すればそれぞれのオブジェクトが持つ値を読み出すことができます。

ところがしかしバット。

一つ問題があることにお気づきでしょうか。

UDPではTCP（Transmission Control Protocol）と違い、送達確認が行われません。TCPでは3ウェイハンドシェイクと呼ばれる複雑な方法でコネクションを確立してからデータ転送を行いますが、シンプルイズベストなSNMPで使用するUDPでは複雑な制御はすべて省いて、効率よくデータを送ります。そのため、SNMPエージェントが緊急性の高いメッセージをtrapで送信した場合、SNMPマネージャがtrapメッセージを受信したかどうかは確認できないことになります。

そこで、SNMPエージェントはSNMPマネージャへinform-request PDUを送信し、SNMPマネージャからのresponse PDUを待ちます。response PDUを受信すれば、informメッセージをSNMPマネージャが受信したと判断できます。受信しなかった場合には、SNMPマネージャからresponse PDUを受け取るまで送信を繰り返すことで、送達確認を行います。

やはり、繰り返しが大事なのですね。

◆メッセージフォーマット

SNMPv2cで利用されるメッセージフォーマットを見てみましょう。

メッセージヘッダのバージョンは”1”に設定されます（v1=0, v2c=1, v3=3）。

コミュニティは、監視対象をグループ化する概念です。SNMPマネージャとSNMPエージェントとの間で同じコミュニティ名を持っていれば、管理情報を共有することができます。MIBへのアクセス権限はRO（Read-only）、RW（Read-write）、Read-write-all の3種類があり、コミュニティごとにMIBへのアクセス権限を分けることができます。

コミュニティ名が一致すれば、複数のホスト間で管理情報が共有できるので、コミュニティ名が管理情報にアクセスするためのパスワードの役割を担っているといえます。

ただし、コミュニティ名は平文でネットワーク上を流れてしまうため、セキュリティ面で脆弱です。よりセキュリティレベルが要求される環境では、コミュニティベースではなく、SNMPv3のUSM（User-based Security Model）の使用が推奨されています。

PDUタイプの値は以下の通りに決められています。
get-request = 0
get-next-request = 1
response = 2
set-request = 3
get-bulk-request = 5
inform-request = 6
snmpV2-trap = 7

※4はSNMPv1のtrapに割り当てられており、SNMPv2cでは使用されません。

オブジェクト名は、SNMPマネージャが取得したい情報につけられたOIDを示します。SNMPエージェントはそのOIDがもつデータを値フィールドに設定して、応答します。

◆RMON

最後に、RMON（Remote network MONitoring）にも触れておきましょう。アールモンと読むそうです。見ての通り、単語の頭文字を単純に並べた略し方ではない。こうなると推測が難しくなりますね。

RMONとは、ネットワーク上のトラフィックやエラーなどに関する統計情報をRMONエージェントが収集し、RMONマネージャが一元的に管理する機能をいいます。遠隔地のLANに流れる通信量やエラーに関するデータを収集し、RMON MIBとして保存し、マネージャからのポーリングに応じて、その内容を報告する仕組みです。RMON MIBもSNMPで取り込みが可能です。

RMONの仕様はIETFによって標準化されており、監視対象の機器と管理用ソフトウェアが異なるメーカーのものでも接続して利用することができます。

(´・ω・)

RFC 2819を読み始めたら頭が痛くなってきたので、今日はこの辺にしましょう。 皆さんもぜひRFC 2819を読んで頭が痛くなってみてください。

今日は若干教科書的な内容になったかもしれませんが、社内でネットワーク機器が使える環境が整えば、コマンドを打ちながらより実践的な検証ができるかもしれません。

それにしても、学習が進めば進むほど紛らわしくなりますね。
SNMPとSMAPは間違えましたが、PDUとUDPは間違えずに済みました。
最近、tnkはSNMPを嚙まずに言えるようになってきました。「おっさん」の入り口に立って変わったことと言えばそのくらいでしょうか。悲しいものです。

以上、tnkでした。

～BGM～
夜空ノムコウ