SNMP（Simple Network Management Protocol）は、ルータ・スイッチ・サーバ・プリンタなどネットワーク機器の情報を遠隔から取得・設定するための定番プロトコルです。1988年8月にIETFがRFC 1067として初版v1を公開し、その後1993年のSNMPv2、1998年のSNMPv3（RFC 2570など）と進化してきました。MIB（Management Information Base）と呼ばれるツリー構造のオブジェクト定義により、機器ごとの情報を統一的に表現できます。古くからの監視ツールZabbix・Nagios・PRTG・LibreNMSなどはほぼ例外なくSNMPに対応し、現代でもネットワーク監視の基盤的存在として広く使われています。
この記事の目次
- Manager・Agent・MIBの三役構造
- v1からv3への進化
- ネットワーク監視での主な使い方
- ストリーミングテレメトリ・gNMIとの比較
- まとめ
Manager・Agent・MIBの三役構造
SNMPは「Manager（管理側）」「Agent（被管理側に常駐）」「MIB（情報定義）」の3要素で構成されます。Managerは監視サーバ上のSNMPクライアントで、ZabbixやLibreNMSのようなNMS（Network Management System）に組み込まれます。Agentは各機器上で動くデーモン（例：net-snmpd）で、UDP 161番ポートで要求を待ち受けます。両者の間でやり取りされる情報の意味は、MIBファイルがOID（Object Identifier）と呼ばれるドット区切りの番号体系で定義します。
代表的なオペレーションは、ManagerからAgentへのGetRequest（値を取得）、GetNextRequest/GetBulkRequest（順次・一括取得）、SetRequest（設定変更）と、Agentから自発的にイベントを通知するTrap（v1）/Notification（v2c以降）です。MIB-II（RFC 1213, 1991年）には、ifInOctets・ifOutOctets・ifOperStatusといったインターフェース統計が標準化されており、ベンダーを問わずほぼ同じ方法でトラフィック・状態を読み取れる点が長期にわたる広く採用された理由です。
v1からv3への進化
SNMPv1は1988年8月、IETFのジェフ・ケース氏らによってRFC 1067として公開されました。翌1989年のRFC 1098を経て、1990年のRFC 1157で正式版v1が確立し、TCP/IPベースのネットワーク管理プロトコルとしてあっという間に普及しました。「Simple」を名乗るとおり、UDP上で動く軽量なプロトコルで、コミュニティ名（パスワード相当）を平文で送る素朴な設計が当時としては実装容易性に貢献しました。
1993年に提案されたSNMPv2は機能拡張を狙いましたが、認証方式の合意が取れず分裂状態となります。妥協案として1996年のRFC 1901でSNMPv2c（コミュニティベース）が事実上の標準となり、GetBulkや64bitカウンタの導入で大規模機器の監視に対応しました。1998年にはRFC 2570としてSNMPv3（後にRFC 3411〜3418で再整理）が公開され、USM（User-based Security Model）とVACM（View-based Access Control Model）による認証・暗号化・アクセス制御の本格対応が実現しました。現在の運用では、外部公開系はv3必須、社内クローズドはv2cが残るというのが現実的な構成です。
ネットワーク監視での主な使い方
SNMPの最も典型的な使い方は、機器インターフェースの送受信オクテット数（ifInOctets/ifOutOctets）を一定周期でポーリングし、トラフィックグラフを描く監視です。1990年代のMRTG（Multi Router Traffic Grapher）や2000年代のCactiから、現代のZabbix・Prometheus（snmp_exporter経由）・LibreNMSまで、ネットワーク監視ツールはほぼ例外なくこのパターンを採用し、5分平均グラフという定型表現を生み出しました。
ハードウェア状態の監視（CPU使用率、メモリ、ファン回転数、温度、電源冗長）や、機器のソフト/ハード構成情報の取得もSNMPで行います。リンクダウンや認証失敗、ハードウェア障害といったイベントは、AgentからのTrap/Notificationで即時通知され、NMS上でアラートに変換されます。個別調査時にはMIBブラウザツール（iReasoning MIB Browser・snmpwalk等）でOIDツリーを辿り、ベンダー固有MIBに定義された詳細情報を直接覗くこともあります。API化やテレメトリの時代になっても、レガシー機器・プリンタ・UPSなどではSNMPが依然として最も確実な監視手段として現役です。
ストリーミングテレメトリ・gNMIとの比較
SNMPの最大の課題は、ポーリング型ゆえに大規模機器を秒単位で監視するのが現実的でない点と、UDPベースで結果のロスやTrapの取りこぼしが発生し得る点です。数千ポートのデータセンタスイッチを毎秒監視したい現代の要件には、構造的に向かないという指摘が増えてきました。これを背景に、gRPCベースのストリーミングテレメトリ（gNMI, OpenConfigの一環として2016年頃から推進）が台頭しています。
gNMIはYANGデータモデルに沿って機器の状態をPush型で送出する仕組みで、毎秒〜サブ秒の高頻度監視に向きます。Cisco・Juniper・Arista・Nokiaなど主要ベンダーが対応を進め、データセンタ・ハイパースケーラ環境では主流化しつつあります。ただしSNMPの「ほぼ全機器に標準実装されている」という強みは依然として大きく、混在環境ではSNMPとgNMIを併用する運用が主流です。プリンタ・UPS・組み込み機器ではSNMPがほぼ唯一の選択肢のため、当分は基盤プロトコルとして広く使われ続けるでしょう。
まとめ
SNMPは1988年のRFC 1067から始まり、v2c・v3を経て30年以上ネットワーク管理の基盤として使われ続けるプロトコルです。Manager・Agent・MIBの三役構造とOIDによる標準化が、ベンダーをまたいだ機器監視を可能にしました。近年はgNMIなどストリーミングテレメトリへの移行が進んでいますが、対応機器の幅広さからSNMPは現役のネットワーク監視ツールの土台であり続けています。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント