ネットワークの障害はネットワークを敷設している以上さけることが出来ない。したがって、ネットワーク管理者にはトラブルが発生してもその原因を特定できる「見極める力」が必要である。それには経験もそうだが、勘所をしっかりつかんでおくべきかと考える。そう言う意味も含め、ここでは俺が経験してきたことを事例としてあげ主観も含めて説明する。そんでもって、ネットワーク管理者のネットワーク障害の原因の特定に役立てて欲しい。
１．トラブル発生
ネットワークに何らかのトラブルが発生してパケット通信ができない状態になったとする。このとき管理者が最初にすべきことは、トラブルの発生個所の特定（当然）である。
それがわからなければ、対策を取ることはできないのは当たり前の事である（爆爆）。
トラブルの発生個所を特定するには“怪しいところ”を特定しなければならない。（図1）。
図の説明 ：
PC1～PC4の範囲すべてのクライアントPCで、同じトラブルが発生している場合はサーバの障害である可能性が高い。
PC1～PC3の範囲のクライアントPCでトラブルが発生した場合はルータまたはネットワークAの障害である可能性が高い。
PC1及びPC2の範囲のクライアントPCのトラブルならばハブの障害である可能性が高い。
PC1のみのクライアントPCにトラブルが発生した場合は、PC1自体の障害である可能性が高い。
２．原因を考える
ネットワーク関連のトラブル発生の範囲としては次の３つが考えられる。
（１） 複数のネットワーク内にあるすべてのクライアントで同じトラブルが発生している。
（２） 同一ネットワーク内にある複数台のクライアントで同じトラブルが発生している（ほかのクライアントにはトラブルは発生していない）。
（３） 特定のクライアント1台だけでトラブルが発生している。
（１）の場合、トラブルの発生個所はサーバの周辺にある可能性が高い。したがって、サーバのハードウェアやOSの設定、サーバのNICに接続しているネットワークケーブルやハブを疑う。
（２）の場合、トラブルの発生個所はサーバとクライアントの間にあるネットワーク機器である可能性が高い。したがって、経路上にあるルータやハブの故障、ケーブルの断線などを疑う。
（３）の場合、トラブルの発生個所はそのクライアント自体あるいはその周辺である可能性が高い。したがって、クライアントのハードウェアやOSの設定、NICに接続しているネットワークケーブルやハブを疑う。
意外と見落としがちなのは、（２）のネットワーク機器のトラブル及びネットワークケーブルの断線・接触不良のような気がする。ネットワークケーブルの断線や接触不良、特に自作ケーブルは注意が必要である。自作ケーブルは通常専用のテスターによって作成後、接続を確認するがテスターは接触不良に関しては感知しない。つまり、繋がっていればOKのサインを出してしまう。したがって、自作のネットワークケーブルは実際にマシンとネットワーク機器に繋げて結線状態を確認すべきである。
次に、ハブやルータの故障などが原因で突然ネットワークに接続できなくなることはよく発生する。最近のルータは熱対策に非常に安易である。したがって夏になると熱暴走による故障が非常に多くなるので注意。ルータの設置環境にも注意すべし。
さらに、これはトラブルが起こる前（敷設時）に配慮すべきだが、ケーブル長や、カスケード接続の段数の規定を守ることだ。ケーブル長が長すぎたり、カスケード接続の段数（せいぜいスイッチングハブで２段カスケードがベスト）が規定を超えると、衝突検出の仕組みが正しく働かなくなる。さらにケーブルが長くなると、そこで信号が減衰して弱くなる、すると受信側でエラーが多発して正しく信号を読み取れなくなる。その結果、通信ができなくなる。
また、一般的にスイッチングハブは、ポートに接続されている機器のMACアドレスを覚え、目的のポートにのみパケットを転送する機器である。
ケーブルの差し替えでこのMACアドレステーブルの対応情報が乱れ、ハブをリセットしない限り、パケットを正しく送れない事がある（リピータハブでは起こらない）。しかし、これは最近の高機能なハブでは起こりにくい。
余談だが会社で俺自身経験するのは休み明けの朝、一部のユーザーからネットワークに接続できなくなったという連絡を受けたことがある。調べたところハブの電源がコンセントから抜けていた。おそらく、休み中に社内を清掃した業者が足で蹴ったりして誤って抜けてしまたのだろう。さらに、電源コンセント自体の故障だった事もあった（安物のスイッチ付きのマルチタップは結構直ぐに壊れたりする）。また、スイッチングハブの1ポートもしくは複数ポートのみに障害が発生したこともあった。
《 ハブなどのネットワーク機器は、目立たない場所に設置されていることが多いため、気が付かない。したがって、注意すべきポイントであると言えるだろう。 》
このように、怪しい個所が特定できれば、原因も考えやすい。
３．原因の特定
さて、次にすべきことはトラブルの原因の特定である。トラブルの種類はさまざまだが、次のようなものが多い。
（１） ネットワーク設定に問題が有る
TCP/IPのパラメータ（IPアドレスやサブネットマスクなど）の設定ミス、DHCPによるIPアドレスの取得ミス、DNSやWINSによる名前解決の設定間違いなどが考えられる。
（２） ハードウェアの故障や設定に問題が有る
NICが故障していたり、またはNICを交換したときにOSが自動検出したデバイスが、実際に組み込んだデバイスと異なっていたりすることが考えられる（特にRIALTECのNICなんか良く壊れるので注意すべしRTL8139等）。
（３） OSの具合が悪い
利用しているアプリケーションやサービスの組み合わせにより、OSのネットワーク機能に影響が出る場合がある。
トラブルの種類を特定するには、そのトラブルがネットワークシステムの設定変更後に発生したのかアプリケーションのインストール後に発生したのか、あるいは運用中に発生したのかという”発生時期”を見極めることも重要だと考える。
システムの設定変更後に発生したのであれば、トラブルが発生する前の状態に戻し、これでトラブルが解決するかどうかを確認してみるのも一つの方法である。それによってトラブルが解決すれば、原因はシステムの設定変更やアプリケーションのインストールにあることは明白である。
アプリケーションの運用中に突然トラブルが発生した場合は、OSを再起動する。
再起動によってトラブルが解決することはよくある。しかし、また同じトラブルが発生した場合はOSや使用しているアプリケーションに根本的な原因がある場合が多い。
４．検証と対策
ここまでで、怪しい個所を特定することが出来たと思う。したがって、原因が
■ ネットワークの設定にあるならば「IPCONFIG」コマンドでTCP／IPの設定を確認する」。
■ ハードウェアにあるならば、「NICが正常に動作しているかどうかを確認する」。
■ OSにあるならば、「Windows2000では、可能性は低いがOSにトラブルの原因がある場合がある。また、起動しているアプリケーションやサービスの組み合わせによってネットワークにトラブルが発生するケースもある」。
（１）のネットワーク設定に原因が有る場合について
「コマンドプロンプト」を起動して、「IPCONFIG /ALL」を実行すれば、現在のIP設定情報が表示されるので、DHCP利用の有無や現在使用しているTCP/IPの設定などを確認できる。
コマンドプロンプトを起動し「IPCONFIG」コマンドでネットワークの設定を確認する。
画面1のように「DHCP Enabled」が「Yes」で、「Autoconfiguration IP Address」が「169.254.0.0」のクラスBアドレス（「128.1.0.0」から「191.254.0.0」までのIPアドレス）になっている場合は、DHCPサーバからIPアドレスのリースが受けられないことを意味しているらしい。
手動でのIPアドレスの割り当てがなく、かつDHCPサーバもない場合、Windows98/Me/2000/XPでは、自動でIPアドレスを割り当てる機能「自動プライベートIPアドレッシング（APIPA）」を利用できる。同機能は、「169.254.0.1」から「169.254.255.254」の範囲から一意なIPアドレスを無作為に選択し、サブネットマスクに「255.255.0.0」を設定する。ちなみにWindows95とWindowsNT 4.0ではIPアドレスの取得に失敗すると、IPアドレスは「0.0.0.0」と表示される。
ネットワーク設定に問題がある場合、トラブル発生の原因は、IPアドレスやサブネットマスクなどのTCP/IPパラメータの設定にあるケースと、DNSやWINSなどの名前解決にあるケースに大別できる。
ここでは、TCP/IPパラメータの設定から見てみよう。TCP/IPパラメータを手動で設定している場合は、IPアドレス、サブネットマスク、DNSサーバのアドレスを再度確認する。設定を正しい場合でも、一度別の設定に変更してから再度元に戻すことをお勧めする。画面で確認した内容が実際に有効な設定になっているとはかぎらないからである。
DHCPを利用している場合およびAPIPAが機能している場合は、IPアドレスの解放と再取得を行う。それには、「コマンドプロンプト」を開き、次のコマンドを順に実行する。
① IPCONFIG/RELEASE
② IPCONFIG/RENEW
コマンドの実行後、再度、「IPCONFIG /ALL」を入力して設定情報を確認する。ネットワーク構成とハードウェアに問題がない場合は、これで適切なIPアドレスがリースできるはずだ。
これらのコマンドを実行しても適切なIPアドレスがリースできない場合は、DHCPサーバとの間のネットワークに問題がある可能性が高い。IPアドレスがリースできなかった場合、PINGコマンドを使って通信可能かどうかを確認する。なお、「IPCONFIG」を実行したときに画面１のような情報が表示されない場合は、NICが故障しているか不適切なドライバがロードされている可能性が高い。NICが正常に認識されているかどうか、正しいドライバがロードされているかどうかを「デバイスマネージャ」で確認する。
また、DHCPに関してはこんな問題もある。
各種ルータにはDHCP機能を備えた製品がある。静的（固定）に構成したはずのネットワークでIPアドレスを設定し忘れたホストに、ルータのDHCP機能がIPアドレスを配布すると内部ネットワークで利用しているプライベート・アドレスの範囲が一致している場合、パケットが送受信できてしまう。そのため一見うまく動作しているように見える。しかし、これだけでは名前解決が出来ないため、内部サーバにアクセスできないのだがユーザの勘違いで「以前アクセスできたはず」と言う声が出てくると、原因究明に手間取る事になる（図２）。
（２）のハードウェアの故障や設定に問題が有る場合について
NICが正常に動作しているかどうかを確認する。
NICが正常に認識されているかどうか、正しいドライバがロードされているかどうかを「デバイスマネージャ」で確認する。
（３）のOSの具合が悪い場合について
Windows2000では、可能性は低いがOSにトラブルの原因がある場合がある。また、起動しているアプリケーションやサービスの組み合わせによってネットワークにトラブルが発生するケースもある。たまたま、ノートブックPC（Windows2000 Pro）に、手持ちのPCカード型LANアダプタ（A）を使ってネットワークの設定を行った。
PING、名前解決とも問題なく機能しサーバ上のファイルをノートブックPCのハードディスクにコピーしようとしたところ、途中でファイルのコピーに失敗するというトラブルが発生した。
そのLANアダプタ（A）はWindows2000 Proが稼動する別のノートブックPCで動作していたものなので、故障があるとは考えにくい。念のため、別のノートブックPCにこのLANアダプタ（A）をセットして同じようにコピーしてみると、何も問題なかった。となると、原因はノートブックPC本体にあると考えられる。ノートブックPCは、OSやシステムは購入後の初期状態のままなので、PCカードスロットのコントローラなどのハードウェア的な問題である可能性がある。そこで、別のPCカード型LANアダプタ（B）をセットして同様の実験を行った。すると、ファイルは何の問題もなくコピーできた。
一連の実験でわかったことは、ノートブックPCとLANアダプタ（A）は両方とも故障していない。しかし、両者を組み合わせるとうまく動作しないということになる。
その後の調査で、ノートブックPCに内蔵されているデジタルカメラのドライバとLANアダプタ（A）のドライバの相性が悪いために発生したトラブルであるということが判明した。このように単体では問題がなくても、組み合わせることによってうまくいかない可能性があることを覚えること。
《 最近、秋葉原のPCショップの店員も含め「相性」という言葉をよく使い何事もこの言葉で片づけてしまう。しかし、そもそも相性というのはハード的な要因ともソフト的な要因ともいえる。ハード的な要因を考えると、例えばLANカードなどの接続によって負荷容量が大きくなった。それによってデータ信号レベルで波形のなまりが大きくなりビット誤り（バースト的）を大量に出してしまう。ソフト的な要因を考えると、お行儀の悪いドライバソフトがメモリーを解放してくれない等である。 》
以上、トラブルシューティングの鉄則は”その場しのぎ”で考えないことだ。「適当に設定をいじったらトラブルが解決した」では経験として蓄積することができない。トラブルの発生範囲と内容を分析し、そのトラブルの原因を論理的に見つけ出すことが重要である事は言うまでも無い。
以上
コメント