JPWO2006046309A1 - 通信ネットワークにおける障害発生箇所を特定する装置および方法 - Google Patents

Abstract

通信異常が発生したとき、通信ネットワーク上のノード間の物理的なリンクの情報と、２点間の通信経路に含まれる１つ以上のリンクを示す経路情報とを参照しながら、通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、障害発生箇所候補が絞り込まれる。

Description

本発明は、企業内ネットワーク、あるいはインターネットデータセンタ（ＩＤＣ）の環境等におけるネットワークシステムの運用管理の分野に係り、通信に異常が発生した場合に、その異常の原因となる障害がネットワーク上のどこで発生したのかについて、その可能性のある箇所を自動的に絞り込む装置および方法に関する。

ネットワーク運用管理における障害検知の分野においては、ネットワーク上のある２点間において、定期的に通信を試み、その通信が正常に行われることを確認することで、ネットワークの状態を監視している。

図１は、このようなネットワークシステムの例を示している。図１において監視対象となるネットワーク１０１は、以下の機器および広域ＩＰ（Internet Protocol ）通信ネットワーク１１６からなる。
・拠点ルータ１１１〜１１５
・ルータ１１７、１１８
・スイッチ（ＳＷ）１１９、１２０、１２３、１２４、１２７、１２８、１３３、１３４、１３７、１３８、１４１、１４２、１４７、１４８
・ファイアウォール１２１、１２２、１３５、１３６
・サーバ負荷分散装置（Server Load Balancer）１２５、１２６、１３９、１４０
・Ｗｅｂサーバ１２９〜１３２
・アプリケーションサーバ１４３〜１４６
・データベースサーバ１４９、１５０
この場合、広域ＩＰ通信ネットワーク１１６は、ＩＰ−ＶＰＮ（Virtual Private Network ）として機能する。２点間の通信試行とその結果となるデータの蓄積を実現する方法としては、以下の２つの方法がある。
（ａ）図１に示すように、ネットワーク上のある地点に運用管理サーバ１０２を設置する。そして、運用管理サーバ１０２からスイッチ１５１〜１５５を介して、監視対象となるネットワーク１０１内の各ノード（機器）に対して定期的に通信を試み、ｐｉｎｇ（Packet INternet Groper）／ＳＮＭＰ（Simple Network Management Protocol）等を用いて通信の可否および状態をチェックする。通信の経路は意識しない。運用管理サーバ１０２にチェック結果のデータを蓄積し、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者１０３に通知する。
（ｂ）図２に示すように、ネットワーク１０１内の複数のノード１１８、１３２、１４５、および１４９に通信監視用のエージェントプログラムをインストールする（ノード１１８はルータなので予めインストールされている場合が多い）。そして、エージェント間で通信を試み、通信の可否および状態をチェックして、その結果を運用管理サーバ１０２に転送する。運用管理サーバ１０２は、転送されたチェック結果を、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者１０３に通知する。この場合、エージェントがインストールされたノードペア間の通信経路の情報は管理されない。

（ａ）および（ｂ）のいずれの方法においても、運用管理サーバ１０２により、試行した通信において異常があると判断されると、当該ノードについてネットワーク通信が異常であることが、イベント通知を画面に表示する等の方法でネットワーク管理者１０３に通知される。

ただし、いずれの方法においても、判明するのは「ある２点間」での通信がある時点で正常に動作しているか否かであり、その２点の間の通信経路は運用管理サーバ１０２によって把握されていない。このようなネットワーク障害検知の方法には、以下のような問題が存在する。
（１）ある２点間の通信に異常があった場合に、その２点間のうちどの部分の障害に起因する異常であるのかが分からないという問題がある。

そもそもネットワーク障害検知は、ネットワーク障害発生時に早期に復旧することにより通信異常の発生期間を短縮するのが大きな目的であるが、早期の復旧のためには通信異常の原因の究明、すなわち障害発生箇所の特定を短時間で行うことが重要である。

ネットワーク通信においては、通信経路のいずれか一箇所でも通信を妨げるような異常が存在すれば、その通信は正常に行われないのが普通である。逆に言えば、多数のネットワーク機器をまたがった２つの機器の間における通信に異常が発生した場合、その原因となる障害が発生した可能性のある機器は、その２点のノードもしくはその中間にあるすべてのネットワーク機器という広範囲にわたる。ネットワーク管理者がこの通信異常の原因となる障害を発見・解決するには、それらすべての機器を調査しなければならない。

例えば、図３に示すように、運用管理サーバ１０２とルータ１１７の間で通信異常が発生した場合、ネットワーク管理者は、運用管理サーバ１０２、ルータ１１７、およびスイッチ１５１〜１５４のすべての機器を調査しなければならない。

通信異常の情報を、ある２点間では通信が正常であったことを示す他の正常通信の情報と組み合わせることにより、ネットワーク管理者の分析および判断によって、障害発生箇所を絞り込むことは可能である。しかし、人間の手を介することによって判断の誤りを犯しやすくなり、また障害発生箇所絞り込みに時間がかかることにより、通信異常という問題の解決までに時間が余分にかかってしまう。
（２）ある２点間の通信に異常があり、なおかつその２点間の物理的通信経路が複数考えられる場合に、そのうちどの経路の通信による異常であるかが分からないという問題がある。

（１）で述べた通り、通信異常のあった２点間の物理的経路が一通りであった場合においても、障害発生箇所の絞り込みは困難であった。しかしながら、実際の企業内ネットワークおよびインターネットにおいては、２つのノードの間の物理的通信経路が複数存在することも多い。このような場合、２点間の通信異常という事象からみて可能性のある障害発生箇所とは、考えうるすべての経路におけるすべての機器ということになる。（１）で述べた通り、このことは通信異常という問題の解決に時間がかかることを意味する。

例えば、図３のＷｅｂサーバ１３２とアプリケーションサーバ１４６の間で通信異常が発生した場合、領域３０１〜３０３内のすべての機器が障害発生箇所の可能性を持っている。

なお、このような場合に、通信異常の発生を検知してから後に、該当する２点間の異常通信がどのような経路で行われたのかを調査することができれば、ある程度の障害発生箇所絞り込みは可能であるが、この調査は一般に困難であると考えられる。なぜならば、当該２点間の通信はすでに異常となっているため、その２点間の通信を実際に行って経路を確認することができないからである。
（３）ある２点間の通信に異常が発見された場合に、その問題の影響範囲および業務上の緊急性を把握できないという問題がある。

例えば、企業内ネットワークにおいて、ある２点間の通信異常が観測されたが、その２点の間には、顧客向け業務等に用いられる重要度の高いネットワークと、異常時の予備等で使われている重要度の低いネットワークが存在する場合を想定する。

障害発生箇所が重要度の高いネットワークの機器にある場合は、この障害は業務に影響を与えるため、早急に対処しなければならないが、重要度の低いネットワークの機器に障害が発生した場合は影響範囲は限定され、対処を遅らせても構わない場合が多い。

このような場合、２点間の通信異常という情報だけでは、ネットワーク管理者はその障害が重要度の高いネットワークで発生しているかどうかを判断できない。実際には影響範囲が狭く、緊急ではない障害であったとしても、重大な障害である可能性を考慮して早急に対処し、結果として過大に労力を費やす結果となる場合がある。

なお、ネットワーク障害発生時に、ネットワークの構成要素から発せられる警報情報に基づいて故障箇所を特定するネットワークシステムも知られている（例えば、特許文献１参照）。
日本特許出願公開 特開２００３−１７９６０１号公報

本発明の課題は、通信ネットワークにおいて通信異常が発生した場合に、その原因となる障害が発生した可能性のある箇所を自動的に絞り込むことにより、通信異常という問題を短時間で解決することである。

本発明の障害発生箇所特定装置は、格納部および判定部を備える。格納部は、複数のノードからなる通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、その通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる１つ以上のリンクを示す経路情報とを格納する。判定部は、通信ネットワーク上で通信異常が発生したとき、リンク情報および経路情報を参照しながら、通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、残されたリンクまたは残されたリンクの両端のノードを障害発生箇所候補と判定する。

このような障害発生箇所特定装置によれば、通信異常が発生したとき、障害が発生した可能性のある箇所を特定のリンクまたはノードの範囲に自動的に絞り込むことが可能になる。

格納部は、例えば、後述する図１８のメモリ１８０２または外部記憶装置１８０５に対応し、判定部は、例えば、後述する図１０の障害発生箇所判定部に対応する。

従来のネットワークシステムにおける運用管理サーバによる通信試行を示す図である。 従来のネットワークシステムにおけるエージェントによる通信試行を示す図である。 従来のネットワークシステムにおける通信異常の発生を示す図である。 トポロジ探索部の構成図である。 物理接続を示す図である。 ＭＡＣ学習テーブルを示す図である。 トポロジ探索装置の構成図である。 コネクタのデータ構造を示す図である。 本発明のネットワークシステムを示す図である。 運用管理サーバおよび監視エージェントの機能ブロック図である。 サーバのグルーピングを示す図である。 各機器のインタフェース識別子を示す図である。 リンク情報を示す図である。 経路情報を示す図である。 通信異常発生時のネットワークの状態を示す図である。 判定処理データを示す図である。 障害発生箇所絞り込み処理のフローチャートである。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本実施形態では、通信ネットワークのトポロジおよび経路情報に基いて、障害発生箇所を絞り込む。トポロジとは、ネットワークを構成する機器同士の物理的・論理的な接続構成を意味する。

この場合、監視対象のネットワークにおける最新の「リンク情報」および「経路情報」があらかじめ用意されている必要がある。「リンク情報」とは、ネットワーク上の各機器の物理的な接続関係を示す情報であり、「経路情報」はネットワーク上の２点間の物理レベルを含む通信経路を示す情報である。

