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

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

Info

Publication number
JP4345987B2
JP4345987B2 JP2006542186A JP2006542186A JP4345987B2 JP 4345987 B2 JP4345987 B2 JP 4345987B2 JP 2006542186 A JP2006542186 A JP 2006542186A JP 2006542186 A JP2006542186 A JP 2006542186A JP 4345987 B2 JP4345987 B2 JP 4345987B2
Authority
JP
Japan
Prior art keywords
communication
information
link
nodes
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006542186A
Other languages
English (en)
Other versions
JPWO2006046309A1 (ja
Inventor
卓哉 羽生
由紀 海野
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2006046309A1 publication Critical patent/JPWO2006046309A1/ja
Application granted granted Critical
Publication of JP4345987B2 publication Critical patent/JP4345987B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0654Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06Management of faults, events, alarms or notifications
    • H04L41/0677Localisation of faults
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/02Topology update or discovery
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/22Alternate routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/24Multipath
    • H04L45/247Multipath using M:N active or standby paths
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/28Routing or path finding of packets in data switching networks using route fault recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Monitoring And Testing Of Transmission In General (AREA)

Description

本発明は、企業内ネットワーク、あるいはインターネットデータセンタ(IDC)の環境等におけるネットワークシステムの運用管理の分野に係り、通信に異常が発生した場合に、その異常の原因となる障害がネットワーク上のどこで発生したのかについて、その可能性のある箇所を自動的に絞り込む装置および方法に関する。
ネットワーク運用管理における障害検知の分野においては、ネットワーク上のある2点間において、定期的に通信を試み、その通信が正常に行われることを確認することで、ネットワークの状態を監視している。
図1は、このようなネットワークシステムの例を示している。図1において監視対象となるネットワーク101は、以下の機器および広域IP(Internet Protocol )通信ネットワーク116からなる。
・拠点ルータ111〜115
・ルータ117、118
・スイッチ(SW)119、120、123、124、127、128、133、134、137、138、141、142、147、148
・ファイアウォール121、122、135、136
・サーバ負荷分散装置(Server Load Balancer)125、126、139、140
・Webサーバ129〜132
・アプリケーションサーバ143〜146
・データベースサーバ149、150
この場合、広域IP通信ネットワーク116は、IP−VPN(Virtual Private Network )として機能する。2点間の通信試行とその結果となるデータの蓄積を実現する方法としては、以下の2つの方法がある。
(a)図1に示すように、ネットワーク上のある地点に運用管理サーバ102を設置する。そして、運用管理サーバ102からスイッチ151〜155を介して、監視対象となるネットワーク101内の各ノード(機器)に対して定期的に通信を試み、ping(Packet INternet Groper)/SNMP(Simple Network Management Protocol)等を用いて通信の可否および状態をチェックする。通信の経路は意識しない。運用管理サーバ102にチェック結果のデータを蓄積し、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者103に通知する。
(b)図2に示すように、ネットワーク101内の複数のノード118、132、145、および149に通信監視用のエージェントプログラムをインストールする。そして、エージェント間で通信を試み、通信の可否および状態をチェックして、その結果を運用管理サーバ102に転送する。運用管理サーバ102は、転送されたチェック結果を、ネットワーク図上で異常のある機器を表示する等の方法で、ネットワーク管理者103に通知する。この場合、エージェントがインストールされたノードペア間の通信経路の情報は管理されない。
(a)および(b)のいずれの方法においても、運用管理サーバ102により、試行した通信において異常があると判断されると、当該ノードについてネットワーク通信が異常であることが、イベント通知を画面に表示する等の方法でネットワーク管理者103に通知される。
ただし、いずれの方法においても、判明するのは「ある2点間」での通信がある時点で正常に動作しているか否かであり、その2点の間の通信経路は運用管理サーバ102によって把握されていない。このようなネットワーク障害検知の方法には、以下のような問題が存在する。
(1)ある2点間の通信に異常があった場合に、その2点間のうちどの部分の障害に起因する異常であるのかが分からないという問題がある。
そもそもネットワーク障害検知は、ネットワーク障害発生時に早期に復旧することにより通信異常の発生期間を短縮するのが大きな目的であるが、早期の復旧のためには通信異常の原因の究明、すなわち障害発生箇所の特定を短時間で行うことが重要である。
ネットワーク通信においては、通信経路のいずれか一箇所でも通信を妨げるような異常が存在すれば、その通信は正常に行われないのが普通である。逆に言えば、多数のネットワーク機器をまたがった2つの機器の間における通信に異常が発生した場合、その原因となる障害が発生した可能性のある機器は、その2点のノードもしくはその中間にあるすべてのネットワーク機器という広範囲にわたる。ネットワーク管理者がこの通信異常の原因となる障害を発見・解決するには、それらすべての機器を調査しなければならない。
例えば、図3に示すように、運用管理サーバ102とルータ117の間で通信異常が発生した場合、ネットワーク管理者は、運用管理サーバ102、ルータ117、およびスイッチ151〜154のすべての機器を調査しなければならない。
通信異常の情報を、ある2点間では通信が正常であったことを示す他の正常通信の情報と組み合わせることにより、ネットワーク管理者の分析および判断によって、障害発生箇所を絞り込むことは可能である。しかし、人間の手を介することによって判断の誤りを犯しやすくなり、また障害発生箇所絞り込みに時間がかかることにより、通信異常という問題の解決までに時間が余分にかかってしまう。
(2)ある2点間の通信に異常があり、なおかつその2点間の物理的通信経路が複数考えられる場合に、そのうちどの経路の通信による異常であるかが分からないという問題がある。
(1)で述べた通り、通信異常のあった2点間の物理的経路が一通りであった場合においても、障害発生箇所の絞り込みは困難であった。しかしながら、実際の企業内ネットワークおよびインターネットにおいては、2つのノードの間の物理的通信経路が複数存在することも多い。このような場合、2点間の通信異常という事象からみて可能性のある障害発生箇所とは、考えうるすべての経路におけるすべての機器ということになる。(1)で述べた通り、このことは通信異常という問題の解決に時間がかかることを意味する。
例えば、図3のWebサーバ132とアプリケーションサーバ146の間で通信異常が発生した場合、領域301〜303内のすべての機器が障害発生箇所の可能性を持っている。
なお、このような場合に、通信異常の発生を検知してから後に、該当する2点間の異常通信がどのような経路で行われたのかを調査することができれば、ある程度の障害発生箇所絞り込みは可能であるが、この調査は一般に困難であると考えられる。なぜならば、当該2点間の通信はすでに異常となっているため、その2点間の通信を実際に行って経路を確認することができないからである。
(3)ある2点間の通信に異常が発見された場合に、その問題の影響範囲および業務上の緊急性を把握できないという問題がある。
例えば、企業内ネットワークにおいて、ある2点間の通信異常が観測されたが、その2点の間には、顧客向け業務等に用いられる重要度の高いネットワークと、異常時の予備等で使われている重要度の低いネットワークが存在する場合を想定する。
障害発生箇所が重要度の高いネットワークの機器にある場合は、この障害は業務に影響を与えるため、早急に対処しなければならないが、重要度の低いネットワークの機器に障害が発生した場合は影響範囲は限定され、対処を遅らせても構わない場合が多い。
このような場合、2点間の通信異常という情報だけでは、ネットワーク管理者はその障害が重要度の高いネットワークで発生しているかどうかを判断できない。実際には影響範囲が狭く、緊急ではない障害であったとしても、重大な障害である可能性を考慮して早急に対処し、結果として過大に労力を費やす結果となる場合がある。
なお、ネットワーク障害発生時に、ネットワークの構成要素から発せられる警報情報に基づいて故障箇所を特定するネットワークシステムも知られている(例えば、特許文献1参照)。
日本特許出願公開 特開2003−179601号公報
本発明の課題は、通信ネットワークにおいて通信異常が発生した場合に、その原因となる障害が発生した可能性のある箇所を自動的に絞り込むことにより、通信異常という問題を短時間で解決することである。
本発明の障害発生箇所特定装置は、格納部および判定部を備える。格納部は、複数のノードからなる通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、その通信ネットワーク上の始点ノードから終点ノードに至る通信経路に含まれる1つ以上のリンクを示す経路情報とを格納する。判定部は、通信ネットワーク上で通信異常が発生したとき、リンク情報および経路情報を参照しながら、通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、残されたリンクまたは残されたリンクの両端のノードを障害発生箇所候補と判定する。
このような障害発生箇所特定装置によれば、通信異常が発生したとき、障害が発生した可能性のある箇所を特定のリンクまたはノードの範囲に自動的に絞り込むことが可能になる。
格納部は、例えば、後述する図18のメモリ1802または外部記憶装置1805に対応し、判定部は、例えば、後述する図10の障害発生箇所判定部に対応する。
以下、図面を参照しながら、本発明を実施するための最良の形態を詳細に説明する。
本実施形態では、通信ネットワークのトポロジおよび経路情報に基いて、障害発生箇所を絞り込む。トポロジとは、ネットワークを構成する機器同士の物理的・論理的な接続構成を意味する。
この場合、監視対象のネットワークにおける最新の「リンク情報」および「経路情報」があらかじめ用意されている必要がある。「リンク情報」とは、ネットワーク上の各機器の物理的な接続関係を示す情報であり、「経路情報」はネットワーク上の2点間の物理レベルを含む通信経路を示す情報である。
「リンク情報」と「経路情報」は、例えば、先に出願された日本特許出願(特願2004−164778号)に記載された「トポロジ探索技術」および「経路探索技術」により定期的・自動的に取得することが可能である。そこで、まず、この「トポロジ探索技術」および「経路探索技術」の概要について、図4から図8までを参照しながら説明する。
(1)トポロジ探索技術
本技術は、物理レイヤからアプリケーションレイヤまでのすべてのレイヤを統合したトポロジを表現するモデルに基き、SNMP−MIB(Management Information Base )等を用いて各ネットワーク機器から各レイヤに関する情報を自動的に収集・分析することにより、各レイヤにまたがるネットワークトポロジをシステムが把握し、これをマップとして描画・表示するものである。これにより、従来は困難であったすべてのレイヤについてのトポロジ把握を容易に行うことができる。
特に、障害発生箇所絞り込み技術へ適用するにあたっては、物理レイヤにおけるトポロジ探索により「リンク情報」が取得できること、すなわち、各機器のどのポートとどのポートとがつながっているか、というレベルにおいて接続関係を把握することができることが、本技術の重要な点である。
実験に基いた見積によれば、本技術を実装したプログラムを用いると、1000台程度の機器から構成されるネットワークのトポロジ探索結果をおよそ60分以内に出力できると考えられる。この技術を定期的に、例えば毎日用いることにより、ネットワーク管理者は1日単位で物理レイヤを含む最新のネットワークトポロジを把握することができる。
図4は、トポロジ探索技術を実装したトポロジ探索部を示している。図4のトポロジ探索部402は、ノード検知部411、トポロジ情報取得部412、およびトポロジ構築部413を備え、以下の手順で、監視対象となるネットワークを構成する機器同士の物理的・論理的接続を求める。
1.ノード検知部411は、探索対象のネットワーク401のIPアドレスの範囲(探索範囲)と各機器のアカウント情報からなる入力情報421を受け取る。そして、探索範囲に対してpingによる探索を試みて、ネットワーク401を構成する機器(ノード)を検出し、検出されたノードのリスト414を生成する。
2.トポロジ情報取得部412は、SNMP、telnet、またはssh(Secure Shell)を用いて、検出されたネットワーク機器の設定やサービスの情報を取得する。情報取得に必要な各機器のアカウント情報は、ノード検知部411から受け取る。
3.トポロジ構築部413は、取得された情報から機器同士の物理的・論理的接続関係を求め、様々な目的に利用できる形式のトポロジデータベースとして保存する。トポロジ探索部402からの出力情報422には、各機器の設定情報やリンク情報が含まれる。
トポロジ構築部413は、各機器におけるメディアアクセス制御(Media Access Control,MAC)学習テーブルを取得し、機器毎のMAC学習テーブルの内容を照合することで、機器間の物理的な接続関係を把握する。MAC学習テーブルには、送信先MACアドレスと送信元ポートの対応関係が記録されている。
図5は、探索対象のネットワークにおける物理接続の例を示している。このネットワークは、スイッチ501〜503およびパーソナルコンピュータ(PC)504〜515からなる。
スイッチ501(スイッチα)はポート1〜5を有し、ポート1、2、3、および4には、パーソナルコンピュータ504、505、506、および507がそれぞれ接続されており、ポート5にはスイッチ502が接続されている。
スイッチ502(スイッチβ)はポート1〜6を有し、ポート1、2、3、および4には、パーソナルコンピュータ508、509、510、および511がそれぞれ接続されており、ポート5および6には、スイッチ501および503がそれぞれ接続されている。
スイッチ503(スイッチγ)はポート1〜5を有し、ポート1、2、3、および4には、パーソナルコンピュータ512、513、514、および515がそれぞれ接続されており、ポート5にはスイッチ502が接続されている。
パーソナルコンピュータ504、505、506、507、508、509、510、511、512、513、514、および515のMACアドレスは、それぞれA、B、C、D、E、F、G、H、I、J、K、およびLである。
スイッチ501、502、および503は、スイッチングサービスを行うために、図6に示すようなMAC学習テーブル601、602、および603をそれぞれ持っている。これらのMAC学習テーブルには、ポート毎に、学習されたパーソナルコンピュータ504〜515のMACアドレスが登録されている。
例えば、スイッチαのポート5については、スイッチβ配下の4台のPCのMACアドレスE、F、G、およびHが学習されており、スイッチβのポート5については、スイッチα配下の4台のPCのMACアドレスが学習されている。この情報から、スイッチαのポート5とスイッチβのポート5とが接続されていると推測できる。このように、スイッチのMAC学習テーブルから、スイッチ同士の接続や、スイッチ−PC間の接続を求めることが可能である。
スイッチ501〜503およびパーソナルコンピュータ504〜515の機器設定情報が入力されたとき、トポロジ構築部413は、以下の手順でリンク情報を求める。
トポロジ構築部413は、まず、スイッチの機器設定情報からMAC学習テーブル601、602、および603を抽出し、それらのMAC学習テーブルを参照してスイッチ間の物理接続を探索する。
隣接する2台のスイッチ間においては、互いを繋ぐポートについて学習されるMACアドレスは、隣接するスイッチの、互いを繋ぐポート以外のポートについて学習されたMACアドレスの総和である。
トポロジ構築部413は、ネットワーク内の全スイッチのMACアドレス学習テーブルを調査し、スイッチの各ポートについて学習されているMACアドレスの、ポートを単位とする論理和を用いた比較が成立するか否かを判定して、スイッチ同士の物理接続を求める。
次に、トポロジ構築部413は、パーソナルコンピュータ504〜515のMACアドレスと、スイッチ間の物理接続の探索結果から、スイッチと各パーソナルコンピュータの物理接続を探索する。このとき、各スイッチのMAC学習テーブル内の、スイッチ同士の接続に使用されていないポートのうち、ネットワーク内のスイッチ以外の機器(パーソナルコンピュータ)のMACアドレスを学習しているポートを探索し、該当するポートとパーソナルコンピュータの間の物理接続を求める。
こうして物理接続の情報(リンク情報)が得られると、トポロジ構築部413は、リンク情報と各機器の設定情報を用いてレイヤ別のトポロジ探索処理を行い、複数レイヤにわたるトポロジを求める。
このとき、設定情報を用いて複数のレイヤの中の下位レイヤのトポロジに含まれる物理接続または論理接続をグループ化して、上位レイヤにおける情報到達範囲を生成し、その情報到達範囲から上位レイヤのトポロジを生成する。このような処理を物理レイヤ、MACレイヤ、IPレイヤ、TCP/UDP(Transmission Control Protocol/User Datagram Protocol)レイヤ、およびアプリケーションレイヤの順に繰り返すことで、複数レイヤにわたるトポロジが生成される。
(2)経路探索技術
本技術は、探索対象となる経路の始点および終点の機器(ノード)と、トポロジ探索技術の出力結果であるトポロジデータベースをもとに、始点ノードから隣接ノードを経由して終点ノードまで接続されているネットワーク内の2点間の経路を算出するものである。
これにより、ネットワークの2点間の通信における「経路情報」を、IPレイヤだけでなくMACレイヤまで(通過するL2スイッチ等の情報まで)のネットワーク機器のレベルで把握することが可能である。具体的には、以下の手順で経路探索を行う。
1.IPレイヤのネクストホップ取得
始点ノードから終点ノードに向かうための、IPレイヤにおけるネクストホップのIPアドレスを、始点ノードのルーティング情報から取得する。
2.MACレイヤのネクストホップ取得
始点ノードのMAC学習テーブルをもとに、ネクストホップのIPアドレスに向かうための、MACレイヤにおけるネクストホップのMACアドレスを取得する。トポロジ探索技術により得られているリンク情報を参照し、MACレイヤでのネクストホップとなる機器を決定する。
3.始点ノードの代わりにネクストホップとなる機器に対して、2のMACレイヤのネクストホップ取得を繰り返し、MACレイヤでの経路情報の取得を続ける。これを繰り返してIPレイヤでのネクストホップの機器に辿り着いたら、1のIPレイヤのネクストホップ取得を繰り返して、IPレイヤにおいてその次のホップとなる機器を決定する。以上の処理を、終点ノードのIPアドレスに辿り着くまで繰り返す。
図7は、このような経路探索技術を実装したトポロジ探索装置を示している。図7のトポロジ探索装置701は、図4のトポロジ探索部402と経路探索部711を備える。経路探索部711は、次経路判定部721および動的情報算出部722を備え、探索対象情報723および次探索対象情報724を保持する。
経路探索部721は、各機器の設定情報751、複数レイヤにわたるトポロジ752、および探索条件753を入力として経路探索処理を行い、データ通過経路754を経路情報として出力する。
トポロジ752は、リンク情報に対応する物理レイヤのトポロジ761、MACレイヤのトポロジ762、IPレイヤのトポロジ763、TCP/UDPレイヤのトポロジ764、およびアプリケーションレイヤのトポロジ765からなり、探索条件753は、始点および終点となるネットワーク内の2点771およびサービスの種類772の情報を含む。ネットワーク内の2点771は、ノード名やIPアドレス等により指定される。
探索対象情報723は、現在のコネクタ731および直前のコネクタ732の情報を含み、次探索対象情報724は、上位レイヤのコネクタ741および下位レイヤのコネクタ742の情報を含む。また、データ通過経路754は、データが通過したコネクタ781−1〜781−nの情報を含む。
各レイヤにおいて、機器間の物理・論理接続に使用される物理・論理インタフェースは「コネクタ」で表され、通信の終端を行ったり、機器内の複数コネクタ間でデータの転送を行う機能は「サービス」で表される。
図8は、現在のコネクタ731、直前のコネクタ732、上位レイヤのコネクタ741、下位レイヤのコネクタ742、およびコネクタ781−1〜781−nの各コネクタ情報のデータ構造を示している。図8のコネクタ情報801は、該当するコネクタが属する機器名811、レイヤの識別情報812、および同一レイヤ内でコネクタを一意に識別するためのコネクタ識別子813を含む。
次経路判定部721は、現在の探索対象の情報を探索対象情報723に保持し、次の探索対象の情報を次探索対象候補724に保持しながら、設定情報751、トポロジ752、および探索条件753を用いてネクストホップの取得を繰り返す。そして、始点ノードから終点ノードに至るコネクタの情報を、データ通過経路754として出力する。動的情報算出部722は、次経路判定部721により宛先が得られない場合、または名前解決等の方法により宛先を取得する必要がある場合に、動的に宛先を求める。
本実施形態では、上述した(1)トポロジ探索および(2)経路探索を定期的に実施することにより、監視対象となるネットワークのリンク情報と、ネットワーク内の複数の始点・終点の組み合わせに対する経路情報をあらかじめ取得しておく。また、運用管理サーバを設けるとともに、監視対象のネットワーク上の複数のノードに監視エージェントを配置する。
図9は、本実施形態のネットワークシステムの例を示している。図9のシステムは、以下の機器からなる。
・スイッチ:SW−a、SW−b、SW−c、SW−d、SW−e、SW−f
・ファイアウォール:FW−a、FW−b
・サーバ負荷分散装置:SLB−a、SLB−b
・Webサーバ:WEB−a、WEB−b
・アプリケーションサーバ:AP−a、AP−b
・運用管理サーバ901
このうち、WEB−a、WEB−b、AP−a、およびAP−bに、それぞれ監視エージェント902、903、904、および905が配置されている。
運用管理サーバ901は、異常通信が発生したとき、その通信の経路情報と他の正常通信の経路情報とを照合する。そして、異常通信の経路に含まれる各リンクのうち、他の正常通信の経路に含まれていないものを抽出し、そのリンクおよび両端のポートを障害発生箇所候補として出力する。
例えば、WEB−bからAP−aへの通信とWEB−aからAP−bへの通信がともに正常で、WEB−bからAP−bへの通信において異常が発生した場合、以下のリンクおよびポートが障害発生箇所候補として求められる。
・SLB−bとSW−fの間のリンク906
・SLB−bのポート907(SW−f向け)
・SW−fのポート908(SLB−b向け)
図10は、図9の運用管理サーバ901および監視エージェント902〜905の機能ブロック図である。運用管理サーバ901は、図4のトポロジ探索部402および図7の経路探索部711に加えて、ノードペア抽出部1011、通信可否調査部1012、障害発生箇所判定部1013、および結果表示部1014を備える。監視エージェント1001は、監視エージェント902〜905に対応し、通信監視部1031、通信異常通知部1032、抽出部1033、および通信試行部1034を備える。
運用管理サーバ901のトポロジ探索部402および経路探索部711は、トポロジ探索および経路探索を定期的に実施することにより、監視対象のネットワークの最新(例えば、最近1日以内)のリンク情報1021および複数のノードペアに対する経路情報1022を取得する。これらの情報は、運用管理サーバ901内に保持される。
監視エージェント1001の通信監視部1031は、常時、他のノード(事前に経路情報が判明しているノード)との間の通信を監視し、ログ1041を生成する。ログ1041には、通信先IPアドレスと通信可否の情報が一定期間蓄積される。通信監視部1031が他のノードとの間での通信の異常を検知すると、通信異常通知部1032は、その旨を運用管理サーバ901に通知する。
運用管理サーバ901のノードペア抽出部1011は、通信可否調査対象のノードペアを抽出する。通信可否調査対象としては、例えば、経路情報が判明しているすべてのノードペアが抽出される。通信可否調査部1012は、監視対象のネットワーク上に配置された各監視エージェント1001に対して、抽出されたノードペアの通信可否を問い合わせる。
これを受けて、監視エージェント1001は、以下の2つの方法のいずれかを用いて、指示された各ノードペアに対する通信可否の情報を取得し、運用管理サーバ901に回答を送信する。
(a)通信試行部1034は、運用管理サーバ901からの問い合わせを契機として、ノードペアに含まれる宛先ノードへの通信を試行する。
(b)抽出部1033は、ログ1041を参照して、ノードペアに含まれる宛先ノードとの通信の可否を取得する。この場合、通信可否調査部1012は、監視エージェント1001に対して調査すべき時間帯を指示し、抽出部1033は、その時間帯に宛先ノードと通信できていたか否かをチェックする。調査すべき時間帯としては、通信異常発生時刻の前後の一定時間等が指定される。
例えば、Web−bからAP−bへの通信で10時35分20秒に異常が発生した場合、Web−aの監視エージェント902は、ログ1041を参照して、Web−aからAP−aへの通信またはWeb−aからAP−bへの通信において、10時34分50秒から10時35分50秒の時間帯に成功/失敗の事例があるか否かをチェックする。そのような事例があれば、それを回答として運用管理サーバ901に通知する。
次に、運用管理サーバ901の障害発生箇所判定部1013は、リンク情報1021、経路情報1022、および現時点での通信可否の情報をもとに、通信経路を構成するリンクのいずれか1箇所でも通信を妨げるような障害が存在すれば、その通信は正常に行われないとの認識に基き、異常の原因となる障害発生箇所を絞り込む。
障害発生箇所判定部1013は、通信に異常があるノードペアに対し、その経路となるリンクを1つ1つ抽出し、そのリンクが他の正常通信が可能なノードペアの経路に含まれているか否かをチェックする。そして、正常通信の経路に含まれていないリンクの集合と、各リンクの両端にあるポートの集合を、障害発生箇所候補に決定する。
結果表示部1014は、障害発生箇所候補の情報を画面表示することで、処理結果を管理者に通知する。例えば、監視対象のネットワークを描いた画面上に、障害発生箇所候補となる機器およびリンクを色を変えて表示することで、障害発生箇所候補が容易に認識できるようになる。
また、処理結果を再利用できるように、異常発生時刻、異常が発生した経路、障害発生箇所候補、および障害発生箇所の情報が、障害情報1023として運用管理サーバ901内に保存される。結果表示部1014は、保存された障害情報1023を参照することで、過去のある時点でのネットワークの状態を再表示することができる。
このようなシステムによれば、ノード間で通信異常が発生した場合に、その通信異常の原因となる障害発生箇所を、あらゆる可能な通信経路の中で、実際に通信が行われた経路で、かつ、他の正常通信では使われない部分に、絞り込むことができる。
絞り込みの精度は、ネットワーク上における監視エージェントの設置数(密度)に依存する。より多くの監視エージェントを設置して多数のノードペアに対する通信可否の情報を取得するほど、通信異常時の障害発生箇所をより狭い範囲に絞り込める。このような絞り込み方法は、監視対象のネットワーク上に同時に発生した障害が1箇所または複数箇所である場合に適用可能である。
ところで、異常通信が発生したとき、常に他のすべてのノードペアについて通信可否を調査すると、調査対象が多すぎて処理効率が低下することが考えられる。そこで、以下の手順で通信可否調査対象を絞り込むことが好ましい。
1.管理者は、
事前に、トポロジ的または役割的に近いサーバ同士をグルーピングし、サーバグループとして運用管理サーバ901に登録しておく。
2.ノードペア抽出部1011は、通信異常が発生したノードペアの各ノードが属するサーバグループを調べ、それらのサーバグループ間でペアを構成するような2つのノードを、通信可否調査対象として抽出する。
例えば、図11に示すように、Web−aおよびWeb−bをWebサーバグループ1101として登録し、AP−aおよびAP−bをAPサーバグループ1102として登録しておく。Web−bからAP−bへの通信で異常が発生したとき、Webサーバグループ1101のノードとAPサーバグループ1102のノードがペアを構成するように、以下のノードペアが抽出される。
・Web−aとAP−a
・Web−aとAP−b
・Web−bとAP−a
そして、Web−aからAP−aへの通信、Web−aからAP−bへの通信、およびWeb−bからAP−aへの通信の可否が調査される。Web−bとAP−bのノードペアは、通信異常が発生したノードペアに相当するため、調査対象からは除外される。
次に、図12から図17までを参照しながら、図9のネットワークシステムにおける障害発生箇所絞り込み処理について、より詳細に説明する。
図12は、図9の監視対象のネットワークに含まれる各機器のインタフェース(コネクタ)の識別子を示している。これらの機器のインタフェース識別子は、以下の通りである。
SW−a、SW−b、SW−c、SW−d、SW−e、SW−f:port1〜port6
FW−a、FW−b、SLB−a、SLB−b:port1〜port4
WEB−a、WEB−b、AP−a、AP−b:eth0、eth1
図13および14は、図12のネットワークに対するリンク情報および経路情報の例を示している。図13のリンク情報には、物理レイヤのトポロジとして、各リンクの識別子(接続ID)と、リンクの両端にあるノードの識別子と、そのノードのコネクタの識別子が含まれている。例えば、接続ID“1”を有するリンクは、ノード“WEB−a”のコネクタ“eth0”とノード“SW−a”のコネクタ“port1”を接続するリンクであることが分かる。
図14の経路情報は、WEB−bと始点とし、AP−bを終点とする経路の情報に相当し、始点に近い方から順に、経路を構成するリンクの接続ID、リンクの両端にあるノードの識別子、およびそのノードのコネクタの識別子が記録されている。
図15は、通信異常発生時のネットワークの状態を示している。例えば、WEB−bを始点とし、AP−bを終点とする通信の異常が検知され、他の経路での通信が試行された結果、WEB−aからAP−bへの通信とWEB−bからAP−aへの通信は正常であることが判明する。この場合、障害発生箇所判定部1013は、図16に示すような判定処理データを生成し、図17に示すフローチャートに従って障害発生箇所絞り込み処理を行う。
図16の判定処理データには、通信異常が発生した経路を構成する各リンクについて、以下の情報が登録される。
・接続ID
・リンク始点:リンクの始点のノードおよびコネクタの識別子
・リンク終点:リンクの終点のノードおよびコネクタの識別子
・WEB−b→AP−bの経路に含まれるか否か
・WEB−b→AP−aの経路に含まれるか否か
・WEB−a→AP−bの経路に含まれるか否か
・障害発生箇所候補であるか否か
黒丸のマーク●は、リンクが対応する経路に含まれることを表し、黒星のマーク★は、リンクおよびコネクタが障害発生箇所候補であることを表す。接続ID、リンク始点、およびリンク終点の情報は、図13のリンク情報から取得され、リンクが経路に含まれるか否かの情報は、図14の経路情報から取得される。図16の判定処理データには、さらに、各経路の通信可否の情報も登録されている。
障害発生箇所判定部1013は、まず、経路情報に含まれる異常または正常と判明した各通信の経路を参照し(ステップ1701)、1つ以上の異常通信の経路に含まれるリンクを抽出する(ステップ1702)。そして、抽出されたリンクに関する判定処理データを生成し、各リンクに対して障害発生箇所候補になるか否かの判定を開始する(ステップ1703)。
まず、判定処理データを参照しながら、1番目のリンクが1つ以上の正常通信の経路に含まれているか否かをチェックする(ステップ1704)。そして、そのリンクがいずれの正常通信の経路にも含まれていなければ、当該リンクとその両端のコネクタを障害発生箇所候補とみなして、判定処理データの対応する行に黒星のマークを付ける(ステップ1705)。そのリンクがいずれかの正常通信の経路に含まれていれば、当該リンクとその両端のコネクタを障害発生箇所候補から除外する(ステップ1706)。
次に、すべてのリンクを判定したか否かをチェックし(ステップ1707)、未判定のリンクがあれば、次のリンクを選択してステップ1703以降の処理を繰り返す(ステップ1708)。そして、未判定のリンクがなくなれば、処理を終了する。
図15の例では、通信異常が発生した「WEB−b→AP−b」の経路に含まれるリンクが抽出され、図16に示した判定処理データが生成される。そして、抽出されたリンクのうち、他の正常通信の経路である「WEB−b→AP−a」および「WEB−a→AP−b」に含まれるリンクが障害発生箇所候補から除外される。こうして、残された接続ID“24”のリンクと、その両端のコネクタに相当するSLB−bのport4とSW−fのport2が、通信異常の原因となる障害発生箇所の候補と判定される。
以上説明した実施形態では、通信機能の階層構成として物理レイヤ、MACレイヤ、IPレイヤ、TCP/UDPレイヤ、およびアプリケーションレイヤの5つのレイヤを想定しているが、本発明はこの階層構成に限らず、他の階層構成にも同様に適用可能である。
ところで、図7のトポロジ探索装置701および図9の運用管理サーバ901、Webサーバ902、903、アプリケーションサーバ904、905は、例えば、図18に示すような情報処理装置(コンピュータ)を用いて構成される。図18の情報処理装置は、CPU1801、メモリ1802、入力装置1803、出力装置1804、外部記憶装置1805、媒体駆動装置1806、ネットワーク接続装置1807を備え、それらはバス1808により互いに接続されている。
メモリ1802は、例えば、ROM(read only memory)、RAM(random access memory)等を含み、処理に用いられるプログラムおよびデータを格納する。CPU1801は、メモリ1802を利用してプログラムを実行することにより、必要な処理を行う。
図10のトポロジ探索部402、経路探索部711、ノードペア抽出部1011、通信可否調査部1012、障害発生箇所判定部1013、結果表示部1014、および監視エージェント1001は、メモリ1802に格納されたプログラムに対応する。また、図10のリンク情報1021、経路情報1022、障害情報1023、ログ1041および図16の判定処理データは、メモリ1802に格納されたデータに対応する。
入力装置1803は、例えば、オペレータからの指示や情報の入力に用いられる。出力装置1804は、例えば、ディスプレイ、プリンタ、スピーカ等であり、オペレータへの問い合わせや処理結果等の出力に用いられる。
外部記憶装置1805は、例えば、磁気ディスク装置、光ディスク装置、光磁気ディスク装置、テープ装置等である。情報処理装置は、この外部記憶装置1805に、プログラムおよびデータを格納しておき、必要に応じて、それらをメモリ1802にロードして使用する。外部記憶装置1805は、リンク情報1021、経路情報1022、障害情報1023、およびログ1041を保存するデータベースとしても使用される。
媒体駆動装置1806は、可搬記録媒体1809を駆動し、その記録内容にアクセスする。可搬記録媒体1809は、メモリカード、フレキシブルディスク、光ディスク、光磁気ディスク等の任意のコンピュータ読み取り可能な記録媒体である。オペレータは、この可搬記録媒体1809にプログラムおよびデータを格納しておき、必要に応じて、それらをメモリ1802にロードして使用する。
ネットワーク接続装置1807は、通信ネットワークに接続され、通信に伴うデータ変換を行う。情報処理装置は、必要に応じて、プログラムおよびデータを外部の装置からネットワーク接続装置1807を介して受け取り、それらをメモリ1802にロードして使用する。
図19は、図18の情報処理装置にプログラムおよびデータを提供する方法を示している。可搬記録媒体1809やサーバ1901のデータベース1911に格納されたプログラムおよびデータは、情報処理装置1902のメモリ1802にロードされる。サーバ1901は、そのプログラムおよびデータを搬送する搬送信号を生成し、ネットワーク上の任意の伝送媒体を介して情報処理装置1902に送信する。CPU1801は、そのデータを用いてそのプログラムを実行し、必要な処理を行う。
本発明によれば、ネットワーク運用管理における障害発生時の復旧において、以下の効果が得られる。
(1)通信異常の原因となる障害が発生した可能性のある箇所を絞り込むことにより、原因究明および復旧作業をより短時間で行うことができる。
前述したように、従来は、ネットワーク上の2点間の通信に異常があった場合、考えられる障害発生箇所は、その2点間のすべての可能な経路上にある、すべての機器・リンクであった。
これに対して、本発明によれば、考えられる障害発生箇所を、実際にその2点間で通信が行われた経路上にある機器・リンクのうち、他で確認された正常通信のデータが通過していない部分にまで絞り込むことができる。このため、原因究明のために調査対象とする機器を減らすことができ、復旧作業の短期化につながる。
(2)通信異常発生時に、その問題の影響範囲および業務上の緊急性の把握ができる可能性が高くなる。
(1)の絞り込みの結果、障害発生箇所である可能性のある場所の範囲が、重要度の低いネットワーク内に絞り込まれれば、業務に影響を与えない程度の影響範囲であると判断できる。その結果、前述したような、緊急ではない障害に対して過大な労力を費やすことが、回避される。
従来のネットワークシステムにおける運用管理サーバによる通信試行を示す図である。 従来のネットワークシステムにおけるエージェントによる通信試行を示す図である。 従来のネットワークシステムにおける通信異常の発生を示す図である。 トポロジ探索部の構成図である。 物理接続を示す図である。 MAC学習テーブルを示す図である。 トポロジ探索装置の構成図である。 コネクタのデータ構造を示す図である。 本発明のネットワークシステムを示す図である。 運用管理サーバおよび監視エージェントの機能ブロック図である。 サーバのグルーピングを示す図である。 各機器のインタフェース識別子を示す図である。 リンク情報を示す図である。 経路情報を示す図である。 通信異常発生時のネットワークの状態を示す図である。 判定処理データを示す図である。 障害発生箇所絞り込み処理のフローチャートである。 情報処理装置の構成図である。 プログラムおよびデータの提供方法を示す図である。

Claims (6)

  1. 複数のノードからなる通信ネットワーク上の各ノードに対応する機器の設定情報から生成されるリンク情報及び経路情報であって、該通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードと終点ノードの複数の組み合わせのそれぞれについて該始点ノードから該終点ノードに至る通信経路に含まれる1つ以上のリンクを示す経路情報とを格納する格納部と、
    前記通信ネットワーク上で通信異常が発生したとき、前記リンク情報および経路情報を参照しながら、該通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外して、残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する判定部と
    を備えることを特徴とする障害発生箇所特定装置。
  2. 複数のノードからなる通信ネットワーク上で通信異常が発生したとき、該通信ネットワーク上の各ノードに対応する機器の設定情報から生成され格納部に格納されているリンク情報及び経路情報であって、該通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードと終点ノードの複数の組み合わせのそれぞれについて該始点ノードから該終点ノードに至る通信経路に含まれる1つ以上のリンクを示す経路情報とを参照し、
    前記通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外し、
    残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する処理をコンピュータに実行させることを特徴とするプログラム。
  3. 前記通信異常が発生したとき、前記通信ネットワーク上のノードに対して、経路情報が判明しているノード間の通信可否を問い合わせ、回答として受け取った通信可否の情報をもとに、前記通信可能なノード間の通信経路を決定する処理を、前記コンピュータにさらに実行させることを特徴とする請求項2記載のプログラム。
  4. 前記通信ネットワーク上の複数のノードをグルーピングして前記格納部に登録し、前記通信異常が発生した通信経路の始点ノードが属するグループと、該通信経路の終点ノードが属するグループの間でノードペアを構成するような2つのノードを、通信可否調査対象として抽出する処理を、前記コンピュータにさらに実行させることを特徴とする請求項記載のプログラム。
  5. 前記通信ネットワークを描いた画面上に、前記障害発生箇所候補と判定されたリンクまたはノードの情報を表示する処理を、前記コンピュータにさらに実行させることを特徴とする請求項2記載のプログラム。
  6. 判定部が、複数のノードからなる通信ネットワーク上で通信異常が発生したとき、該通信ネットワーク上の各ノードに対応する機器の設定情報から生成され格納部に格納されているリンク情報及び経路情報であって、該通信ネットワーク上のノード間を接続する物理的なリンクを示すリンク情報と、該通信ネットワーク上の始点ノードと終点ノードの複数の組み合わせのそれぞれについて該始点ノードから該終点ノードに至る通信経路に含まれる1つ以上のリンクを示す経路情報とを参照し、
    前記判定部が、前記通信異常が発生した通信経路に含まれるリンクのうち、通信可能なノード間の通信経路に含まれるリンクを除外し、
    前記判定部が、残されたリンクまたは該残されたリンクの両端のノードを障害発生箇所候補と判定する
    ことを特徴とする障害発生箇所特定方法。
JP2006542186A 2004-10-29 2004-10-29 通信ネットワークにおける障害発生箇所を特定する装置および方法 Expired - Fee Related JP4345987B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/016161 WO2006046309A1 (ja) 2004-10-29 2004-10-29 通信ネットワークにおける障害発生箇所を特定する装置および方法

Publications (2)

Publication Number Publication Date
JPWO2006046309A1 JPWO2006046309A1 (ja) 2008-05-22
JP4345987B2 true JP4345987B2 (ja) 2009-10-14

Family

ID=36227561

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006542186A Expired - Fee Related JP4345987B2 (ja) 2004-10-29 2004-10-29 通信ネットワークにおける障害発生箇所を特定する装置および方法

Country Status (3)

Country Link
US (1) US7756046B2 (ja)
JP (1) JP4345987B2 (ja)
WO (1) WO2006046309A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4523444B2 (ja) 2005-02-10 2010-08-11 富士通株式会社 通信ネットワークにおける障害の原因を特定する障害管理装置および方法
JP2009194675A (ja) * 2008-02-15 2009-08-27 Fujitsu Ltd ネットワーク構成管理プログラム、ネットワーク構成管理装置、ネットワーク構成管理方法
US8160855B2 (en) * 2008-06-26 2012-04-17 Q1 Labs, Inc. System and method for simulating network attacks
JP5035219B2 (ja) * 2008-11-06 2012-09-26 富士通株式会社 通信経路検出方法、通信経路検出プログラム、および通信経路検出装置
US20100165849A1 (en) * 2008-12-29 2010-07-01 Martin Eisenberg Failure Detection in IP Networks Using Long Packets
JP5358256B2 (ja) * 2009-04-17 2013-12-04 エヌ・ティ・ティ・コムウェア株式会社 劣化箇所推定装置及び劣化箇所推定方法並びにそのプログラム
JP5655651B2 (ja) 2010-06-09 2015-01-21 富士通株式会社 異常検出装置、通信異常検出システム、通信異常検出方法、及びプログラム
JP5534481B2 (ja) * 2010-08-30 2014-07-02 日本電気株式会社 通信品質監視システム、通信品質監視方法、及び記憶媒体
US20130268801A1 (en) * 2010-12-10 2013-10-10 Nec Corporation Server management apparatus, server management method, and program
JP5427913B2 (ja) * 2012-04-18 2014-02-26 株式会社日立製作所 管理システム及び情報処理システム
US9800423B1 (en) 2012-05-14 2017-10-24 Crimson Corporation Determining the status of a node based on a distributed system
JP6051724B2 (ja) * 2012-09-20 2016-12-27 富士通株式会社 設計支援プログラム、設計支援装置、及び設計支援方法
WO2014050143A1 (en) * 2012-09-28 2014-04-03 Nec Corporation Communication system, control apparatus, control method, and program
US20150188731A1 (en) * 2013-12-27 2015-07-02 Daniel P. Daly Programmable Distributed Networking
US10834150B1 (en) 2014-12-26 2020-11-10 Ivanti, Inc. System and methods for self-organizing multicast
JP6997378B2 (ja) * 2018-10-26 2022-01-17 日本電信電話株式会社 推定方法、推定装置及び推定プログラム
CN109347687B (zh) * 2018-11-23 2021-10-29 四川通信科研规划设计有限责任公司 一种基于网络节点故障定位的通信系统及方法
CN111030878A (zh) * 2019-12-31 2020-04-17 深圳市英威腾电气股份有限公司 一种线型组网变频器的故障检测方法及相关装置
CN113300868B (zh) * 2020-07-13 2024-04-30 阿里巴巴集团控股有限公司 故障网络设备节点的定位方法、装置和网络通信方法
CN112684371B (zh) * 2020-12-07 2023-11-21 深圳市道通科技股份有限公司 汽车总线的故障定位方法、诊断设备及汽车检测系统、方法
JPWO2023136091A1 (ja) * 2022-01-11 2023-07-20
CN116545846B (zh) * 2023-07-06 2023-09-15 北京志凌海纳科技有限公司 列布局型网络拓扑显示及网口故障域发现系统及方法

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0199345A (ja) * 1987-10-13 1989-04-18 Nec Corp 通信ネットワーク管理図の障害表示方式
JPH09186716A (ja) * 1995-12-28 1997-07-15 Sumitomo Electric Ind Ltd ネットワークトポロジ認識方法およびネットワークトポロジ認識装置
JPH11331236A (ja) 1998-05-19 1999-11-30 Nippon Telegr & Teleph Corp <Ntt> 通信ネットワーク構成表示方法
US6757242B1 (en) * 2000-03-30 2004-06-29 Intel Corporation System and multi-thread method to manage a fault tolerant computer switching cluster using a spanning tree
US7035202B2 (en) * 2001-03-16 2006-04-25 Juniper Networks, Inc. Network routing using link failure information
JP4149680B2 (ja) * 2001-03-21 2008-09-10 富士通株式会社 通信ネットワークの迂回経路設計方法
EP1282265A3 (en) * 2001-07-26 2003-06-18 Allied Telesis Kabushiki Kaisha Media converter and transmission system using the same
JP2003179601A (ja) 2001-12-10 2003-06-27 Hitachi Ltd 伝送ネットワークシステム、伝送ネットワーク監視システム、および、故障点診断方法
JP2003333104A (ja) * 2002-05-14 2003-11-21 Fujitsu I-Network Systems Ltd VoIPゲートウエイ装置
DK1537701T3 (da) * 2002-09-09 2008-08-11 Cisco Tech Inc Årsagskorrelation i forbindelseslöse netværk
ATE455438T1 (de) * 2002-11-19 2010-01-15 Alcatel Lucent Die fehlerlokalisierung in einem übertragungsnetzwerk
US7876694B2 (en) * 2004-07-02 2011-01-25 Hewlett-Packard Development Company, L.P. Identifying VPN faults based on virtual routing address and edge interface relationship information

Also Published As

Publication number Publication date
US7756046B2 (en) 2010-07-13
JPWO2006046309A1 (ja) 2008-05-22
US20070258476A1 (en) 2007-11-08
WO2006046309A1 (ja) 2006-05-04

Similar Documents

Publication Publication Date Title
JP4345987B2 (ja) 通信ネットワークにおける障害発生箇所を特定する装置および方法
JP4523444B2 (ja) 通信ネットワークにおける障害の原因を特定する障害管理装置および方法
JP4840236B2 (ja) ネットワークシステム及びノード装置
US9225624B2 (en) Systems and methods for topology discovery and application in a border gateway protocol based data center
EP2725743B1 (en) Methods and device for processing location information about fault point
US20070177523A1 (en) System and method for network monitoring
WO2021128977A1 (zh) 一种故障诊断方法及装置
JP2002141905A (ja) ノード監視方法,ノード監視システム、および記録媒体
JP5842641B2 (ja) 通信システム、および生成装置
CN112995042B (zh) 业务拓扑图的生成方法、装置、设备及存储介质
JP5035219B2 (ja) 通信経路検出方法、通信経路検出プログラム、および通信経路検出装置
WO2017036165A1 (zh) 链路故障检测方法及装置
JP4464256B2 (ja) ネットワーク上位監視装置
JP7056207B2 (ja) トポロジ決定装置、トポロジ決定方法、トポロジ決定プログラムおよび通信システム
US10333817B2 (en) Non-transitory computer-readable storage medium, communication device, and determination method
JP4238834B2 (ja) ネットワーク管理システムおよびネットワーク管理プログラム
JP3725146B2 (ja) 通信ネットワーク管理装置及び通信ネットワークの疎通確認試験方法
US20170346678A1 (en) Methods, systems, and computer readable media for providing high availability support at a bypass switch
US8463940B2 (en) Method of indicating a path in a computer network
JP6460893B2 (ja) 通信経路監視装置、通信システム、障害判定方法、及びプログラム
JP2006319683A (ja) ネットワークシステム監視方式およびネットワークシステム監視装置
JP4126697B2 (ja) 接続監視システム
JP5398568B2 (ja) ネットワーク管理装置および障害箇所推定方法
JP5613193B2 (ja) ポーリング試験装置およびポーリング試験方法
Huang et al. A network processor-based fault-tolerance architecture for critical network equipments

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20090414

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090611

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090707

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090709

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120724

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120724

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130724

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees