• TOP > トラブルシュート > Windowsネットワークの基礎知識、設定・トラブルシュート
  • ネットワークの基礎編
  • Windowsネットワーク編
  • 監視・パケット解析編

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ネットワーク管理資料一覧

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

• ネットワーク構成のチェックリスト

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

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

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

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

を算出する。

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

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

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

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

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

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

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

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

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

• イーサネットでは、
  • １つのフレームの最小サイズはフレーム間隔も含め672ビットになるため、

8バイト(プリアンブル、SFD) + 64バイト(イーサネットフレーム) + 12バイト(IFG) = 合計84バイト = 672ビット

• イーサネットのワイヤ スピードは以下の式で算出できる。

帯域幅（bps） ÷ 672（bit） ＝ ワイヤ スピード（pps）

• 従って、イーサネットの規格毎のワイヤ スピードは次のようになる。

• －補足－
  • 多くの場合、ノイズ、オーバヘッド、スイッチング能力などにより転送効率が落ちるため、ワイヤ スピードどおりの速度が出ることはないので注意する。
  • 一般的には、実際のデータ転送処理に使用できる帯域幅（全二重で帯域の７０％程度）で計算する。
  • スイッチング機能がない半二重のハブでは、スイッチング能力、ワイヤ スピードを考慮する必要はない。

• ブロードキャスト パケットが多すぎる場合は、
  ネットワークを分割するか、VLANを導入するなどして
  ブロードキャスト ドメインを分割（サブネット化）する必要がある。
• プロトコルによっては、名前解決などのためにブロードキャスト パケットを多用することがある。
  このため、プロトコルの特徴を理解して、ブロードキャスト ドメイン上のノード数を検討する必要がある。
• プロトコル別のブロードキャスト ドメイン上の
  ノード数の上限の目安としては、次の値を参考にできる。

• この上限値に近づいた場合は、下記を確認する。
  • パケット数を監視し、スイッチング能力、ワイヤ スピードに不足がないか？
  • ブロードキャスト パケットを監視し、ネットワーク上のPCのCPUに影響がないか？
• 問題があるようであれば、下記の何れかの方法で
  ブロードキャスト ドメインを分割（サブネット化）する。
  • ネットワークを分割する。
  • VLANを導入する。

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

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

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

• この場合、

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

  などにより、

• 複数の

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

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

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

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

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

• 負荷分散装置
  • 負荷分散方式には、以下のものがある。

• NLBについては NLBを参照
  • 分散処理方式
  • ハッシュ関数

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

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

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

• 各サーバのNICの負荷・エラー状況を監視する。
• NICの監視にはOS付属のユーティリティを使用できる。
  • パフォーマンス カウンタ
  • コマンドライン ツール
  • パケット キャプチャ ツール（パケット ダンプ ツール、LANアナライザ）
    サーバのNICをパケット キャプチャ ツールで直接監視する場合、
    パケット キャプチャ ツールの処理のオーバーヘッドに注意する。

• クライアント・サーバが混在するネットワークでマクロな問題を検出する場合は、ネットワーク上のパケットを監視する。
  • 最近のネットワークではスイッチが使用されている。
  • スイッチは、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基本参照モデルの下位のレイヤから分析を開始し、問題を切り分ける。
• そのレイヤで問題が発生していない場合は、上位のレイヤを分析し問題を探すようにする。
• ミクロな問題を起こしているレイヤとトラブルの例

• パケット キャプチャを実施することによって、これらの切り分け、対応が容易になる。
• 次にオープン ソースのソフトウェアLANアナライザ（Wireshark）の操作方法について説明する。

Wiresharkの操作方法を参照。

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

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