「リンク情報」と「経路情報」は、例えば、先に出願された日本特許出願（特願２００４−１６４７７８号）に記載された「トポロジ探索技術」および「経路探索技術」により定期的・自動的に取得することが可能である。そこで、まず、この「トポロジ探索技術」および「経路探索技術」の概要について、図４から図８までを参照しながら説明する。
（１）トポロジ探索技術
本技術は、物理レイヤからアプリケーションレイヤまでのすべてのレイヤを統合したトポロジを表現するモデルに基き、ＳＮＭＰ−ＭＩＢ（Management Information Base ）等を用いて各ネットワーク機器から各レイヤに関する情報を自動的に収集・分析することにより、各レイヤにまたがるネットワークトポロジをシステムが把握し、これをマップとして描画・表示するものである。これにより、従来は困難であったすべてのレイヤについてのトポロジ把握を容易に行うことができる。

特に、障害発生箇所絞り込み技術へ適用するにあたっては、物理レイヤにおけるトポロジ探索により「リンク情報」が取得できること、すなわち、各機器のどのポートとどのポートとがつながっているか、というレベルにおいて接続関係を把握することができることが、本技術の重要な点である。

実験に基いた見積によれば、本技術を実装したプログラムを用いると、１０００台程度の機器から構成されるネットワークのトポロジ探索結果をおよそ６０分以内に出力できると考えられる。この技術を定期的に、例えば毎日用いることにより、ネットワーク管理者は１日単位で物理レイヤを含む最新のネットワークトポロジを把握することができる。

図４は、トポロジ探索技術を実装したトポロジ探索部を示している。図４のトポロジ探索部４０２は、ノード検知部４１１、トポロジ情報取得部４１２、およびトポロジ構築部４１３を備え、以下の手順で、監視対象となるネットワークを構成する機器同士の物理的・論理的接続を求める。
１．ノード検知部４１１は、探索対象のネットワーク４０１のＩＰアドレスの範囲（探索範囲）と各機器のアカウント情報からなる入力情報４２１を受け取る。そして、探索範囲に対してｐｉｎｇによる探索を試みて、ネットワーク４０１を構成する機器（ノード）を検出し、検出されたノードのリスト４１４を生成する。
２．トポロジ情報取得部４１２は、ＳＮＭＰ、ｔｅｌｎｅｔ、またはｓｓｈ（Secure Shell）を用いて、検出されたネットワーク機器の設定やサービスの情報を取得する。情報取得に必要な各機器のアカウント情報は、ノード検知部４１１から受け取る。
３．トポロジ構築部４１３は、取得された情報から機器同士の物理的・論理的接続関係を求め、様々な目的に利用できる形式のトポロジデータベースとして保存する。トポロジ探索部４０２からの出力情報４２２には、各機器の設定情報やリンク情報が含まれる。

トポロジ構築部４１３は、各機器におけるメディアアクセス制御（Media Access Control，ＭＡＣ）学習テーブルを取得し、機器毎のＭＡＣ学習テーブルの内容を照合することで、機器間の物理的な接続関係を把握する。ＭＡＣ学習テーブルには、送信先ＭＡＣアドレスと送信元ポートの対応関係が記録されている。

図５は、探索対象のネットワークにおける物理接続の例を示している。このネットワークは、スイッチ５０１〜５０３およびパーソナルコンピュータ（ＰＣ）５０４〜５１５からなる。

スイッチ５０１（スイッチα）はポート１〜５を有し、ポート１、２、３、および４には、パーソナルコンピュータ５０４、５０５、５０６、および５０７がそれぞれ接続されており、ポート５にはスイッチ５０２が接続されている。

スイッチ５０２（スイッチβ）はポート１〜６を有し、ポート１、２、３、および４には、パーソナルコンピュータ５０８、５０９、５１０、および５１１がそれぞれ接続されており、ポート５および６には、スイッチ５０１および５０３がそれぞれ接続されている。

スイッチ５０３（スイッチγ）はポート１〜５を有し、ポート１、２、３、および４には、パーソナルコンピュータ５１２、５１３、５１４、および５１５がそれぞれ接続されており、ポート５にはスイッチ５０２が接続されている。

パーソナルコンピュータ５０４、５０５、５０６、５０７、５０８、５０９、５１０、５１１、５１２、５１３、５１４、および５１５のＭＡＣアドレスは、それぞれＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、およびＬである。

スイッチ５０１、５０２、および５０３は、スイッチングサービスを行うために、図６に示すようなＭＡＣ学習テーブル６０１、６０２、および６０３をそれぞれ持っている。これらのＭＡＣ学習テーブルには、ポート毎に、学習されたパーソナルコンピュータ５０４〜５１５のＭＡＣアドレスが登録されている。

例えば、スイッチαのポート５については、スイッチβ配下の４台のＰＣのＭＡＣアドレスＥ、Ｆ、Ｇ、およびＨが学習されており、スイッチβのポート５については、スイッチα配下の４台のＰＣのＭＡＣアドレスが学習されている。この情報から、スイッチαのポート５とスイッチβのポート５とが接続されていると推測できる。このように、スイッチのＭＡＣ学習テーブルから、スイッチ同士の接続や、スイッチ−ＰＣ間の接続を求めることが可能である。

スイッチ５０１〜５０３およびパーソナルコンピュータ５０４〜５１５の機器設定情報が入力されたとき、トポロジ構築部４１３は、以下の手順でリンク情報を求める。
トポロジ構築部４１３は、まず、スイッチの機器設定情報からＭＡＣ学習テーブル６０１、６０２、および６０３を抽出し、それらのＭＡＣ学習テーブルを参照してスイッチ間の物理接続を探索する。

隣接する２台のスイッチ間においては、互いを繋ぐポートについて学習されるＭＡＣアドレスは、隣接するスイッチの、互いを繋ぐポート以外のポートについて学習されたＭＡＣアドレスの総和である。

トポロジ構築部４１３は、ネットワーク内の全スイッチのＭＡＣアドレス学習テーブルを調査し、スイッチの各ポートについて学習されているＭＡＣアドレスの、ポートを単位とする論理和を用いた比較が成立するか否かを判定して、スイッチ同士の物理接続を求める。

次に、トポロジ構築部４１３は、パーソナルコンピュータ５０４〜５１５のＭＡＣアドレスと、スイッチ間の物理接続の探索結果から、スイッチと各パーソナルコンピュータの物理接続を探索する。このとき、各スイッチのＭＡＣ学習テーブル内の、スイッチ同士の接続に使用されていないポートのうち、ネットワーク内のスイッチ以外の機器（パーソナルコンピュータ）のＭＡＣアドレスを学習しているポートを探索し、該当するポートとパーソナルコンピュータの間の物理接続を求める。

こうして物理接続の情報（リンク情報）が得られると、トポロジ構築部４１３は、リンク情報と各機器の設定情報を用いてレイヤ別のトポロジ探索処理を行い、複数レイヤにわたるトポロジを求める。

このとき、設定情報を用いて複数のレイヤの中の下位レイヤのトポロジに含まれる物理接続または論理接続をグループ化して、上位レイヤにおける情報到達範囲を生成し、その情報到達範囲から上位レイヤのトポロジを生成する。このような処理を物理レイヤ、ＭＡＣレイヤ、ＩＰレイヤ、ＴＣＰ／ＵＤＰ（Transmission Control Protocol/User Datagram Protocol）レイヤ、およびアプリケーションレイヤの順に繰り返すことで、複数レイヤにわたるトポロジが生成される。
（２）経路探索技術
本技術は、探索対象となる経路の始点および終点の機器（ノード）と、トポロジ探索技術の出力結果であるトポロジデータベースをもとに、始点ノードから隣接ノードを経由して終点ノードまで接続されているネットワーク内の２点間の経路を算出するものである。

これにより、ネットワークの２点間の通信における「経路情報」を、ＩＰレイヤだけでなくＭＡＣレイヤまで（通過するＬ２スイッチ等の情報まで）のネットワーク機器のレベルで把握することが可能である。具体的には、以下の手順で経路探索を行う。
１．ＩＰレイヤのネクストホップ取得
始点ノードから終点ノードに向かうための、ＩＰレイヤにおけるネクストホップのＩＰアドレスを、始点ノードのルーティング情報から取得する。
２．ＭＡＣレイヤのネクストホップ取得
始点ノードのＭＡＣ学習テーブルをもとに、ネクストホップのＩＰアドレスに向かうための、ＭＡＣレイヤにおけるネクストホップのＭＡＣアドレスを取得する。トポロジ探索技術により得られているリンク情報を参照し、ＭＡＣレイヤでのネクストホップとなる機器を決定する。
３．始点ノードの代わりにネクストホップとなる機器に対して、２のＭＡＣレイヤのネクストホップ取得を繰り返し、ＭＡＣレイヤでの経路情報の取得を続ける。これを繰り返してＩＰレイヤでのネクストホップの機器に辿り着いたら、１のＩＰレイヤのネクストホップ取得を繰り返して、ＩＰレイヤにおいてその次のホップとなる機器を決定する。以上の処理を、終点ノードのＩＰアドレスに辿り着くまで繰り返す。

図７は、このような経路探索技術を実装したトポロジ探索装置を示している。図７のトポロジ探索装置７０１は、図４のトポロジ探索部４０２と経路探索部７１１を備える。経路探索部７１１は、次経路判定部７２１および動的情報算出部７２２を備え、探索対象情報７２３および次探索対象情報７２４を保持する。

経路探索部７２１は、各機器の設定情報７５１、複数レイヤにわたるトポロジ７５２、および探索条件７５３を入力として経路探索処理を行い、データ通過経路７５４を経路情報として出力する。

トポロジ７５２は、リンク情報に対応する物理レイヤのトポロジ７６１、ＭＡＣレイヤのトポロジ７６２、ＩＰレイヤのトポロジ７６３、ＴＣＰ／ＵＤＰレイヤのトポロジ７６４、およびアプリケーションレイヤのトポロジ７６５からなり、探索条件７５３は、始点および終点となるネットワーク内の２点７７１およびサービスの種類７７２の情報を含む。ネットワーク内の２点７７１は、ノード名やＩＰアドレス等により指定される。

探索対象情報７２３は、現在のコネクタ７３１および直前のコネクタ７３２の情報を含み、次探索対象情報７２４は、上位レイヤのコネクタ７４１および下位レイヤのコネクタ７４２の情報を含む。また、データ通過経路７５４は、データが通過したコネクタ７８１−１〜７８１−ｎの情報を含む。

