Skip to content

MS_NetworkMonitoringAndPacketAnalysis

Jump to bottom
nishi_74322014 edited this page Aug 3, 2026 · 1 revision

監視・パケット解析編

概要

「Windowsネットワークの基礎知識、設定・トラブルシュート」3部作の第3部。

ネットワーク管理・監視の必要性

ここ数年でネットワーク機器（NIC、スイッチなど）の価格は大きく値下がりし、
以前は、情報システム部門が担当していたネットワーク構築も"末端部分に関しては"
各部門から個人へと、ネットワーク構築の担当者のレベルが低下してきている。

このため、末端のネットワークで

  • ネットワークが不安定になった
  • ネットワークが遅くなった
  • 通信ができなくなった

などの問題が発生した場合、個人レベルでの対応が必要になる場合もある。

本ドキュメントでは対象読者を考慮し、末端のネットワークにおける、

  • 定常的なネットワーク構成の管理
  • マクロな問題のトラブルシュートのための、ネットワーク監視
  • ミクロな問題のトラブルシュートのための、パケット解析

などの方法について説明する。

ココでは、このマクロな問題・ミクロな問題を以下のように定義する。

マクロな問題

ココでは、ネットワークの全体的な問題をマクロな問題と呼ぶ。
以下の表に、このマクロな問題と、問題の検出方法の例を示す。

# マクロな問題の例 問題の検出方法の例
1 帯域の不足 転送データ量の監視
2 スイッチング能力、ワイヤ スピードの不足 パケット数の監視
3 ブロードキャスト ドメインが大きすぎる ブロードキャスト パケットの監視
4 サーバへの負荷集中 サーバのNICの監視

移行メモ: 元 Wiki の表では 2 行目の「問題の例」と「検出方法の例」が入れ替わっていたため、 他の行と同じ並びに揃えた。

ミクロな問題

ココでは、ネットワーク通信の局地的な問題をミクロな問題と呼ぶ。
以下の表に、このミクロな問題と、問題の検出方法の例を示す。

# ミクロな問題の例 問題の検出方法の例
1 NICの設定ミス（MACアドレス解決など） パケットキャプチャによるパケット分析
2 ルーティング、フラグメントに関する設定ミス 〃
3 TCPのコネクション、ウィンドウ・フロー制御 〃
4 クライアント・サーバ プログラムの設定ミスや予期せぬ動作 〃

ネットワークの把握

マクロな問題・ミクロな問題の切り分け、対応の際には、
ネットワークの把握が必要になる。本章では、ネットワークを把握するための、

  • ネットワーク構成
  • ネットワーク構成の問題点
  • ネットワークに必要な帯域幅

の確認方法について説明する。

ネットワーク構成の確認

初めに、ネットワーク構成（VLANなどの論理構成も含む）を確認し、問題になり得る部分を把握する。
ネットワーク構成の確認に利用できるネットワーク管理資料には次のようなものがある。

  • ネットワーク管理資料一覧
# 区分 管理資料 説明
1 ネットワーク構成管理
1-1 配線図（フロア・幹線） ケーブルの配線を記した図面。フロア内の配線と、フロア間・建物間の幹線の配線がある。
配線図には、論理的な経路を記した図面と、物理的な経路を記した図面がある。
1-2 ネットワーク構成図 ネットワーク全体の構成管理
1-3 パフォーマンス管理 サーバ・ルータのパフォーマンス情報、回線の負荷情報などの管理。
1-4 ネットワークの保守・障害履歴 ネットワーク機器の変更履歴と、障害履歴の管理
1-5 ベンダ・プロバイダ担当者リスト ネットワーク機器のベンダや配線施工会社、
WANのサービス プロバイダなどの担当者を記録するリスト
2 ネットワーク機器
2-1 ネットワーク機器リスト ネットワーク機器のリスト
2-2 ネットワーク機器設置図 ルータ、スイッチ、ハブなどのネットワーク機器を設置した場所の管理
2-3 ネットワーク機器設定内容 ルータ、スイッチなどのネットワーク機器に設定した内容の管理
2-4 パッチパネル接続表 統合配線システムのパッチパネルと、ネットワーク機器の接続管理
2-5 ネットワーク機器保守・障害履歴 ネットワーク機器の保守履歴、障害履歴の管理
3 ネットワーク端末
3-1 端末リスト ネットワークに接続されている端末のリスト
3-2 IPアドレス管理表 IPアドレスの割り当ての管理
3-3 アカウント管理 ユーザアカウントの管理

ネットワーク構成の問題点の確認

次に、ネットワーク構成の問題点を確認する。
以下のチェックリストを使用してネットワーク構成に問題点が無いか確認する。

  • ネットワーク構成のチェックリスト
# 区分 管理資料 説明
1 TPケーブル線の配線 TPケーブルが破損している場合、規格に適合しない場合、不正パケットが発生し易い。
1-1 TPケーブル線の保護 ・TPケーブルは保護されているか？
・無理に引き伸ばされたり、きつく締め付けられていたりしないか？
・コネクタ部分の加工にミスは無いか？
1-2 TPケーブルの規格とイーサネット規格 TPケーブル規格（カテゴリ）がイーサネット規格に適合しているか？
・カテゴリ3:10BASE-Tの場合
・カテゴリ5:100BASE-TXの場合
※ 上位のカテゴリの利用は問題ない。
1-3 機器間の総延長 機器間の総延長が、イーサネット規格で決められた総延長以下になっているか？
・リピータ - 端末間
・リピータ - リピータ間
2 ハブの配置 ハブとハブを接続する場合、イーサネット規格によっては中間のハブに端末を接続できないので注意する。
例えば、10BASE-T のネットワークが4台のハブで構成される場合、中間の2台には端末を接続できない。
3 スイッチの配置 規格に適合しない場合、不正パケットが発生し易い。
3-1 イーサネット規格との適合 イーサネット規格に適合しているか？
3-2 カスケード接続の段数 〃
3-3 スタック接続の段数 〃
4 機器・ノードの接続
4-1 ルータ、スイッチ、ハブ コリジョン ドメイン、ブロードキャスト ドメインの分割など、
イーサネットの特性を考慮して配置されているか？
・○: ルータ → スイッチ → ハブ
・×: ルータ → ハブ → スイッチ
4-2 クライアント、機器、サーバ ネットワーク トラフィックなど、業務システムの特性を考慮して配置されているか？
5 機器の保守・保護
5-1 機器の保守性 メンテナンスしやすい位置にあるか？
5-2 機器の保護 固定されているか？

ネットワークに必要な帯域幅の確認

ネットワーク構成に問題がないことを確認したら、必要とされる帯域幅を計算し、ネットワークの帯域幅に問題が無いかを確認する。
例えば、下記の構成では合計6台のPCが、ネットワーク プリンタとファイル サーバを使用する。

対象ネットワーク

通常、ブロードキャストやマルチキャストのパケットはそれほど多く使われていないので、
全ての通信がユニキャストで処理されている前提でトラフィックを計算する。

サーバ毎のトラフィック タイプがあるので、それぞれ次の式に当てはめて、

  • プリンタへのデータ転送処理に必要な帯域幅
  • ファイル サーバへ（から）のデータ転送処理に必要な帯域幅

を算出する。

トラフィック タイプ A に必要な帯域幅
  = クライアント台数
    * データ転送処理あたりのデータ量の平均値（量 / 回）
    * 単位時間あたりのデータ転送処理発生回数（回 / 時）
  = x（量/時）

※ 単位時間あたりにクライアントから送信されるトラフィック タイプ A のデータ量

  • これにより必要な帯域幅が算出でき、現状で不足がないかを確認する。
  • 実際のデータ転送処理に使用できる帯域幅は規格上の帯域幅より少ないので、
    必要に応じて、規格毎に実際のデータ転送処理に使用できる帯域幅を確認しておく必要がある。
  • －補足－
    • 一般的には半二重で帯域の40%、全二重で帯域の70%程度がネットワーク利用率の限界と言われている。
    • また、トラフィックは、統計学的に分布の幅が大きく最大値を予測し難い。このため、帯域幅には余裕を大きく持たせるのが慣例となっている。

マクロな問題の検出

ネットワークの以下の項目を監視することで、マクロな問題の検出ができる。
マクロな問題の検出には、一般的に定常的な監視が必要である。

