ネットワーク運用監視(SNMPv3・NetFlow/IPFIX・Syslog)の実務
1. 概要と本質:なぜ「死活監視」だけでは不十分なのか
ネットワークの運用監視において、Ping(ICMP Echo)による「死活監視(Ping監視)」は最も基本です。 しかし、現場のネットワークエンジニアが直面するトラブルの多くは、「機器が完全にダウンする障害」ではなく、「機器は生きているが、通信が極端に遅い」「特定の時間帯だけパケットが大量破棄される」「特定の社員が回線帯域を占有している」といった、死活監視では絶対に検知できない「性能低下・サイレント障害」です。
このような複雑な障害を未然に防ぎ、発生時に即座に根本原因を特定するためには、以下の4つの監視技術を組み合わせた統合運用監視が不可欠です。
死活監視: 機器やポートの稼働状態(Ping / TCP Connect)。
性能・リソース監視: CPU/メモリ使用率やポートごとの通信トラフィック量(SNMP Polling)。
トラフィック・フロー分析: 「誰が」「何を」「どの宛先へ」流しているかの通信内訳(NetFlow / IPFIX)。
イベント・障害通知: 機器が自律的に発する異常アラートログ(Syslog / SNMP Trap)。
ネットワークスペシャリスト(NW)午後・科目B試験では、「SNMPv3の暗号化・認証モデル(USM/VACM)」「MIB-2のカウンタ(`ifInOctets` や `ifInDiscards`)を用いた帯域使用率・廃棄率の定量的計算」「NetFlowによるトラフィック原因の特定」「NTPによるミリ秒単位の時刻同期とログ相関分析」が頻出します。 本稿では、プロトコル仕様から実務の計算式、障害切り分けまでを一気通貫で解説します。
2. 運用監視の4本柱と連携アーキテクチャ
運用監視システムは、プル型(定期問合せ)とプッシュ型(自律通知)の2つの通信方式を使い分けます。
図のデータを表示できません。
3. SNMPアーキテクチャとSNMPv3のセキュリティ
SNMP(Simple Network Management Protocol) は、マネージャ(監視サーバ)とエージェント(ルータやスイッチ等の被監視機器)の間で機器情報をやり取りするプロトコルです。
図のデータを表示できません。
3.1 MIB(Management Information Base)と中核カウンタ
MIBは、機器が保持する管理情報の木構造データベースです。各項目は OID(Object Identifier:オブジェクト識別子) というドット区切りの数字列で指定されます。
午後試験で計算問題として出題される代表的MIB-2カウンタは以下の通りです。
MIBオブジェクト | 意味 | 単位 | 活用法と試験での着眼点 |
|---|---|---|---|
`ifInOctets` | インタフェースが受信した総バイト数 | バイト (Octet) | 帯域使用率(スループット)の計算に必須。 |
`ifOutOctets` | インタフェースが送信した総バイト数 | バイト (Octet) | 戻りトラフィックの計算に使用。 |
`ifInErrors` | 受信時に壊れていたエラーパケット数 | 個数 (Packets) | ケーブル不良、光減衰、CRCエラー等の物理層障害を検知。 |
`ifInDiscards` | エラーはないが破棄(ドロップ)されたパケット数 | 個数 (Packets) | キュー(バッファ)溢れを検知。回線帯域が一時的にパンク(マイクロバースト)している証拠。 |
[!IMPORTANT] 帯域使用率の計算公式(試験超頻出) カウンタは機器起動時からの「累積値」であるため、「2回のポーリング測定時刻()の差分」から計算します。 ※1バイト=8ビットの換算を忘れないことが最大のポイントです。
3.2 SNMPv1/v2cの欠陥とSNMPv3(USM / VACM)
SNMPv1 / SNMPv2cの致命的脆弱性:
- パケット内のパスワードに相当する 「コミュニティ名(Community String)」が平文(暗号化なし) で流れる。盗聴されれば誰でもネットワーク機器の設定を書き換え(SetRequest)可能。
SNMPv3(RFC 3414 / RFC 3415)のセキュリティモデル:
- USM(User-based Security Model): ユーザ名ごとに暗号化と認証を適用。 1. noAuthNoPriv: 認証なし・暗号化なし(非推奨) 2. authNoPriv: 認証あり(SHA-256等による改ざん検知・なりすまし防止)・暗号化なし 3. authPriv: 認証あり(SHA-256)+ パケット暗号化あり(AES-128/256)(業界標準) - VACM(View-based Access Control Model): MIBツリーの特定の枝(サブツリー)に対してのみアクセス権(読取専用/読書可能)を認可する。
4. NetFlow / IPFIXによるトラフィック可視化
SNMP監視で「WAN回線の帯域使用率が98%に達している」ことが判明しても、「誰がその帯域を消費しているのか」は分かりません。 これを解決するのが NetFlow(Cisco開発) およびそのIETF標準規格である IPFIX(IP Flow Information Export: RFC 7011) です。
図のデータを表示できません。
ルータは通過するパケットの7大キーが一致するものを同一の「フロー」としてまとめ、通信が終了(FIN/RST)した際、または一定時間(アクティブタイムアウト)経過した際に、「フローの統計情報(送信元、宛先、ポート、バイト数、パケット数、開始・終了時刻)」をコレクタサーバへUDPでエクスポートします。
5. NTP(Network Time Protocol)とログ相関分析の鉄則
インシデント発生時、管理者は 「Syslogのアラートログ」「NetFlowの通信記録」「ファイアウォールのセッションログ」「パケットキャプチャ」 を机の上に並べて時系列で突き合わせ(ログ相関分析)を行います。
[!CAUTION] 試験頻出の落とし穴:時刻ズレによるログ分析の破綻 もしルータAの時計が30秒進んでおり、ファイアウォールBの時計が1分遅れていた場合、「FWで遮断された攻撃パケットが、なぜかその30秒前にルータAで正常通過している」という矛盾が生じ、障害や攻撃の因果関係が一切立証できなくなります。 【鉄則】: 全てのネットワーク機器、サーバ、監視装置は、信頼できる上位NTPサーバ(Stratum 1/2)を参照し、ミリ秒単位で時刻を完全同期させなければなりません。
6. 午後・科目B形式 実戦演習
【問題シナリオ】
全国に拠点を持つ物流企業のT社は、本社データセンタ(DC)と各拠点ルータとの間をIP-VPN網(拠点帯域:各100Mbps)で接続している。 本社DCの統合NMSサーバでは、全拠点の対外ルータに対して5分間隔でSNMPv3ポーリングを実施し、トラフィック量および機器リソースを監視している。
図のデータを表示できません。
ある月曜日の午前10時30分、関西支社から「本社基幹システムへの画面遷移が非常に重く、タイムアウトが多発している」という障害連絡が入った。 NMSのSNMP監視グラフを確認したところ、10時00分から10時30分にかけて以下のデータが記録されていた。
【SNMP監視データ(関西支社ルータ R-K のWAN送信ポート)】:
帯域使用率: 10時00分から100Mbpsの帯域上限(99.8%)に達して横ばい状態。
`ifOutErrors`(送信エラーパケット数): 0(物理層・回線の異常なし)
`ifOutDiscards`(送信破棄パケット数): 平常時は0であったが、10時00分以降、毎分約5,000パケットのペースで急上昇。
【設問1】
ルータR-Kにおいて、ifOutErrors が0であるにもかかわらず、ifOutDiscards が急増した理由について、ルータ内部のバッファメモリの動作に着目して35字以内で述べよ。
解答への思考プロセス
MIBカウンタの性質:
- ifOutErrors が0ということは、物理ケーブルの断線やノイズ、CRCエラーなどによるパケット破損は発生していない。 - ifOutDiscards は、パケット自体にエラーはないものの、ルータがパケットを処理・送信できずに自ら破棄(ドロップ)した数を示す。 - 送信トラフィック量が回線の物理帯域(100Mbps)を超過し、ルータの送信待ちキュー(出力バッファ)が満杯(オーバーフロー)になってパケットが溢れ出た(ドロップした)ことが直接の原因。
設問要求の確認:
- 「ルータ内部のバッファメモリの動作に着目」 - 35字以内。
文章作成:
- 送信パケットが回線帯域を超過し出力バッファが溢れて破棄されたため。(35字)
模範解答
送信パケットが回線帯域を超過し出力バッファが溢れて破棄されたため。(35字)
減点・失点分析
×「回線が物理的に切断されたため。」(エラーパケットが0であり、帯域99.8%で通信自体は流れているため完全な誤り。0点)
△「帯域が狭すぎたから。」(出力バッファのオーバーフローというルータ内部の動作に触れていないため減点)
【設問2】
システム管理者が、帯域を飽和させている特定の端末および通信内容を特定するため、NMSサーバのNetFlowコレクタ画面で確認すべき通信フローの属性項目(送信元・宛先・通信種別に関する情報)を3つ挙げ、25字以内で述べよ。
解答への思考プロセス
NetFlowの7大キー項目:
- 送信端末を特定する情報:送信元IPアドレス - 送信先サーバを特定する情報:宛先IPアドレス - アプリケーション・通信内容を特定する情報:ポート番号(またはプロトコル番号)
字数制限(25字以内)への整形:
- 「送信元IP、宛先IP、ポート番号」(17字) - 「送信元IPアドレス、宛先IP、ポート番号」(21字)
模範解答
送信元IP、宛先IP、ポート番号(17字) (または 送信元IPアドレス、宛先IPアドレス、宛先ポート番号)
減点・失点分析
×「MACアドレス、VLAN ID、ホスト名」(NetFlowの標準キー情報ではなく、パケットの中身を直接特定する情報ではないため不可)
△「IPアドレスとプロトコル」(送信元と宛先を区別しておらず、ポート番号が抜けているため減点)
7. まとめとNW科目B合格へのロードマップ
全16教材(NWP-01〜NWP-16)にわたる長大なカリキュラムは、ネットワークスペシャリスト(NW)試験で問われる技術体系を網羅するものです。
L2・物理層(NWP-03, NWP-11, NWP-13):
- STP/MC-LAGによるループ排除と冗長化、802.1X認証による接続制御、Wi-Fi 6/7のOFDMA電波設計。
L3・ルーティング(NWP-04, NWP-05, NWP-15):
- OSPFのエリア・コスト設計、BGPマルチホームのパス属性制御、IPv6 IPoE/MAP-Eの移行技術。
トランスポート・Web(NWP-02, NWP-07, NWP-08):
- TCPハンドシェイク・輻輳制御、ロードバランサのSSLオフロードとCookieパーシステンス、HTTP/3 QUICの低遅延化。
境界防御・WAN・ゼロトラスト(NWP-09, NWP-10, NWP-12, NWP-14):
- IPsec-VPN(IKEv2/NAT-T)、ステートフルFW・NAPT・ALG、ZTNA/SASE、SD-WANインターネットブレイクアウト。
基盤・運用監視(NWP-01, NWP-06, NWP-16):
- Wiresharkパケットキャプチャ解析、DNS権威・キャッシュ分離とDNSSEC、SNMPv3とNetFlowによる障害究明。
午後・科目B試験の長文問題は、これら複数の技術が複合して1つのシナリオを形成します。 「障害が起きた時、パケットはどの経路を通り、どのヘッダが書き換わり、どの機器でドロップしたのか」を頭の中で動画のように再生できるようになれば、合格答案はおのずと完成します。自信を持って本番試験に挑んでください。
次におすすめの学習
編集・検証について
編集・検証:IT資格ラボ編集部
IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。
編集方針・情報源・訂正方針を見る