各レイヤにおいて、機器間の物理・論理接続に使用される物理・論理インタフェースは「コネクタ」で表され、通信の終端を行ったり、機器内の複数コネクタ間でデータの転送を行う機能は「サービス」で表される。

図８は、現在のコネクタ７３１、直前のコネクタ７３２、上位レイヤのコネクタ７４１、下位レイヤのコネクタ７４２、およびコネクタ７８１−１〜７８１−ｎの各コネクタ情報のデータ構造を示している。図８のコネクタ情報８０１は、該当するコネクタが属する機器名８１１、レイヤの識別情報８１２、および同一レイヤ内でコネクタを一意に識別するためのコネクタ識別子８１３を含む。

次経路判定部７２１は、現在の探索対象の情報を探索対象情報７２３に保持し、次の探索対象の情報を次探索対象候補７２４に保持しながら、設定情報７５１、トポロジ７５２、および探索条件７５３を用いてネクストホップの取得を繰り返す。そして、始点ノードから終点ノードに至るコネクタの情報を、データ通過経路７５４として出力する。動的情報算出部７２２は、次経路判定部７２１により宛先が得られない場合、または名前解決等の方法により宛先を取得する必要がある場合に、動的に宛先を求める。

本実施形態では、上述した（１）トポロジ探索および（２）経路探索を定期的に実施することにより、監視対象となるネットワークのリンク情報と、ネットワーク内の複数の始点・終点の組み合わせに対する経路情報をあらかじめ取得しておく。また、運用管理サーバを設けるとともに、監視対象のネットワーク上の複数のノードに監視エージェントを配置する。

図９は、本実施形態のネットワークシステムの例を示している。図９のシステムは、以下の機器からなる。
・スイッチ：ＳＷ−ａ、ＳＷ−ｂ、ＳＷ−ｃ、ＳＷ−ｄ、ＳＷ−ｅ、ＳＷ−ｆ
・ファイアウォール：ＦＷ−ａ、ＦＷ−ｂ
・サーバ負荷分散装置：ＳＬＢ−ａ、ＳＬＢ−ｂ
・Ｗｅｂサーバ：ＷＥＢ−ａ、ＷＥＢ−ｂ
・アプリケーションサーバ：ＡＰ−ａ、ＡＰ−ｂ
・運用管理サーバ９０１
このうち、ＷＥＢ−ａ、ＷＥＢ−ｂ、ＡＰ−ａ、およびＡＰ−ｂに、それぞれ監視エージェント９０２、９０３、９０４、および９０５が配置されている。

運用管理サーバ９０１は、異常通信が発生したとき、その通信の経路情報と他の正常通信の経路情報とを照合する。そして、異常通信の経路に含まれる各リンクのうち、他の正常通信の経路に含まれていないものを抽出し、そのリンクおよび両端のポートを障害発生箇所候補として出力する。

例えば、ＷＥＢ−ｂからＡＰ−ａへの通信とＷＥＢ−ａからＡＰ−ｂへの通信がともに正常で、ＷＥＢ−ｂからＡＰ−ｂへの通信において異常が発生した場合、以下のリンクおよびポートが障害発生箇所候補として求められる。
・ＳＬＢ−ｂとＳＷ−ｆの間のリンク９０６
・ＳＬＢ−ｂのポート９０７（ＳＷ−ｆ向け）
・ＳＷ−ｆのポート９０８（ＳＬＢ−ｂ向け）
図１０は、図９の運用管理サーバ９０１および監視エージェント９０２〜９０５の機能ブロック図である。運用管理サーバ９０１は、図４のトポロジ探索部４０２および図７の経路探索部７１１に加えて、ノードペア抽出部１０１１、通信可否調査部１０１２、障害発生箇所判定部１０１３、および結果表示部１０１４を備える。監視エージェント１００１は、監視エージェント９０２〜９０５に対応し、通信監視部１０３１、通信異常通知部１０３２、抽出部１０３３、および通信試行部１０３４を備える。

運用管理サーバ９０１のトポロジ探索部４０２および経路探索部７１１は、トポロジ探索および経路探索を定期的に実施することにより、監視対象のネットワークの最新（例えば、最近１日以内）のリンク情報１０２１および複数のノードペアに対する経路情報１０２２を取得する。これらの情報は、運用管理サーバ９０１内に保持される。

監視エージェント１００１の通信監視部１０３１は、常時、他のノード（事前に経路情報が判明しているノード）との間の通信を監視し、ログ１０４１を生成する。ログ１０４１には、通信先ＩＰアドレスと通信可否の情報が一定期間蓄積される。通信監視部１０３１が他のノードとの間での通信の異常を検知すると、通信異常通知部１０３２は、その旨を運用管理サーバ９０１に通知する。

運用管理サーバ９０１のノードペア抽出部１０１１は、通信可否調査対象のノードペアを抽出する。通信可否調査対象としては、例えば、経路情報が判明しているすべてのノードペアが抽出される。通信可否調査部１０１２は、監視対象のネットワーク上に配置された各監視エージェント１００１に対して、抽出されたノードペアの通信可否を問い合わせる。

これを受けて、監視エージェント１００１は、以下の２つの方法のいずれかを用いて、指示された各ノードペアに対する通信可否の情報を取得し、運用管理サーバ９０１に回答を送信する。
（ａ）通信試行部１０３４は、運用管理サーバ９０１からの問い合わせを契機として、ノードペアに含まれる宛先ノードへの通信を試行する。
（ｂ）抽出部１０３３は、ログ１０４１を参照して、ノードペアに含まれる宛先ノードとの通信の可否を取得する。この場合、通信可否調査部１０１２は、監視エージェント１００１に対して調査すべき時間帯を指示し、抽出部１０３３は、その時間帯に宛先ノードと通信できていたか否かをチェックする。調査すべき時間帯としては、通信異常発生時刻の前後の一定時間等が指定される。

例えば、Ｗｅｂ−ｂからＡＰ−ｂへの通信で１０時３５分２０秒に異常が発生した場合、Ｗｅｂ−ａの監視エージェント９０２は、ログ１０４１を参照して、Ｗｅｂ−ａからＡＰ−ａへの通信またはＷｅｂ−ａからＡＰ−ｂへの通信において、１０時３４分５０秒から１０時３５分５０秒の時間帯に成功／失敗の事例があるか否かをチェックする。そのような事例があれば、それを回答として運用管理サーバ９０１に通知する。

次に、運用管理サーバ９０１の障害発生箇所判定部１０１３は、リンク情報１０２１、経路情報１０２２、および現時点での通信可否の情報をもとに、通信経路を構成するリンクのいずれか１箇所でも通信を妨げるような障害が存在すれば、その通信は正常に行われないとの認識に基き、異常の原因となる障害発生箇所を絞り込む。

障害発生箇所判定部１０１３は、通信に異常があるノードペアに対し、その経路となるリンクを１つ１つ抽出し、そのリンクが他の正常通信が可能なノードペアの経路に含まれているか否かをチェックする。そして、正常通信の経路に含まれていないリンクの集合と、各リンクの両端にあるポートの集合を、障害発生箇所候補に決定する。

結果表示部１０１４は、障害発生箇所候補の情報を画面表示することで、処理結果を管理者に通知する。例えば、監視対象のネットワークを描いた画面上に、障害発生箇所候補となる機器およびリンクを色を変えて表示することで、障害発生箇所候補が容易に認識できるようになる。

また、処理結果を再利用できるように、異常発生時刻、異常が発生した経路、障害発生箇所候補、および障害発生箇所の情報が、障害情報１０２３として運用管理サーバ９０１内に保存される。結果表示部１０１４は、保存された障害情報１０２３を参照することで、過去のある時点でのネットワークの状態を再表示することができる。

このようなシステムによれば、ノード間で通信異常が発生した場合に、その通信異常の原因となる障害発生箇所を、あらゆる可能な通信経路の中で、実際に通信が行われた経路で、かつ、他の正常通信では使われない部分に、絞り込むことができる。

絞り込みの精度は、ネットワーク上における監視エージェントの設置数（密度）に依存する。より多くの監視エージェントを設置して多数のノードペアに対する通信可否の情報を取得するほど、通信異常時の障害発生箇所をより狭い範囲に絞り込める。このような絞り込み方法は、監視対象のネットワーク上に同時に発生した障害が１箇所または複数箇所である場合に適用可能である。

ところで、異常通信が発生したとき、常に他のすべてのノードペアについて通信可否を調査すると、調査対象が多すぎて処理効率が低下することが考えられる。そこで、以下の手順で通信可否調査対象を絞り込むことが好ましい。
１．管理者は、
事前に、トポロジ的または役割的に近いサーバ同士をグルーピングし、サーバグループとして運用管理サーバ９０１に登録しておく。
２．ノードペア抽出部１０１１は、通信異常が発生したノードペアの各ノードが属するサーバグループを調べ、それらのサーバグループ間でペアを構成するような２つのノードを、通信可否調査対象として抽出する。

例えば、図１１に示すように、Ｗｅｂ−ａおよびＷｅｂ−ｂをＷｅｂサーバグループ１１０１として登録し、ＡＰ−ａおよびＡＰ−ｂをＡＰサーバグループ１１０２として登録しておく。Ｗｅｂ−ｂからＡＰ−ｂへの通信で異常が発生したとき、Ｗｅｂサーバグループ１１０１のノードとＡＰサーバグループ１１０２のノードがペアを構成するように、以下のノードペアが抽出される。
・Ｗｅｂ−ａとＡＰ−ａ
・Ｗｅｂ−ａとＡＰ−ｂ
・Ｗｅｂ−ｂとＡＰ−ａ
そして、Ｗｅｂ−ａからＡＰ−ａへの通信、Ｗｅｂ−ａからＡＰ−ｂへの通信、およびＷｅｂ−ｂからＡＰ−ａへの通信の可否が調査される。Ｗｅｂ−ｂとＡＰ−ｂのノードペアは、通信異常が発生したノードペアに相当するため、調査対象からは除外される。