マクロな問題の検出のための監視ポイント

転送データ量

現状の実際の転送データ量を把握することで、帯域幅の不足を確認できる。
必要とされる帯域幅の計算方法については、「ネットワークに必要な帯域幅の確認」を参照。

パケット数

パケット数の値を参考にして、スイッチング能力に不足がないかを確認できる。

当該ネットワークの理論上の最高通信速度で、最も負荷がかかる

「現在使用しているネットワークの帯域幅で、単位時間あたりに流れ得る最小サイズのフレーム数が最大となる状態」

を、ネットワークのワイヤ スピードと呼ぶ。

  • イーサネットでは、
    • １つのフレームの最小サイズはフレーム間隔も含め672ビットになるため、
8バイト(プリアンブル、SFD) + 64バイト(イーサネットフレーム) + 12バイト(IFG) = 合計84バイト = 672ビット
  • イーサネットのワイヤ スピードは以下の式で算出できる。
帯域幅（bps） ÷ 672（bit） ＝ ワイヤ スピード（pps）
  • 従って、イーサネットの規格毎のワイヤ スピードは次のようになる。
# 規格 帯域幅 ワイヤ スピード
1 Ethernet（10BASE-2、10BASE-5、10BASE-T） 10Mbps 14,880 pps
2 Fast Ethernet（100BASE-TX） 100Mbps 148,810 pps
3 Gigabit Ethernet（1000BASE-T） 1Gbps 1,488,100 pps
  • －補足－
    • 多くの場合、ノイズ、オーバヘッド、スイッチング能力などにより転送効率が落ちるため、ワイヤ スピードどおりの速度が出ることはないので注意する。
    • 一般的には、実際のデータ転送処理に使用できる帯域幅（全二重で帯域の７０％程度）で計算する。
    • スイッチング機能がない半二重のハブでは、スイッチング能力、ワイヤ スピードを考慮する必要はない。

ブロードキャスト パケットの監視

  • ブロードキャスト パケットが多すぎる場合は、
    ネットワークを分割するか、VLANを導入するなどして
    ブロードキャスト ドメインを分割（サブネット化）する必要がある。
  • プロトコルによっては、名前解決などのためにブロードキャスト パケットを多用することがある。
    このため、プロトコルの特徴を理解して、ブロードキャスト ドメイン上のノード数を検討する必要がある。
  • プロトコル別のブロードキャスト ドメイン上の
    ノード数の上限の目安としては、次の値を参考にできる。
# プロトコル ノード数
1 TCP/IP 500
2 IPX 300
3 AppleTalk 200
4 マルチプロトコル環境 200
  • この上限値に近づいた場合は、下記を確認する。
    • パケット数を監視し、スイッチング能力、ワイヤ スピードに不足がないか？
    • ブロードキャスト パケットを監視し、ネットワーク上のPCのCPUに影響がないか？
  • 問題があるようであれば、下記の何れかの方法で
    ブロードキャスト ドメインを分割（サブネット化）する。
    • ネットワークを分割する。
    • VLANを導入する。

サーバのNICの監視

  • 1台のサーバにトラフィックが集中してしまうと、

    • サーバのNIC
    • CPU（その他のマシン リソース）
    • ルータのNIC・CPU

    に処理能力を超える高い負荷がかかってしまう可能性がある。

  • この場合、

    • ルータ、ネットワークの分割
    • サーバ、NICの分割
    • 負荷分散装置の導入

    などにより、

  • 複数の

    • ルータ
    • ネットワーク
    • NIC
    • サーバ

    などへ負荷を分散できる。

負荷分散の方式の例

方式1: 複数ルータ・複数NICの設置

  • ネットワークを分割し、サーバにそれぞれのネットワーク毎のNICを装備する。
  • これによって、ルータ － ネットワーク － NICの負荷を分散できる。

方式1: 複数ルータ・複数NICの設置

方式2: サーバの分散（サーバ上のコンテンツ自体を分散する）

  • サーバ（コンテンツ）自体を分割することによって、NIC － サーバの負荷を分散できる。
  • また、方式1と組み合わせてルータ － ネットワークも分割すれば、
    ルータ － ネットワーク － NIC － サーバの負荷を分散できる。

