「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
「Windowsネットワークの基礎知識、設定・トラブルシュート」3部作の第3部。
ここ数年でネットワーク機器(NIC、スイッチなど)の価格は大きく値下がりし、
以前は、情報システム部門が担当していたネットワーク構築も"末端部分に関しては"
各部門から個人へと、ネットワーク構築の担当者のレベルが低下してきている。
このため、末端のネットワークで
などの問題が発生した場合、個人レベルでの対応が必要になる場合もある。
本ドキュメントでは対象読者を考慮し、末端のネットワークにおける、
などの方法について説明する。
ココでは、このマクロな問題・ミクロな問題を以下のように定義する。
ココでは、ネットワークの全体的な問題をマクロな問題と呼ぶ。
以下の表に、このマクロな問題と、問題の検出方法の例を示す。
# | マクロな問題の例 | 問題の検出方法の例 |
1 | 帯域の不足 | 転送データ量の監視 |
2 | パケット数の監視 | スイッチング能力、ワイヤ スピードの不足 |
3 | ブロードキャスト ドメインが大きすぎる | ブロードキャスト パケットの監視 |
4 | サーバへの負荷集中 | サーバのNICの監視 |
ココでは、ネットワーク通信の局地的な問題をミクロな問題と呼ぶ。
以下の表に、このミクロな問題と、問題の検出方法の例を示す。
# | ミクロな問題の例 | 問題の検出方法の例 |
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が、ネットワーク プリンタとファイル サーバを使用する。
通常、ブロードキャストやマルチキャストのパケットはそれほど多く使われていないので、
全ての通信がユニキャストで処理されている前提でトラフィックを計算する。
サーバ毎のトラフィック タイプがあるので、それぞれ次の式に当てはめて、
を算出する。
= クライアント台数 * データ転送処理中りのデータ量の平均値(量 / 回) * 単位時間あたりのデータ転送処理発生回数(回 / 時) = x(量/時)
※ 単位時間あたりにクライアントから送信されるトラフィック タイプ A のデータ量
ネットワークの以下の項目を監視することで、マクロな問題の検出ができる。
マクロな問題の検出には、一般的に定常的な監視が必要である。
現状の実際の転送データ量を把握することで、帯域幅の不足を確認できる。
必要とされる帯域幅の計算方法については、「ネットワークに必要な帯域幅の確認」を参照。
パケット数の値を参考にして、スイッチング能力に不足がないかを確認できる。
当該ネットワークの理論上の最高通信速度で、最も負荷がかかる
「現在使用しているネットワークの帯域幅で、単位時間あたりに流れ得る最小サイズのフレーム数が最大となる状態」
を、ネットワークのワイヤ スピードと呼ぶ。
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 |
# | プロトコル | ノード数 |
1 | TCP/IP | 500 |
2 | IPX | 300 |
3 | AppleTalk? | 200 |
4 | マルチプロトコル環境 | 200 |
に処理能力を超える高い負荷がかかってしまう可能性がある。
などにより、
などへ負荷を分散できる。
# | 負荷分散方式 | 負荷分散装置(例) |
1 | ラウンドロビン | ラウンドロビンDNS (方式1・方式2でも利用可能) |
2 | サーバ応答時間 | Squid(プロキシサーバ ソフトウェア) (方式1・方式2でも利用可能) |
3 | クライアント IPアドレス | ネットワーク負荷分散(NLB)クラスタ.etc |
4 | クライアント IPアドレス + ポート | |
5 | サーバCPU利用率 | コンポーネント負荷分散(CLB)クラスタ.etc |
6 | その他の方式 | TCP/IPコネクション数、ユーザ数、 転送データ量などを基に負荷分散する。 |
マクロな問題を検出するにあたっての監視部位には、NIC、ネットワークがある。
以下、これらの部位の監視方法について説明する。
サーバ ファームなどのネットワークでマクロな問題を検出する場合は、
などのネットワーク型IDSを導入することもできるが、比較的高価である。
ミクロな問題の検出には、一般的にパケット キャプチャが有用である。
ココでは、ミクロな問題の検出のためのパケット キャプチャ位置とタイミングについて説明する。
- AD環境下でファイル サーバにアクセスする場合(DCへのNTLM・Kerberos認証が必要になる)
- HTTPでプロキシサーバを経由する場合
- FTPクライアントAからFTPサーバ上のファイルをFTPクライアントBに転送する場合
パケット キャプチャのタイミングは、
異なる。
ココでは、ミクロな問題を起こしている(OSI基本参照モデルの)レイヤの切り分け、対応方法について説明する。
# | レイヤ | プロトコル | 媒体 | トラブルの例 |
1 | 第1層 物理層 | - | ケーブル、インターフェイスなどハードウェア類 | ・電源切断、LANケーブル抜け ・LANケーブルの破損 ・イーサネット規格への不適合 |
2 | 第2層 データリンク層 | EthernetⅡ | NIC、スイッチの機能部 | ・NICのドライバ不良 ・IP ⇒ MACへのアドレス解決 |
3 | 第3層 ネットワーク層 | IP | OSのIPプロトコル スタック | ルーティング関連の設定(IPアドレス、サブネット マスク、ルーティング テーブル)、 IPパケットのフラグメントなどに関する設定ミスがないか確認する。 |
4 | 第4層 トランスポート層 | TCP | OSのTCPプロトコル スタック | ・コネクション、 ・ウィンドウ・フロー制御 ・ウィンドウ サイズの状態 ・パケット遅延 ・ロストしたパケット ・再送要求のパケット ・再送されたパケット などの問題、 ・TCP関係のパラメタの設定ミス がないか確認する。 |
5 | 第5, 6, 7層 ・セッション層 ・プレゼンテーション層 ・アプリケーション層 | ・HTTP ・FTP ・SMB | ソフトウェア | ・クライアント プログラム ・サーバ プログラム の設定ミスや不良 |
「Wiresharkの操作方法」を参照。
Tags: :通信技術