次に、図１２から図１７までを参照しながら、図９のネットワークシステムにおける障害発生箇所絞り込み処理について、より詳細に説明する。
図１２は、図９の監視対象のネットワークに含まれる各機器のインタフェース（コネクタ）の識別子を示している。これらの機器のインタフェース識別子は、以下の通りである。
ＳＷ−ａ、ＳＷ−ｂ、ＳＷ−ｃ、ＳＷ−ｄ、ＳＷ−ｅ、ＳＷ−ｆ：ｐｏｒｔ１〜ｐｏｒｔ６
ＦＷ−ａ、ＦＷ−ｂ、ＳＬＢ−ａ、ＳＬＢ−ｂ：ｐｏｒｔ１〜ｐｏｒｔ４
ＷＥＢ−ａ、ＷＥＢ−ｂ、ＡＰ−ａ、ＡＰ−ｂ：ｅｔｈ０、ｅｔｈ１
図１３および１４は、図１２のネットワークに対するリンク情報および経路情報の例を示している。図１３のリンク情報には、物理レイヤのトポロジとして、各リンクの識別子（接続ＩＤ）と、リンクの両端にあるノードの識別子と、そのノードのコネクタの識別子が含まれている。例えば、接続ＩＤ“１”を有するリンクは、ノード“ＷＥＢ−ａ”のコネクタ“ｅｔｈ０”とノード“ＳＷ−ａ”のコネクタ“ｐｏｒｔ１”を接続するリンクであることが分かる。

図１４の経路情報は、ＷＥＢ−ｂと始点とし、ＡＰ−ｂを終点とする経路の情報に相当し、始点に近い方から順に、経路を構成するリンクの接続ＩＤ、リンクの両端にあるノードの識別子、およびそのノードのコネクタの識別子が記録されている。

図１５は、通信異常発生時のネットワークの状態を示している。例えば、ＷＥＢ−ｂを始点とし、ＡＰ−ｂを終点とする通信の異常が検知され、他の経路での通信が試行された結果、ＷＥＢ−ａからＡＰ−ｂへの通信とＷＥＢ−ｂからＡＰ−ａへの通信は正常であることが判明する。この場合、障害発生箇所判定部１０１３は、図１６に示すような判定処理データを生成し、図１７に示すフローチャートに従って障害発生箇所絞り込み処理を行う。

図１６の判定処理データには、通信異常が発生した経路を構成する各リンクについて、以下の情報が登録される。
・接続ＩＤ
・リンク始点：リンクの始点のノードおよびコネクタの識別子
・リンク終点：リンクの終点のノードおよびコネクタの識別子
・ＷＥＢ−ｂ→ＡＰ−ｂの経路に含まれるか否か
・ＷＥＢ−ｂ→ＡＰ−ａの経路に含まれるか否か
・ＷＥＢ−ａ→ＡＰ−ｂの経路に含まれるか否か
・障害発生箇所候補であるか否か
黒丸のマーク●は、リンクが対応する経路に含まれることを表し、黒星のマーク★は、リンクおよびコネクタが障害発生箇所候補であることを表す。接続ＩＤ、リンク始点、およびリンク終点の情報は、図１３のリンク情報から取得され、リンクが経路に含まれるか否かの情報は、図１４の経路情報から取得される。図１６の判定処理データには、さらに、各経路の通信可否の情報も登録されている。

障害発生箇所判定部１０１３は、まず、経路情報に含まれる異常または正常と判明した各通信の経路を参照し（ステップ１７０１）、１つ以上の異常通信の経路に含まれるリンクを抽出する（ステップ１７０２）。そして、抽出されたリンクに関する判定処理データを生成し、各リンクに対して障害発生箇所候補になるか否かの判定を開始する（ステップ１７０３）。

まず、判定処理データを参照しながら、１番目のリンクが１つ以上の正常通信の経路に含まれているか否かをチェックする（ステップ１７０４）。そして、そのリンクがいずれの正常通信の経路にも含まれていなければ、当該リンクとその両端のコネクタを障害発生箇所候補とみなして、判定処理データの対応する行に黒星のマークを付ける（ステップ１７０５）。そのリンクがいずれかの正常通信の経路に含まれていれば、当該リンクとその両端のコネクタを障害発生箇所候補から除外する（ステップ１７０６）。

次に、すべてのリンクを判定したか否かをチェックし（ステップ１７０７）、未判定のリンクがあれば、次のリンクを選択してステップ１７０３以降の処理を繰り返す（ステップ１７０８）。そして、未判定のリンクがなくなれば、処理を終了する。

図１５の例では、通信異常が発生した「ＷＥＢ−ｂ→ＡＰ−ｂ」の経路に含まれるリンクが抽出され、図１６に示した判定処理データが生成される。そして、抽出されたリンクのうち、他の正常通信の経路である「ＷＥＢ−ｂ→ＡＰ−ａ」および「ＷＥＢ−ａ→ＡＰ−ｂ」に含まれるリンクが障害発生箇所候補から除外される。こうして、残された接続ＩＤ“２４”のリンクと、その両端のコネクタに相当するＳＬＢ−ｂのｐｏｒｔ４とＳＷ−ｆのｐｏｒｔ２が、通信異常の原因となる障害発生箇所の候補と判定される。

以上説明した実施形態では、通信機能の階層構成として物理レイヤ、ＭＡＣレイヤ、ＩＰレイヤ、ＴＣＰ／ＵＤＰレイヤ、およびアプリケーションレイヤの５つのレイヤを想定しているが、本発明はこの階層構成に限らず、他の階層構成にも同様に適用可能である。

ところで、図７のトポロジ探索装置７０１および図９の運用管理サーバ９０１、Ｗｅｂサーバ９０２、９０３、アプリケーションサーバ９０４、９０５は、例えば、図１８に示すような情報処理装置（コンピュータ）を用いて構成される。図１８の情報処理装置は、ＣＰＵ１８０１、メモリ１８０２、入力装置１８０３、出力装置１８０４、外部記憶装置１８０５、媒体駆動装置１８０６、ネットワーク接続装置１８０７を備え、それらはバス１８０８により互いに接続されている。

メモリ１８０２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１８０１は、メモリ１８０２を利用してプログラムを実行することにより、必要な処理を行う。

図１０のトポロジ探索部４０２、経路探索部７１１、ノードペア抽出部１０１１、通信可否調査部１０１２、障害発生箇所判定部１０１３、結果表示部１０１４、および監視エージェント１００１は、メモリ１８０２に格納されたプログラムに対応する。また、図１０のリンク情報１０２１、経路情報１０２２、障害情報１０２３、ログ１０４１および図１６の判定処理データは、メモリ１８０２に格納されたデータに対応する。

入力装置１８０３は、例えば、オペレータからの指示や情報の入力に用いられる。出力装置１８０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果等の出力に用いられる。

外部記憶装置１８０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１８０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１８０２にロードして使用する。外部記憶装置１８０５は、リンク情報１０２１、経路情報１０２２、障害情報１０２３、およびログ１０４１を保存するデータベースとしても使用される。

媒体駆動装置１８０６は、可搬記録媒体１８０９を駆動し、その記録内容にアクセスする。可搬記録媒体１８０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体１８０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１８０２にロードして使用する。

ネットワーク接続装置１８０７は、通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置１８０７を介して受け取り、それらをメモリ１８０２にロードして使用する。

図１９は、図１８の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体１８０９やサーバ１９０１のデータベース１９１１に格納されたプログラムおよびデータは、情報処理装置１９０２のメモリ１８０２にロードされる。サーバ１９０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置１９０２に送信する。ＣＰＵ１８０１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。

本発明によれば、ネットワーク運用管理における障害発生時の復旧において、以下の効果が得られる。
（１）通信異常の原因となる障害が発生した可能性のある箇所を絞り込むことにより、原因究明および復旧作業をより短時間で行うことができる。

前述したように、従来は、ネットワーク上の２点間の通信に異常があった場合、考えられる障害発生箇所は、その２点間のすべての可能な経路上にある、すべての機器・リンクであった。

これに対して、本発明によれば、考えられる障害発生箇所を、実際にその２点間で通信が行われた経路上にある機器・リンクのうち、他で確認された正常通信のデータが通過していない部分にまで絞り込むことができる。このため、原因究明のために調査対象とする機器を減らすことができ、復旧作業の短期化につながる。
（２）通信異常発生時に、その問題の影響範囲および業務上の緊急性の把握ができる可能性が高くなる。

（１）の絞り込みの結果、障害発生箇所である可能性のある場所の範囲が、重要度の低いネットワーク内に絞り込まれれば、業務に影響を与えない程度の影響範囲であると判断できる。その結果、前述したような、緊急ではない障害に対して過大な労力を費やすことが、回避される。

本発明は、企業内ネットワーク、あるいはインターネットデータセンタ（ＩＤＣ）の環境等におけるネットワークシステムの運用管理の分野に係り、通信に異常が発生した場合に、その異常の原因となる障害がネットワーク上のどこで発生したのかについて、その可能性のある箇所を自動的に絞り込む装置および方法に関する。

ネットワーク運用管理における障害検知の分野においては、ネットワーク上のある２点間において、定期的に通信を試み、その通信が正常に行われることを確認することで、ネットワークの状態を監視している。

図１は、このようなネットワークシステムの例を示している。図１において監視対象となるネットワーク１０１は、以下の機器および広域ＩＰ（Internet Protocol ）通信ネットワーク１１６からなる。
・拠点ルータ１１１〜１１５
・ルータ１１７、１１８
・スイッチ（ＳＷ）１１９、１２０、１２３、１２４、１２７、１２８、１３３、１３４、１３７、１３８、１４１、１４２、１４７、１４８
・ファイアウォール１２１、１２２、１３５、１３６
・サーバ負荷分散装置（Server Load Balancer）１２５、１２６、１３９、１４０
・Ｗｅｂサーバ１２９〜１３２
・アプリケーションサーバ１４３〜１４６
・データベースサーバ１４９、１５０