方式2: サーバの分散（サーバ上のコンテンツ自体を分散する）

方式3: 負荷分散装置の導入

  • 負荷分散装置によって、NIC － サーバの負荷を分散できる。

方式3: 負荷分散装置の導入

  • 負荷分散装置
    • 負荷分散方式には、以下のものがある。
# 負荷分散方式 負荷分散装置（例）
1 ラウンドロビン ラウンドロビンDNS
（方式１・方式２でも利用可能）
2 サーバ応答時間 Squid（プロキシサーバ ソフトウェア）
（方式１・方式２でも利用可能）
3 クライアント IPアドレス ネットワーク負荷分散（NLB）クラスタ.etc
4 クライアント IPアドレス + ポート 〃
5 サーバCPU利用率 コンポーネント負荷分散（CLB）クラスタ.etc
6 その他の方式 TCP/IPコネクション数、ユーザ数、
転送データ量などを基に負荷分散する。
  • NLBについては NLB（MS_NLB.md）を参照
    • 分散処理方式
    • ハッシュ関数

マクロな問題の検出のための監視部位

マクロな問題を検出するにあたっての監視部位には、NIC、ネットワークがある。

以下、これらの部位の監視方法について説明する。

NIC

サーバ ファームなどのネットワークでマクロな問題を検出する場合は、

ネットワーク

  • クライアント・サーバが混在するネットワークでマクロな問題を検出する場合は、ネットワーク上のパケットを監視する。
    • 最近のネットワークではスイッチが使用されている。
    • スイッチは、MACアドレス フィルタリング機能によって、宛先ノード以外にはフレームを送信しない。

MACアドレス フィルタリング機能

  • このため、ネットワーク上のパケットを監視（自ノード宛以外のフレームを監視）する場合は工夫が必要になる。
    このような場合、

    • RMON（Remote network MONitoring）
      SNMPを拡張したネットワーク（LAN）の通信状況を遠隔から監視する仕組み。
      • RMONは最も古くからあるトラフィック管理技術で、遠隔地にあるネットワークをモニターする目的で開発された。
      • RMON では、RMONプローブ上のSNMPエージェントがイーサネット上のトラフィックを統計情報として、
        管理情報ベース（MIB）に保存し、この蓄積した情報をRMONマネージャ上のSNMPマネージャからの要求に応じて転送する。
      • ただし、市販のRMON対応機器は、RMON-1（データリンク層のキャプチャ機能）の一部にしか対応していない。
    • sFlow
      • キャプチャした情報を統計的処理で計算し、UDPベースのsFlowパケットで管理ステーションに送信する。
      • サンプル数が少ない場合、誤差が発生するという欠点がある。
    • NetFlow
      TCP, UDPやICMPなどの、送信元・送信先（IPアドレス・ポート番号の組み合わせ）で
      識別するセッション単位でパケット数やバイト数を統計的処理で計算し、
      UDPベースのNetFlowパケットで管理ステーションに送信する。

    などのネットワーク型IDSを導入することもできるが、比較的高価である。

    • 参考
      • ITpro > ネットワーク管理者のためのトラフィック管理入門 > 第4章 技術比較とまとめ

  • このような高価な製品（ソリューション）を導入できない場合、

    • （小規模ネットワークであれば）プロミスキャス モード に対応した
      フリーのパケット キャプチャ ツールを使用してパケットを監視できる。
    • 例えば、イーサネット上のネットワークのトラフィックは、
      クライアント － サーバ間、スイッチ － スイッチ間であることが多いので、
      この間に、ハブやポート ミラーリングが可能なスイッチ、
      スプリッタ タップ などを挿入しトラフィックを監視する。

パケット キャプチャ ツールを使用する方法（１）

  • また、WANに対するアクセスを監視する場合はルータ － スイッチ間に、
    ハブやポート ミラーリングが可能なスイッチ、スプリッタ タップなどを挿入しトラフィックを監視する。

パケット キャプチャ ツールを使用する方法（２）

ミクロな問題の検出

ミクロな問題の検出には、一般的にパケット キャプチャが有用である。

ミクロな問題の検出のためのパケット キャプチャ位置とタイミング

ココでは、ミクロな問題の検出のためのパケット キャプチャ位置とタイミングについて説明する。

