アカウントをお持ちの場合

  •   パーソナライズされたコンテンツ
  •   製品とサポート

アカウントをお持ちでない場合

アカウントを作成

トラブルシューティングの概要

  このドキュメントは英語版のTroubleshooting Overviewを翻訳したものです。

目次

過去 10 年間において、ネットワーク リソースへの依存は飛躍的に増大しました。 今日の世界では、企業の成功はネットワークの可用性に大きく依存しています。 結果的に、企業でのネットワーク障害に対する許容性はますます低くなっています。 そのため、ネットワークのトラブルシューティングは多くの企業にとって重大な問題となっています。

産業活動は、ネットワークへの依存度が増大しただけでなく、複数のメディア タイプ、複数のプロトコル、および(多くの場合)未知のネットワークへの相互接続を含む、ますます複雑化する環境に移行しつつあります。 未知のネットワークとは、Internet Service Provider(ISP; インターネット サービス プロバイダー)に属するトランジット ネットワークや、プライベート ネットワークを相互接続する電話会社を指します。 また、データ ネットワークへの音声およびビデオの統合により、複雑性が増大し、またネットワークの信頼性がさらに重要になっています。

より複雑なネットワーク環境とは、インターネットワークにおいて接続とパフォーマンスの問題が発生する可能性が高く、多くの場合問題の発生源が分かりにくいことを意味します。



症状、問題、および解決策

インターネットワークにおける障害には、ある種の症状が特徴として表れます。 これらの症状には、一般的なもの(特定のサーバにアクセスできないクライアントなど)もあれば、より限定的なもの(ルーティング テーブルに存在しないルート)もあります。 それぞれの症状は、特定のトラブルシューティング ツールやテクニックを使用することで、1つあるいは複数の問題や原因にまで追跡できます。 各問題が特定されると、一連のアクションから構成される解決策を実施することで対処できます。

この文書では、一般的な環境において、症状を定義し、問題を特定し、解決策を実施する方法を説明します。 実際には、それらの一般的な方法論を状況に応じて適用し、トラブルシューティングを行っている個々の環境で、どのように症状を検出し、問題を診断するかを決定する必要があります。



一般的な問題解決モデル

ネットワーク環境のトラブルシューティングを行う場合、体系的なアプローチが最も有効です。 トラブルシューティングに対して非体系的なアプローチを行うと、貴重な時間とリソースを浪費し、場合によっては症状をさらに悪化させる可能性もあります。 特定の症状を定義し、症状の原因である可能性があるすべての問題を特定し、(最も可能性の高い問題から最も可能性の低い問題へ向けて)症状が出現しなくなるまで、潜在的な問題を 1 つずつ体系的に除去します。

一般的な問題解決モデルの処理の流れを示します。 この処理の流れは、インターネットワークをトラブルシューティングするための厳格なアウトラインではなく、お客様の特定の環境に合わせて問題解決プロセスを構築する基礎となるものです。


一般的な問題解決モデル

概要が示されている問題解決プロセスについて、次のステップで詳細を説明します。


ステップ 1 ネットワーク問題を分析する際には、問題を明確な文の形にします。 症状と考えられる原因のセットの形式で問題を定義する必要があります。

問題を正しく分析するには、一般的な症状を特定してから、どの種類の問題(原因)が症状を引き起こすかを確認します。 たとえば、ホストがクライアントからのサービス要求に応答していないとします(症状)。 考えられる原因としては、ホストの誤った設定、インターフェイス カードの不良、ルータ設定コマンドが欠けていることが挙げられます。

ステップ 2 考えられる原因を特定するのに必要な情報を収集します。

影響を受けているユーザ、ネットワーク管理者、マネージャ、およびその他の重要な人物に質問します。 ネットワーク管理システム、プロトコル アナライザのトレース、ルータ診断コマンドからの出力、ソフトウェアのリリース ノートなどの情報源から情報を収集します。

ステップ 3 収集した情報に基づいて、考えられる原因を検討します。 これらの情報を使用すると、考えられる問題の一部をリストから除外できます。

たとえばデータに基づいて、ハードウェアを問題から除外できれば、ソフトウェアの問題に集中できます。 機会あるごとに、効率的なアクション プランを作成できるよう、考えられる問題の数を絞るようにします。

ステップ 4 未解決の潜在的な問題を考慮したアクションプランを策定してください。もっとも可能性の高い問題から始めて、一度に一つだけの要素を変更していくプランを考案します。

一度に 1 つだけの要素を変更することで、特定の問題が解決される 因果関係が再現できます。 同時に複数の要素を変更しても問題が解決できる場合もありますが、 どの要素の変更が問題を解決したかの識別が大幅に困難になり、将来、 同様の問題が発生した場合の解決には役立ちません。

ステップ 5 アクション プランを実施し、症状が出現しなくなるかどうかを確認するテストを行いながら、各ステップを注意深く実行します。

ステップ 6 ある要素を変更した場合は、必ず結果を収集します。 一般的に、ステップ 2 で使用した同じ情報収集方式を使用する必要があります(つまり、影響を受ける重要な人物とともに、診断ツールを活用しつつ作業します)。

ステップ 7 結果を分析し、問題が解決されたかどうかを判断します。 解決していれば、プロセスは完了です。

ステップ 8 問題が解決されない場合、リスト内で次に可能性の高い問題に基づいてアクション プランを作成する必要があります。 ステップ 4 に戻り、一度に 1 つずつ要素を変更し、問題が解除されるまでこのプロセスを繰り返します。



注: 一般的な原因とそれに対するアクション(この文書で説明されているアクション、または使用中の環境に対して作成したアクション)をすべて試した場合は、シスコのテクニカル サポート担当者に連絡してください。



ネットワーク障害に対する準備

事前に準備してある場合の方が、必ず、ネットワーク障害からの復旧が容易になります。 通常、あらゆるネットワーク環境で最も重要な要件とは、常にネットワーク サポート担当者が、ネットワークに関する現在の正確な情報を利用できるようにすることです。 ネットワーク変更に関するインテリジェントな決定を行えるのは完全な情報がある場合だけで、また可能な限り迅速かつ容易にトラブルシューティングを実施できるのも完全な情報がある場合だけです。

ネットワーク トラブルシューティングのプロセス中、ネットワークは通常とは違った動作を示すものと予想されます。 したがって、業務への影響を最小限にするように、トラブルシューティング用のメンテナンス期間を設定することをお勧めします。 トラブルシューティングで、メンテナンス期間内に問題を特定できなかった場合に、簡単に元に戻せるように、実施したすべての変更を常に記録するようにしてください。

ネットワーク障害に対する準備ができているかどうか判断するには、次の質問に答えてください。

  • インターネットワークの正確な物理マップと論理マップがありますか。

    お客様の組織や部署には、ネットワーク上の全デバイスの物理的な位置およびそれらの接続形態だけでなく、ネットワークアドレス、ネットワーク番号、サブネットワークなどの論理マップの概要を示す、最新のインターネットワーク マップがありますか。

  • ネットワーク内で実装されているすべてのネットワークプロトコルのリストがありますか。

    実装されている各プロトコルに関して、ネットワーク番号、サブネットワーク、ゾーン、エリア、およびその他それらと関連付けられている要素のリストがありますか。

  • どのプロトコルがルーティングされているかを把握していますか。

    ルーティングされている各プロトコルに関して、正確な最新のルータ設定を把握していますか。

  • どのプロトコルがブリッジされているかを把握していますか。

    ブリッジではフィルタが設定されていますか、さらに、それらの設定のコピーがありますか。

  • インターネットへの接続を含む、外部ネットワークへの接点をすべて把握していますか。

    各外部ネットワーク接続に関して、どのルーティング プロトコルが使用されているかを把握していますか。

  • ネットワークに対して確立されたベースラインがありますか。

    お客様の組織では、現在の問題とベースラインを比較できるように、1日の異なる時間帯での通常のネットワークの動作とパフォーマンスを文書化していますか。

すべての質問に対して「はい」と答えることができれば、準備していない場合よりも、より迅速かつ容易に障害から復旧できるようになります。最後に、解決されたすべての問題に関して、必ず適用した解決策とともに問題を文書化します。この方法で、将来同じような問題が起こった場合に、お客様の組織内の他のユーザが参照できる問題/解決方法のデータベースを作成できます。これにより確実にネットワークのトラブルシューティング時間が短くなり、結果として業務への影響が最小化されます。



日本語版更新日:2005年3月31日