この場合、広域ＩＰ通信ネットワーク１１６は、ＩＰ−ＶＰＮ（Virtual Private Network ）として機能する。２点間の通信試行とその結果となるデータの蓄積を実現する方法としては、以下の２つの方法がある。
（ａ）図１に示すように、ネットワーク上のある地点に運用管理サーバ１０２を設置する。そして、運用管理サーバ１０２からスイッチ１５１〜１５５を介して、監視対象となるネットワーク１０１内の各ノード（機器）に対して定期的に通信を試み、ｐｉｎｇ（Packet INternet Groper）／ＳＮＭＰ（Simple Network Management Protocol）等を用いて通信の可否および状態をチェックする。通信の経路は意識しない。運用管理サーバ１０２にチェック結果のデータを蓄積し、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者１０３に通知する。
（ｂ）図２に示すように、ネットワーク１０１内の複数のノード１１８、１３２、１４５、および１４９に通信監視用のエージェントプログラムをインストールする。そして、エージェント間で通信を試み、通信の可否および状態をチェックして、その結果を運用管理サーバ１０２に転送する。運用管理サーバ１０２は、転送されたチェック結果を、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者１０３に通知する。この場合、エージェントがインストールされたノードペア間の通信経路の情報は管理されない。

（ａ）および（ｂ）のいずれの方法においても、運用管理サーバ１０２により、試行した通信において異常があると判断されると、当該ノードについてネットワーク通信が異常であることが、イベント通知を画面に表示する等の方法でネットワーク管理者１０３に通知される。

ただし、いずれの方法においても、判明するのは「ある２点間」での通信がある時点で正常に動作しているか否かであり、その２点の間の通信経路は運用管理サーバ１０２によって把握されていない。このようなネットワーク障害検知の方法には、以下のような問題が存在する。
（１）ある２点間の通信に異常があった場合に、その２点間のうちどの部分の障害に起因する異常であるのかが分からないという問題がある。

そもそもネットワーク障害検知は、ネットワーク障害発生時に早期に復旧することにより通信異常の発生期間を短縮するのが大きな目的であるが、早期の復旧のためには通信異常の原因の究明、すなわち障害発生箇所の特定を短時間で行うことが重要である。

ネットワーク通信においては、通信経路のいずれか一箇所でも通信を妨げるような異常が存在すれば、その通信は正常に行われないのが普通である。逆に言えば、多数のネットワーク機器をまたがった２つの機器の間における通信に異常が発生した場合、その原因となる障害が発生した可能性のある機器は、その２点のノードもしくはその中間にあるすべてのネットワーク機器という広範囲にわたる。ネットワーク管理者がこの通信異常の原因となる障害を発見・解決するには、それらすべての機器を調査しなければならない。

例えば、図３に示すように、運用管理サーバ１０２とルータ１１７の間で通信異常が発生した場合、ネットワーク管理者は、運用管理サーバ１０２、ルータ１１７、およびスイッチ１５１〜１５４のすべての機器を調査しなければならない。

通信異常の情報を、ある２点間では通信が正常であったことを示す他の正常通信の情報と組み合わせることにより、ネットワーク管理者の分析および判断によって、障害発生箇所を絞り込むことは可能である。しかし、人間の手を介することによって判断の誤りを犯しやすくなり、また障害発生箇所絞り込みに時間がかかることにより、通信異常という問題の解決までに時間が余分にかかってしまう。
（２）ある２点間の通信に異常があり、なおかつその２点間の物理的通信経路が複数考えられる場合に、そのうちどの経路の通信による異常であるかが分からないという問題がある。

（１）で述べた通り、通信異常のあった２点間の物理的経路が一通りであった場合においても、障害発生箇所の絞り込みは困難であった。しかしながら、実際の企業内ネットワークおよびインターネットにおいては、２つのノードの間の物理的通信経路が複数存在することも多い。このような場合、２点間の通信異常という事象からみて可能性のある障害発生箇所とは、考えうるすべての経路におけるすべての機器ということになる。（１）で述べた通り、このことは通信異常という問題の解決に時間がかかることを意味する。

例えば、図３のＷｅｂサーバ１３２とアプリケーションサーバ１４６の間で通信異常が発生した場合、領域３０１〜３０３内のすべての機器が障害発生箇所の可能性を持っている。

なお、このような場合に、通信異常の発生を検知してから後に、該当する２点間の異常通信がどのような経路で行われたのかを調査することができれば、ある程度の障害発生箇所絞り込みは可能であるが、この調査は一般に困難であると考えられる。なぜならば、当該２点間の通信はすでに異常となっているため、その２点間の通信を実際に行って経路を確認することができないからである。

（３）ある２点間の通信に異常が発見された場合に、その問題の影響範囲および業務上の緊急性を把握できないという問題がある。

例えば、企業内ネットワークにおいて、ある２点間の通信異常が観測されたが、その２点の間には、顧客向け業務等に用いられる重要度の高いネットワークと、異常時の予備等で使われている重要度の低いネットワークが存在する場合を想定する。

障害発生箇所が重要度の高いネットワークの機器にある場合は、この障害は業務に影響を与えるため、早急に対処しなければならないが、重要度の低いネットワークの機器に障害が発生した場合は影響範囲は限定され、対処を遅らせても構わない場合が多い。

このような場合、２点間の通信異常という情報だけでは、ネットワーク管理者はその障害が重要度の高いネットワークで発生しているかどうかを判断できない。実際には影響範囲が狭く、緊急ではない障害であったとしても、重大な障害である可能性を考慮して早急に対処し、結果として過大に労力を費やす結果となる場合がある。

なお、ネットワーク障害発生時に、ネットワークの構成要素から発せられる警報情報に基づいて故障箇所を特定するネットワークシステムも知られている（例えば、特許文献１参照）。
日本特許出願公開 特開２００３−１７９６０１号公報

本発明の課題は、通信ネットワークにおいて通信異常が発生した場合に、その原因となる障害が発生した可能性のある箇所を自動的に絞り込むことにより、通信異常という問題を短時間で解決することである。

本発明の障害発生箇所特定装置は、格納部および判定部を備える。格納部は、複数のノードからなる通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、その通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる１つ以上のリンクを示す経路情報とを格納する。判定部は、通信ネットワーク上で通信異常が発生したとき、リンク情報および経路情報を参照しながら、通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、残されたリンクまたは残されたリンクの両端のノードを障害発生箇所候補と判定する。

このような障害発生箇所特定装置によれば、通信異常が発生したとき、障害が発生した可能性のある箇所を特定のリンクまたはノードの範囲に自動的に絞り込むことが可能になる。

格納部は、例えば、後述する図１８のメモリ１８０２または外部記憶装置１８０５に対応し、判定部は、例えば、後述する図１０の障害発生箇所判定部に対応する。

以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本実施形態では、通信ネットワークのトポロジおよび経路情報に基いて、障害発生箇所を絞り込む。トポロジとは、ネットワークを構成する機器同士の物理的・論理的な接続構成を意味する。

この場合、監視対象のネットワークにおける最新の「リンク情報」および「経路情報」があらかじめ用意されている必要がある。「リンク情報」とは、ネットワーク上の各機器の物理的な接続関係を示す情報であり、「経路情報」はネットワーク上の２点間の物理レベルを含む通信経路を示す情報である。

「リンク情報」と「経路情報」は、例えば、先に出願された日本特許出願（特願２００４−１６４７７８号）に記載された「トポロジ探索技術」および「経路探索技術」により定期的・自動的に取得することが可能である。そこで、まず、この「トポロジ探索技術」および「経路探索技術」の概要について、図４から図８までを参照しながら説明する。

（１）トポロジ探索技術
本技術は、物理レイヤからアプリケーションレイヤまでのすべてのレイヤを統合したトポロジを表現するモデルに基き、ＳＮＭＰ−ＭＩＢ（Management Information Base ）等を用いて各ネットワーク機器から各レイヤに関する情報を自動的に収集・分析することにより、各レイヤにまたがるネットワークトポロジをシステムが把握し、これをマップとして描画・表示するものである。これにより、従来は困難であったすべてのレイヤについてのトポロジ把握を容易に行うことができる。

特に、障害発生箇所絞り込み技術へ適用するにあたっては、物理レイヤにおけるトポロジ探索により「リンク情報」が取得できること、すなわち、各機器のどのポートとどのポートとがつながっているか、というレベルにおいて接続関係を把握することができることが、本技術の重要な点である。

実験に基いた見積によれば、本技術を実装したプログラムを用いると、１０００台程度の機器から構成されるネットワークのトポロジ探索結果をおよそ６０分以内に出力できると考えられる。この技術を定期的に、例えば毎日用いることにより、ネットワーク管理者は１日単位で物理レイヤを含む最新のネットワークトポロジを把握することができる。

図４は、トポロジ探索技術を実装したトポロジ探索部を示している。図４のトポロジ探索部４０２は、ノード検知部４１１、トポロジ情報取得部４１２、およびトポロジ構築部４１３を備え、以下の手順で、監視対象となるネットワークを構成する機器同士の物理的・論理的接続を求める。

１．ノード検知部４１１は、探索対象のネットワーク４０１のＩＰアドレスの範囲（探索範囲）と各機器のアカウント情報からなる入力情報４２１を受け取る。そして、探索範囲に対してｐｉｎｇによる探索を試みて、ネットワーク４０１を構成する機器（ノード）を検出し、検出されたノードのリスト４１４を生成する。
２．トポロジ情報取得部４１２は、ＳＮＭＰ、ｔｅｌｎｅｔ、またはｓｓｈ（Secure Shell）を用いて、検出されたネットワーク機器の設定やサービスの情報を取得する。情報取得に必要な各機器のアカウント情報は、ノード検知部４１１から受け取る。
３．トポロジ構築部４１３は、取得された情報から機器同士の物理的・論理的接続関係を求め、様々な目的に利用できる形式のトポロジデータベースとして保存する。トポロジ探索部４０２からの出力情報４２２には、各機器の設定情報やリンク情報が含まれる。

トポロジ構築部４１３は、各機器におけるメディアアクセス制御（Media Access Control，ＭＡＣ）学習テーブルを取得し、機器毎のＭＡＣ学習テーブルの内容を照合することで、機器間の物理的な接続関係を把握する。ＭＡＣ学習テーブルには、送信先ＭＡＣアドレスと送信元ポートの対応関係が記録されている。

図５は、探索対象のネットワークにおける物理接続の例を示している。このネットワークは、スイッチ５０１〜５０３およびパーソナルコンピュータ（ＰＣ）５０４〜５１５からなる。

スイッチ５０１（スイッチα）はポート１〜５を有し、ポート１、２、３、および４には、パーソナルコンピュータ５０４、５０５、５０６、および５０７がそれぞれ接続されており、ポート５にはスイッチ５０２が接続されている。

スイッチ５０２（スイッチβ）はポート１〜６を有し、ポート１、２、３、および４には、パーソナルコンピュータ５０８、５０９、５１０、および５１１がそれぞれ接続されており、ポート５および６には、スイッチ５０１および５０３がそれぞれ接続されている。

スイッチ５０３（スイッチγ）はポート１〜５を有し、ポート１、２、３、および４には、パーソナルコンピュータ５１２、５１３、５１４、および５１５がそれぞれ接続されており、ポート５にはスイッチ５０２が接続されている。

パーソナルコンピュータ５０４、５０５、５０６、５０７、５０８、５０９、５１０、５１１、５１２、５１３、５１４、および５１５のＭＡＣアドレスは、それぞれＡ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇ、Ｈ、Ｉ、Ｊ、Ｋ、およびＬである。

スイッチ５０１、５０２、および５０３は、スイッチングサービスを行うために、図６に示すようなＭＡＣ学習テーブル６０１、６０２、および６０３をそれぞれ持っている。これらのＭＡＣ学習テーブルには、ポート毎に、学習されたパーソナルコンピュータ５０４〜５１５のＭＡＣアドレスが登録されている。

例えば、スイッチαのポート５については、スイッチβ配下の４台のＰＣのＭＡＣアドレスＥ、Ｆ、Ｇ、およびＨが学習されており、スイッチβのポート５については、スイッチα配下の４台のＰＣのＭＡＣアドレスが学習されている。この情報から、スイッチαのポート５とスイッチβのポート５とが接続されていると推測できる。このように、スイッチのＭＡＣ学習テーブルから、スイッチ同士の接続や、スイッチ−ＰＣ間の接続を求めることが可能である。

スイッチ５０１〜５０３およびパーソナルコンピュータ５０４〜５１５の機器設定情報が入力されたとき、トポロジ構築部４１３は、以下の手順でリンク情報を求める。
トポロジ構築部４１３は、まず、スイッチの機器設定情報からＭＡＣ学習テーブル６０１、６０２、および６０３を抽出し、それらのＭＡＣ学習テーブルを参照してスイッチ間の物理接続を探索する。

隣接する２台のスイッチ間においては、互いを繋ぐポートについて学習されるＭＡＣアドレスは、隣接するスイッチの、互いを繋ぐポート以外のポートについて学習されたＭＡＣアドレスの総和である。

トポロジ構築部４１３は、ネットワーク内の全スイッチのＭＡＣアドレス学習テーブルを調査し、スイッチの各ポートについて学習されているＭＡＣアドレスの、ポートを単位とする論理和を用いた比較が成立するか否かを判定して、スイッチ同士の物理接続を求める。

次に、トポロジ構築部４１３は、パーソナルコンピュータ５０４〜５１５のＭＡＣアドレスと、スイッチ間の物理接続の探索結果から、スイッチと各パーソナルコンピュータの物理接続を探索する。このとき、各スイッチのＭＡＣ学習テーブル内の、スイッチ同士の接続に使用されていないポートのうち、ネットワーク内のスイッチ以外の機器（パーソナルコンピュータ）のＭＡＣアドレスを学習しているポートを探索し、該当するポートとパーソナルコンピュータの間の物理接続を求める。

こうして物理接続の情報（リンク情報）が得られると、トポロジ構築部４１３は、リンク情報と各機器の設定情報を用いてレイヤ別のトポロジ探索処理を行い、複数レイヤにわたるトポロジを求める。

このとき、設定情報を用いて複数のレイヤの中の下位レイヤのトポロジに含まれる物理接続または論理接続をグループ化して、上位レイヤにおける情報到達範囲を生成し、その情報到達範囲から上位レイヤのトポロジを生成する。このような処理を物理レイヤ、ＭＡＣレイヤ、ＩＰレイヤ、ＴＣＰ／ＵＤＰ（Transmission Control Protocol/User Datagram Protocol）レイヤ、およびアプリケーションレイヤの順に繰り返すことで、複数レイヤにわたるトポロジが生成される。
（２）経路探索技術
本技術は、探索対象となる経路の始点および終点の機器（ノード）と、トポロジ探索技術の出力結果であるトポロジデータベースをもとに、始点ノードから隣接ノードを経由して終点ノードまで接続されているネットワーク内の２点間の経路を算出するものである。

これにより、ネットワークの２点間の通信における「経路情報」を、ＩＰレイヤだけでなくＭＡＣレイヤまで（通過するＬ２スイッチ等の情報まで）のネットワーク機器のレベルで把握することが可能である。具体的には、以下の手順で経路探索を行う。

１．ＩＰレイヤのネクストホップ取得
始点ノードから終点ノードに向かうための、ＩＰレイヤにおけるネクストホップのＩＰアドレスを、始点ノードのルーティング情報から取得する。
２．ＭＡＣレイヤのネクストホップ取得
始点ノードのＭＡＣ学習テーブルをもとに、ネクストホップのＩＰアドレスに向かうための、ＭＡＣレイヤにおけるネクストホップのＭＡＣアドレスを取得する。トポロジ探索技術により得られているリンク情報を参照し、ＭＡＣレイヤでのネクストホップとなる機器を決定する。
３．始点ノードの代わりにネクストホップとなる機器に対して、２のＭＡＣレイヤのネクストホップ取得を繰り返し、ＭＡＣレイヤでの経路情報の取得を続ける。これを繰り返してＩＰレイヤでのネクストホップの機器に辿り着いたら、１のＩＰレイヤのネクストホップ取得を繰り返して、ＩＰレイヤにおいてその次のホップとなる機器を決定する。以上の処理を、終点ノードのＩＰアドレスに辿り着くまで繰り返す。

図７は、このような経路探索技術を実装したトポロジ探索装置を示している。図７のトポロジ探索装置７０１は、図４のトポロジ探索部４０２と経路探索部７１１を備える。経路探索部７１１は、次経路判定部７２１および動的情報算出部７２２を備え、探索対象情報７２３および次探索対象情報７２４を保持する。

経路探索部７２１は、各機器の設定情報７５１、複数レイヤにわたるトポロジ７５２、および探索条件７５３を入力として経路探索処理を行い、データ通過経路７５４を経路情報として出力する。

トポロジ７５２は、リンク情報に対応する物理レイヤのトポロジ７６１、ＭＡＣレイヤのトポロジ７６２、ＩＰレイヤのトポロジ７６３、ＴＣＰ／ＵＤＰレイヤのトポロジ７６４、およびアプリケーションレイヤのトポロジ７６５からなり、探索条件７５３は、始点および終点となるネットワーク内の２点７７１およびサービスの種類７７２の情報を含む。ネットワーク内の２点７７１は、ノード名やＩＰアドレス等により指定される。

探索対象情報７２３は、現在のコネクタ７３１および直前のコネクタ７３２の情報を含み、次探索対象情報７２４は、上位レイヤのコネクタ７４１および下位レイヤのコネクタ７４２の情報を含む。また、データ通過経路７５４は、データが通過したコネクタ７８１−１〜７８１−ｎの情報を含む。

各レイヤにおいて、機器間の物理・論理接続に使用される物理・論理インタフェースは「コネクタ」で表され、通信の終端を行ったり、機器内の複数コネクタ間でデータの転送を行う機能は「サービス」で表される。

図８は、現在のコネクタ７３１、直前のコネクタ７３２、上位レイヤのコネクタ７４１、下位レイヤのコネクタ７４２、およびコネクタ７８１−１〜７８１−ｎの各コネクタ情報のデータ構造を示している。図８のコネクタ情報８０１は、該当するコネクタが属する機器名８１１、レイヤの識別情報８１２、および同一レイヤ内でコネクタを一意に識別するためのコネクタ識別子８１３を含む。

次経路判定部７２１は、現在の探索対象の情報を探索対象情報７２３に保持し、次の探索対象の情報を次探索対象候補７２４に保持しながら、設定情報７５１、トポロジ７５２、および探索条件７５３を用いてネクストホップの取得を繰り返す。そして、始点ノードから終点ノードに至るコネクタの情報を、データ通過経路７５４として出力する。動的情報算出部７２２は、次経路判定部７２１により宛先が得られない場合、または名前解決等の方法により宛先を取得する必要がある場合に、動的に宛先を求める。

本実施形態では、上述した（１）トポロジ探索および（２）経路探索を定期的に実施することにより、監視対象となるネットワークのリンク情報と、ネットワーク内の複数の始点・終点の組み合わせに対する経路情報をあらかじめ取得しておく。また、運用管理サーバを設けるとともに、監視対象のネットワーク上の複数のノードに監視エージェントを配置する。

図９は、本実施形態のネットワークシステムの例を示している。図９のシステムは、以下の機器からなる。
・スイッチ：ＳＷ−ａ、ＳＷ−ｂ、ＳＷ−ｃ、ＳＷ−ｄ、ＳＷ−ｅ、ＳＷ−ｆ
・ファイアウォール：ＦＷ−ａ、ＦＷ−ｂ
・サーバ負荷分散装置：ＳＬＢ−ａ、ＳＬＢ−ｂ
・Ｗｅｂサーバ：ＷＥＢ−ａ、ＷＥＢ−ｂ
・アプリケーションサーバ：ＡＰ−ａ、ＡＰ−ｂ
・運用管理サーバ９０１
このうち、ＷＥＢ−ａ、ＷＥＢ−ｂ、ＡＰ−ａ、およびＡＰ−ｂに、それぞれ監視エージェント９０２、９０３、９０４、および９０５が配置されている。

運用管理サーバ９０１は、異常通信が発生したとき、その通信の経路情報と他の正常通信の経路情報とを照合する。そして、異常通信の経路に含まれる各リンクのうち、他の正常通信の経路に含まれていないものを抽出し、そのリンクおよび両端のポートを障害発生箇所候補として出力する。

例えば、ＷＥＢ−ｂからＡＰ−ａへの通信とＷＥＢ−ａからＡＰ−ｂへの通信がともに正常で、ＷＥＢ−ｂからＡＰ−ｂへの通信において異常が発生した場合、以下のリンクおよびポートが障害発生箇所候補として求められる。
・ＳＬＢ−ｂとＳＷ−ｆの間のリンク９０６
・ＳＬＢ−ｂのポート９０７（ＳＷ−ｆ向け）
・ＳＷ−ｆのポート９０８（ＳＬＢ−ｂ向け）

図１０は、図９の運用管理サーバ９０１および監視エージェント９０２〜９０５の機能ブロック図である。運用管理サーバ９０１は、図４のトポロジ探索部４０２および図７の経路探索部７１１に加えて、ノードペア抽出部１０１１、通信可否調査部１０１２、障害発生箇所判定部１０１３、および結果表示部１０１４を備える。監視エージェント１００１は、監視エージェント９０２〜９０５に対応し、通信監視部１０３１、通信異常通知部１０３２、抽出部１０３３、および通信試行部１０３４を備える。

運用管理サーバ９０１のトポロジ探索部４０２および経路探索部７１１は、トポロジ探索および経路探索を定期的に実施することにより、監視対象のネットワークの最新（例えば、最近１日以内）のリンク情報１０２１および複数のノードペアに対する経路情報１０２２を取得する。これらの情報は、運用管理サーバ９０１内に保持される。

監視エージェント１００１の通信監視部１０３１は、常時、他のノード（事前に経路情報が判明しているノード）との間の通信を監視し、ログ１０４１を生成する。ログ１０４１には、通信先ＩＰアドレスと通信可否の情報が一定期間蓄積される。通信監視部１０３１が他のノードとの間での通信の異常を検知すると、通信異常通知部１０３２は、その旨を運用管理サーバ９０１に通知する。

運用管理サーバ９０１のノードペア抽出部１０１１は、通信可否調査対象のノードペアを抽出する。通信可否調査対象としては、例えば、経路情報が判明しているすべてのノードペアが抽出される。通信可否調査部１０１２は、監視対象のネットワーク上に配置された各監視エージェント１００１に対して、抽出されたノードペアの通信可否を問い合わせる。

これを受けて、監視エージェント１００１は、以下の２つの方法のいずれかを用いて、指示された各ノードペアに対する通信可否の情報を取得し、運用管理サーバ９０１に回答を送信する。

（ａ）通信試行部１０３４は、運用管理サーバ９０１からの問い合わせを契機として、ノードペアに含まれる宛先ノードへの通信を試行する。
（ｂ）抽出部１０３３は、ログ１０４１を参照して、ノードペアに含まれる宛先ノードとの通信の可否を取得する。この場合、通信可否調査部１０１２は、監視エージェント１００１に対して調査すべき時間帯を指示し、抽出部１０３３は、その時間帯に宛先ノードと通信できていたか否かをチェックする。調査すべき時間帯としては、通信異常発生時刻の前後の一定時間等が指定される。

例えば、Ｗｅｂ−ｂからＡＰ−ｂへの通信で１０時３５分２０秒に異常が発生した場合、Ｗｅｂ−ａの監視エージェント９０２は、ログ１０４１を参照して、Ｗｅｂ−ａからＡＰ−ａへの通信またはＷｅｂ−ａからＡＰ−ｂへの通信において、１０時３４分５０秒から１０時３５分５０秒の時間帯に成功／失敗の事例があるか否かをチェックする。そのような事例があれば、それを回答として運用管理サーバ９０１に通知する。

次に、運用管理サーバ９０１の障害発生箇所判定部１０１３は、リンク情報１０２１、経路情報１０２２、および現時点での通信可否の情報をもとに、通信経路を構成するリンクのいずれか１箇所でも通信を妨げるような障害が存在すれば、その通信は正常に行われないとの認識に基き、異常の原因となる障害発生箇所を絞り込む。

障害発生箇所判定部１０１３は、通信に異常があるノードペアに対し、その経路となるリンクを１つ１つ抽出し、そのリンクが他の正常通信が可能なノードペアの経路に含まれているか否かをチェックする。そして、正常通信の経路に含まれていないリンクの集合と、各リンクの両端にあるポートの集合を、障害発生箇所候補に決定する。

結果表示部１０１４は、障害発生箇所候補の情報を画面表示することで、処理結果を管理者に通知する。例えば、監視対象のネットワークを描いた画面上に、障害発生箇所候補となる機器およびリンクを色を変えて表示することで、障害発生箇所候補が容易に認識できるようになる。

また、処理結果を再利用できるように、異常発生時刻、異常が発生した経路、障害発生箇所候補、および障害発生箇所の情報が、障害情報１０２３として運用管理サーバ９０１内に保存される。結果表示部１０１４は、保存された障害情報１０２３を参照することで、過去のある時点でのネットワークの状態を再表示することができる。

このようなシステムによれば、ノード間で通信異常が発生した場合に、その通信異常の原因となる障害発生箇所を、あらゆる可能な通信経路の中で、実際に通信が行われた経路で、かつ、他の正常通信では使われない部分に、絞り込むことができる。

絞り込みの精度は、ネットワーク上における監視エージェントの設置数（密度）に依存する。より多くの監視エージェントを設置して多数のノードペアに対する通信可否の情報を取得するほど、通信異常時の障害発生箇所をより狭い範囲に絞り込める。このような絞り込み方法は、監視対象のネットワーク上に同時に発生した障害が１箇所または複数箇所である場合に適用可能である。

ところで、異常通信が発生したとき、常に他のすべてのノードペアについて通信可否を調査すると、調査対象が多すぎて処理効率が低下することが考えられる。そこで、以下の手順で通信可否調査対象を絞り込むことが好ましい。

１．管理者は、
事前に、トポロジ的または役割的に近いサーバ同士をグルーピングし、サーバグループとして運用管理サーバ９０１に登録しておく。
２．ノードペア抽出部１０１１は、通信異常が発生したノードペアの各ノードが属するサーバグループを調べ、それらのサーバグループ間でペアを構成するような２つのノードを、通信可否調査対象として抽出する。

例えば、図１１に示すように、Ｗｅｂ−ａおよびＷｅｂ−ｂをＷｅｂサーバグループ１１０１として登録し、ＡＰ−ａおよびＡＰ−ｂをＡＰサーバグループ１１０２として登録しておく。Ｗｅｂ−ｂからＡＰ−ｂへの通信で異常が発生したとき、Ｗｅｂサーバグループ１１０１のノードとＡＰサーバグループ１１０２のノードがペアを構成するように、以下のノードペアが抽出される。
・Ｗｅｂ−ａとＡＰ−ａ
・Ｗｅｂ−ａとＡＰ−ｂ
・Ｗｅｂ−ｂとＡＰ−ａ

そして、Ｗｅｂ−ａからＡＰ−ａへの通信、Ｗｅｂ−ａからＡＰ−ｂへの通信、およびＷｅｂ−ｂからＡＰ−ａへの通信の可否が調査される。Ｗｅｂ−ｂとＡＰ−ｂのノードペアは、通信異常が発生したノードペアに相当するため、調査対象からは除外される。

次に、図１２から図１７までを参照しながら、図９のネットワークシステムにおける障害発生箇所絞り込み処理について、より詳細に説明する。
図１２は、図９の監視対象のネットワークに含まれる各機器のインタフェース（コネクタ）の識別子を示している。これらの機器のインタフェース識別子は、以下の通りである。

ＳＷ−ａ、ＳＷ−ｂ、ＳＷ−ｃ、ＳＷ−ｄ、ＳＷ−ｅ、ＳＷ−ｆ：ｐｏｒｔ１〜ｐｏｒｔ６
ＦＷ−ａ、ＦＷ−ｂ、ＳＬＢ−ａ、ＳＬＢ−ｂ：ｐｏｒｔ１〜ｐｏｒｔ４
ＷＥＢ−ａ、ＷＥＢ−ｂ、ＡＰ−ａ、ＡＰ−ｂ：ｅｔｈ０、ｅｔｈ１

図１３および１４は、図１２のネットワークに対するリンク情報および経路情報の例を示している。図１３のリンク情報には、物理レイヤのトポロジとして、各リンクの識別子（接続ＩＤ）と、リンクの両端にあるノードの識別子と、そのノードのコネクタの識別子が含まれている。例えば、接続ＩＤ“１”を有するリンクは、ノード“ＷＥＢ−ａ”のコネクタ“ｅｔｈ０”とノード“ＳＷ−ａ”のコネクタ“ｐｏｒｔ１”を接続するリンクであることが分かる。

図１４の経路情報は、ＷＥＢ−ｂと始点とし、ＡＰ−ｂを終点とする経路の情報に相当し、始点に近い方から順に、経路を構成するリンクの接続ＩＤ、リンクの両端にあるノードの識別子、およびそのノードのコネクタの識別子が記録されている。

図１５は、通信異常発生時のネットワークの状態を示している。例えば、ＷＥＢ−ｂを始点とし、ＡＰ−ｂを終点とする通信の異常が検知され、他の経路での通信が試行された結果、ＷＥＢ−ａからＡＰ−ｂへの通信とＷＥＢ−ｂからＡＰ−ａへの通信は正常であることが判明する。この場合、障害発生箇所判定部１０１３は、図１６に示すような判定処理データを生成し、図１７に示すフローチャートに従って障害発生箇所絞り込み処理を行う。

図１６の判定処理データには、通信異常が発生した経路を構成する各リンクについて、以下の情報が登録される。
・接続ＩＤ
・リンク始点：リンクの始点のノードおよびコネクタの識別子
・リンク終点：リンクの終点のノードおよびコネクタの識別子
・ＷＥＢ−ｂ→ＡＰ−ｂの経路に含まれるか否か
・ＷＥＢ−ｂ→ＡＰ−ａの経路に含まれるか否か
・ＷＥＢ−ａ→ＡＰ−ｂの経路に含まれるか否か
・障害発生箇所候補であるか否か