パケット キャプチャの位置

  • 凡例：
    • NICのパケット キャプチャ： ●
    • 経路上のパケット キャプチャ： ○
  • 一般的には、問題の発生しているクライアント － サーバのNICのパケット キャプチャでこと足りる。
    • ただし、3つ以上のノード間で通信が発生するような場合、それにあわせてキャプチャ対象となるノード（NIC）も増加するので注意する。
      1. AD環境下でファイル サーバにアクセスする場合（DCへのNTLM・Kerberos認証が必要になる）
      2. HTTPでプロキシサーバを経由する場合
      3. FTPクライアントAからFTPサーバ上のファイルをFTPクライアントBに転送する場合

クライアント － サーバのＮＩＣのパケット キャプチャ

  • ただし、経路（スイッチ、ルータ、負荷分散装置）上でパケットがドロップされている場合など、場合によっては、
    経路上にパケット キャプチャ ツールと機材を挿入したほうが問題の切り分けが上手く行き、問題を早期に解決できる可能性もある。

経路上のパケット キャプチャ

  • このため、パケット キャプチャの位置を、必要に応じて使い分ける必要がある。
    • NICのパケット キャプチャ
    • 経路上のパケット キャプチャ

パケット キャプチャのタイミング

パケット キャプチャのタイミングは、

  • ネットワークの遅延と推測される場合と、
  • プログラム エラーと推測される場合とで

異なる。

  • ネットワークの遅延と推測される場合
    • 可能な限り、遅延の開始から終了までを採取する。
    • 途中で止めてしまうと、本当の問題が見えない可能性がある。
  • プログラム エラーと推測される場合
    • オペレーションの最初からエラー メッセージが出力されるまでを採取する。
    • ここでのプログラム エラーとは、
      OSのプロトコル スタックや、クライアント － サーバのプログラムの、
      パラメータなどの設定ミス・プログラム不良により発生するエラーを指す。

ミクロな問題を起こしているレイヤの切り分け、対応方法

ココでは、ミクロな問題を起こしている（OSI基本参照モデルの）レイヤの切り分け、対応方法について説明する。

  • 一般的には、OSI基本参照モデルの下位のレイヤから分析を開始し、問題を切り分ける。
  • そのレイヤで問題が発生していない場合は、上位のレイヤを分析し問題を探すようにする。
  • ミクロな問題を起こしているレイヤとトラブルの例
# レイヤ プロトコル 媒体 トラブルの例
1 第1層
物理層		 － ケーブル、インターフェイスなどハードウェア類 ・電源切断、LANケーブル抜け
・LANケーブルの破損
・イーサネット規格への不適合
2 第2層
データリンク層		 EthernetⅡ NIC、スイッチの機能部 ・ＮＩＣのドライバ不良
・IP ⇒ MACへのアドレス解決
3 第3層
ネットワーク層		 IP OSのIPプロトコル スタック ルーティング関連の設定（ＩＰアドレス、サブネット マスク、ルーティング テーブル）、
IPパケットのフラグメントなどに関する設定ミスがないか確認する。
4 第4層
トランスポート層		 TCP OSのTCPプロトコル スタック ・コネクション
・ウィンドウ・フロー制御
　・ウィンドウ サイズの状態
　・パケット遅延
　・ロストしたパケット
　・再送要求のパケット
　・再送されたパケット
　などの問題、
・TCP関係のパラメタの設定ミス
がないか確認する。
5 第5, 6, 7層
・セッション層
・プレゼンテーション層
・アプリケーション層		 ・HTTP
・FTP
・SMB		 ソフトウェア ・クライアント プログラム
・サーバ プログラム
の設定ミスや不良
  • パケット キャプチャを実施することによって、これらの切り分け、対応が容易になる。
  • 次にオープン ソースのソフトウェアLANアナライザ（Wireshark）の操作方法について説明する。

Wiresharkの操作方法

Wiresharkの操作方法（MS_WiresharkUsage.md）を参照。

  • マクロな問題検出についての具体例（Wiresharkを使用してマクロな問題を検出する具体例）
  • ミクロな問題検出についての具体例（Wiresharkを使用してミクロな問題を検出する具体例）

Tags: インフラストラクチャ, 通信技術

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally