ネットワーク運用監視(SNMPv3・NetFlow/IPFIX・Syslog)の実務のサムネイル
ガイドNW

ネットワーク運用監視(SNMPv3・NetFlow/IPFIX・Syslog)の実務

公開: 2026-10-06更新: 2026-10-07
ネットワーク運用監視(SNMPv3・NetFlow/IPFIX・Syslog)の実務を図表とオリジナル演習で解説。動作条件、障害の切り分け、解答の考え方を整理し、NWの午後試験・科目B群の学習と実務に役立てます。

本記事はNWの午後試験・科目B群の学習を支える技術解説です。演習と解答例は当サイトのオリジナルで、IPAの公式問題・公式採点基準ではありません。製品ごとの設定差や、問題文で仮定した条件を区別して読み進めてください。

1. 概要と本質:なぜ「死活監視」だけでは不十分なのか

ネットワークの運用監視において、Ping(ICMP Echo)による「死活監視(Ping監視)」は最も基本です。 しかし、現場のネットワークエンジニアが直面するトラブルの多くは、「機器が完全にダウンする障害」ではなく、「機器は生きているが、通信が極端に遅い」「特定の時間帯だけパケットが大量破棄される」「特定の社員が回線帯域を占有している」といった、死活監視では絶対に検知できない「性能低下・サイレント障害」です。

このような複雑な障害を未然に防ぎ、発生時に即座に根本原因を特定するためには、以下の4つの監視技術を組み合わせた統合運用監視が不可欠です。

  1. 死活監視: 機器やポートの稼働状態(Ping / TCP Connect)。

  2. 性能・リソース監視: CPU/メモリ使用率やポートごとの通信トラフィック量(SNMP Polling)。

  3. トラフィック・フロー分析: 「誰が」「何を」「どの宛先へ」流しているかの通信内訳(NetFlow / IPFIX)。

  4. イベント・障害通知: 機器が自律的に発する異常アラートログ(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回のポーリング測定時刻(T1,T2T_1, T_2)の差分」から計算します。 帯域使用率 [%]=(ifInOctetsT2−ifInOctetsT1)×8 [bit](T2−T1) [秒]×インタフェース帯域幅 [bps]×100\text{帯域使用率 [\%]} = \frac{(\text{ifInOctets}_{T_2} - \text{ifInOctets}_{T_1}) \times 8 \text{ [bit]}}{(T_2 - T_1) \text{ [秒]} \times \text{インタフェース帯域幅 [bps]}} \times 100 ※1バイト=8ビットの換算を忘れないことが最大のポイントです。

3.2 SNMPv1/v2cの欠陥とSNMPv3(USM / VACM)

  • SNMPv1 / SNMPv2cの致命的脆弱性:

- パケット内のパスワードに相当する 「コミュニティ名(Community String)」が平文(暗号化なし) で流れる。盗聴されれば書込み権限まで付与されていれば設定変更に悪用されるおそれがある。

  • SNMPv3(RFC 3414 / RFC 3415)のセキュリティモデル:

- USM(User-based Security Model): ユーザ名ごとに暗号化と認証を適用。 1. noAuthNoPriv: 認証なし・暗号化なし(非推奨) 2. authNoPriv: 認証あり(SHA-256等による改ざん検知・なりすまし防止)・暗号化なし 3. authPriv: 認証あり(SHA-256)+ パケット暗号化あり(AES-128等(AES-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の通信記録」「ファイアウォールのセッションログ」「パケットキャプチャ」 を机の上に並べて時系列で突き合わせ(ログ相関分析)を行います。

時計が30秒進む機器と60秒遅れる機器では、記録上の差が実際より90秒ずれる。NTP同期に加えタイムゾーン、同期誤差、ログの時刻精度を確認し、記録を同じ基準に正規化する。


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は送信エラーが計上されていないことを示すが、物理層全体の正常性の証明ではない。本演習では帯域飽和に加え、送信キューの満杯も確認したため、出力バッファ溢れと判断する。

  • 設問要求の確認:

- 「ルータ内部のバッファメモリの動作に着目」 - 35字以内。

  • 文章作成: 設問が求める原因・動作を短く整理し、以下の解答例のようにまとめる。

- 送信パケットが回線帯域を超過し出力バッファが溢れて破棄されたため。

模範解答

送信パケットが回線帯域を超過し出力バッファが溢れて破棄されたため。

解答で確認したい論点

  • ×「回線が物理的に切断されたため。」(エラーパケットが0であり、帯域99.8%で通信自体は流れているため完全な誤り。論点不足)

  • △「帯域が狭すぎたから。」(出力バッファのオーバーフローというルータ内部の動作に触れていないため説明不足)


【設問2】

システム管理者が、帯域を飽和させている特定の端末および通信内容を特定するため、NMSサーバのNetFlowコレクタ画面で確認すべき通信フローの属性項目(送信元・宛先・通信種別に関する情報)を3つ挙げ、25字以内で述べよ。

解答への思考プロセス

  • NetFlowの7大キー項目:

- 送信端末を特定する情報:送信元IPアドレス - 送信先サーバを特定する情報:宛先IPアドレス - アプリケーション・通信内容を特定する情報:ポート番号(またはプロトコル番号)

  • 字数制限(25字以内)への整形:

- 「送信元IP、宛先IP、ポート番号」 - 「送信元IPアドレス、宛先IP、ポート番号」

模範解答

送信元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つのシナリオを形成します。 「障害が起きた時、パケットはどの経路を通り、どのヘッダが書き換わり、どの機器でドロップしたのか」を頭の中で動画のように再生できるようになれば、合格答案はおのずと完成します。自信を持って本番試験に挑んでください。

カウンタとログを使った確認例

1Gbpsで32ビットのOctetsカウンタは約34.36秒で一周するため、5分ポーリングの単純差分では使用率を計算できない。高速回線はifHCInOctets/ifHCOutOctetsを使い、ifCounterDiscontinuityTimeや再起動・リセットも確認する。32ビットでは複数周すると差分の補正だけでは復元できない。

例:100Mbps回線、300秒間でifHCOutOctetsが2,250,000,000バイト増えたとき、増分×8÷300=60,000,000bps、使用率60%。全二重リンクは送受信を別々に評価し、5分平均だけでは短いバーストを把握できない。

ifOutErrors=0でも受信側のエラーや物理層の問題がないとは限らない。ifOutDiscardsの増加にもキュー不足、ポリシー等の複数原因がある。演習は帯域飽和と出力キューの満杯を追加確認した条件である。

NetFlowの7項目は従来の代表的なキー例であり、Flexible NetFlow/IPFIXではテンプレートや観測点に応じて項目が異なる。ポート443だけでアプリ内容を断定できず、DNS・アプリログを合わせる。IPFIXはUDP以外のトランスポートも使える。SyslogはUDP以外にTCP/TLSも検討し、NTP同期は誤差をゼロにする保証ではない。

参考資料・関連する学習記事

RFC 2863

RFC 3414

RFC 3415

RFC 7011

RFC 5905

次に読む:ネットワーク障害調査とパケットキャプチャ解析の実務手順

次におすすめの学習

この記事を共有する

編集・検証について

編集・検証:IT資格ラボ編集部

IPAが公開する試験要綱・シラバス・過去問題と、各技術の公式資料を優先して内容を確認しています。制度変更や誤りを確認した場合は、記事を見直して更新します。

編集方針・情報源・訂正方針を見る