黒丸のマーク●は、リンクが対応する経路に含まれることを表し、黒星のマーク★は、リンクおよびコネクタが障害発生箇所候補であることを表す。接続ＩＤ、リンク始点、およびリンク終点の情報は、図１３のリンク情報から取得され、リンクが経路に含まれるか否かの情報は、図１４の経路情報から取得される。図１６の判定処理データには、さらに、各経路の通信可否の情報も登録されている。

障害発生箇所判定部１０１３は、まず、経路情報に含まれる異常または正常と判明した各通信の経路を参照し（ステップ１７０１）、１つ以上の異常通信の経路に含まれるリンクを抽出する（ステップ１７０２）。そして、抽出されたリンクに関する判定処理データを生成し、各リンクに対して障害発生箇所候補になるか否かの判定を開始する（ステップ１７０３）。

まず、判定処理データを参照しながら、１番目のリンクが１つ以上の正常通信の経路に含まれているか否かをチェックする（ステップ１７０４）。そして、そのリンクがいずれの正常通信の経路にも含まれていなければ、当該リンクとその両端のコネクタを障害発生箇所候補とみなして、判定処理データの対応する行に黒星のマークを付ける（ステップ１７０５）。そのリンクがいずれかの正常通信の経路に含まれていれば、当該リンクとその両端のコネクタを障害発生箇所候補から除外する（ステップ１７０６）。

次に、すべてのリンクを判定したか否かをチェックし（ステップ１７０７）、未判定のリンクがあれば、次のリンクを選択してステップ１７０３以降の処理を繰り返す（ステップ１７０８）。そして、未判定のリンクがなくなれば、処理を終了する。

図１５の例では、通信異常が発生した「ＷＥＢ−ｂ→ＡＰ−ｂ」の経路に含まれるリンクが抽出され、図１６に示した判定処理データが生成される。そして、抽出されたリンクのうち、他の正常通信の経路である「ＷＥＢ−ｂ→ＡＰ−ａ」および「ＷＥＢ−ａ→ＡＰ−ｂ」に含まれるリンクが障害発生箇所候補から除外される。こうして、残された接続ＩＤ“２４”のリンクと、その両端のコネクタに相当するＳＬＢ−ｂのｐｏｒｔ４とＳＷ−ｆのｐｏｒｔ２が、通信異常の原因となる障害発生箇所の候補と判定される。

以上説明した実施形態では、通信機能の階層構成として物理レイヤ、ＭＡＣレイヤ、ＩＰレイヤ、ＴＣＰ／ＵＤＰレイヤ、およびアプリケーションレイヤの５つのレイヤを想定しているが、本発明はこの階層構成に限らず、他の階層構成にも同様に適用可能である。

ところで、図７のトポロジ探索装置７０１および図９の運用管理サーバ９０１、Ｗｅｂサーバ９０２、９０３、アプリケーションサーバ９０４、９０５は、例えば、図１８に示すような情報処理装置（コンピュータ）を用いて構成される。図１８の情報処理装置は、ＣＰＵ１８０１、メモリ１８０２、入力装置１８０３、出力装置１８０４、外部記憶装置１８０５、媒体駆動装置１８０６、ネットワーク接続装置１８０７を備え、それらはバス１８０８により互いに接続されている。

メモリ１８０２は、例えば、ＲＯＭ（read only memory）、ＲＡＭ（random access memory）等を含み、処理に用いられるプログラムおよびデータを格納する。ＣＰＵ１８０１は、メモリ１８０２を利用してプログラムを実行することにより、必要な処理を行う。

図１０のトポロジ探索部４０２、経路探索部７１１、ノードペア抽出部１０１１、通信可否調査部１０１２、障害発生箇所判定部１０１３、結果表示部１０１４、および監視エージェント１００１は、メモリ１８０２に格納されたプログラムに対応する。また、図１０のリンク情報１０２１、経路情報１０２２、障害情報１０２３、ログ１０４１および図１６の判定処理データは、メモリ１８０２に格納されたデータに対応する。

入力装置１８０３は、例えば、オペレータからの指示や情報の入力に用いられる。出力装置１８０４は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果等の出力に用いられる。

外部記憶装置１８０５は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置１８０５に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１８０２にロードして使用する。外部記憶装置１８０５は、リンク情報１０２１、経路情報１０２２、障害情報１０２３、およびログ１０４１を保存するデータベースとしても使用される。

媒体駆動装置１８０６は、可搬記録媒体１８０９を駆動し、その記録内容にアクセスする。可搬記録媒体１８０９は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体１８０９にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ１８０２にロードして使用する。

ネットワーク接続装置１８０７は、通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置１８０７を介して受け取り、それらをメモリ１８０２にロードして使用する。

図１９は、図１８の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体１８０９やサーバ１９０１のデータベース１９１１に格納されたプログラムおよびデータは、情報処理装置１９０２のメモリ１８０２にロードされる。サーバ１９０１は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置１９０２に送信する。ＣＰＵ１８０１は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。

本発明によれば、ネットワーク運用管理における障害発生時の復旧において、以下の効果が得られる。

（１）通信異常の原因となる障害が発生した可能性のある箇所を絞り込むことにより、原因究明および復旧作業をより短時間で行うことができる。

前述したように、従来は、ネットワーク上の２点間の通信に異常があった場合、考えられる障害発生箇所は、その２点間のすべての可能な経路上にある、すべての機器・リンクであった。

これに対して、本発明によれば、考えられる障害発生箇所を、実際にその２点間で通信が行われた経路上にある機器・リンクのうち、他で確認された正常通信のデータが通過していない部分にまで絞り込むことができる。このため、原因究明のために調査対象とする機器を減らすことができ、復旧作業の短期化につながる。

（２）通信異常発生時に、その問題の影響範囲および業務上の緊急性の把握ができる可能性が高くなる。

（１）の絞り込みの結果、障害発生箇所である可能性のある場所の範囲が、重要度の低いネットワーク内に絞り込まれれば、業務に影響を与えない程度の影響範囲であると判断できる。その結果、前述したような、緊急ではない障害に対して過大な労力を費やすことが、回避される。

従来のネットワークシステムにおける運用管理サーバによる通信試行を示す図である。 従来のネットワークシステムにおけるエージェントによる通信試行を示す図である。 従来のネットワークシステムにおける通信異常の発生を示す図である。 トポロジ探索部の構成図である。 物理接続を示す図である。 ＭＡＣ学習テーブルを示す図である。 トポロジ探索装置の構成図である。 コネクタのデータ構造を示す図である。 本発明のネットワークシステムを示す図である。 運用管理サーバおよび監視エージェントの機能ブロック図である。 サーバのグルーピングを示す図である。 各機器のインタフェース識別子を示す図である。 リンク情報を示す図である。 経路情報を示す図である。 通信異常発生時のネットワークの状態を示す図である。 判定処理データを示す図である。 障害発生箇所絞り込み処理のフローチャートである。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。

Claims (10)

1. 複数のノードからなる通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる１つ以上のリンクを示す経路情報とを格納する格納部と、
   前記通信ネットワーク上で通信異常が発生したとき、前記リンク情報および経路情報を参照しながら、該通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する判定部と
   を備えることを特徴とする障害発生箇所特定装置。
2. 複数のノードからなる通信ネットワーク上で通信異常が発生したとき、格納部に格納された、該通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる１つ以上のリンクを示す経路情報とを参照し、
   前記通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外し、
   残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する
   処理をコンピュータに実行させることを特徴とするプログラム。
3. 前記通信ネットワークから各ノードに対応する機器の設定情報を取得し、該設定情報から、前記リンク情報と、始点ノードと終点ノードの複数の組み合わせに対する前記経路情報とを生成して、前記格納部に格納する処理を、前記コンピュータにさらに実行させることを特徴とする請求項２記載のプログラム。
4. 前記設定情報に含まれる、各機器の各インタフェースのメディアアクセス制御アドレスの情報を用いて、前記リンク情報を生成する処理を、前記コンピュータに実行させることを特徴とする請求項３記載のプログラム。
5. 前記設定情報を用いて、前記通信ネットワークの通信機能の階層構成を表す複数のレイヤの中の下位レイヤのトポロジに含まれる接続をグループ化して、上位レイヤにおける情報到達範囲を生成し、該情報到達範囲から上位レイヤのトポロジを生成する処理を繰り返して、各レイヤのトポロジを生成し、該設定情報と各レイヤのトポロジの情報を用いて前記経路情報を生成する処理を、前記コンピュータに実行させることを特徴とする請求項３または４記載のプログラム。
6. 前記通信異常が発生したとき、前記通信ネットワーク上のノードに対して、経路情報が判明しているノード間の通信可否を問い合わせ、回答として受け取った通信可否の情報をもとに、前記通信可能なノード間の通信経路を決定する処理を、前記コンピュータにさらに実行させることを特徴とする請求項２記載のプログラム。
7. 前記通信ネットワーク上の複数のノードをグルーピングして前記格納部に登録し、前記通信異常が発生した通信経路の始点ノードが属するグループと、該通信経路の終点ノードが属するグループの間でノードペアを構成するような２つのノードを、通信可否調査対象として抽出する処理を、前記コンピュータにさらに実行させることを特徴とする請求項６記載のプログラム。
8. 前記通信ネットワークを描いた画面上に、前記障害発生箇所候補と判定されたリンクまたはノードの情報を表示する処理を、前記コンピュータにさらに実行させることを特徴とする請求項２記載のプログラム。
9. 前記障害発生箇所候補の情報を前記格納部に保存しておき、過去のある時点での前記通信ネットワークの状態を再表示する処理を、前記コンピュータにさらに実行させることを特徴とする請求項８記載のプログラム。
10. 判定部が、複数のノードからなる通信ネットワーク上で通信異常が発生したとき、格納部に格納された、該通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる１つ以上のリンクを示す経路情報とを参照し、
    前記判定部が、前記通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外し、
    前記判定部が、残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する
    ことを特徴とする障害発生箇所特定方法。

Images