[go: up one dir, main page]

JP2014053658A - 障害部位推定システムおよび障害部位推定プログラム - Google Patents

障害部位推定システムおよび障害部位推定プログラム Download PDF

Info

Publication number
JP2014053658A
JP2014053658A JP2012194743A JP2012194743A JP2014053658A JP 2014053658 A JP2014053658 A JP 2014053658A JP 2012194743 A JP2012194743 A JP 2012194743A JP 2012194743 A JP2012194743 A JP 2012194743A JP 2014053658 A JP2014053658 A JP 2014053658A
Authority
JP
Japan
Prior art keywords
failure
interface
site
node
information
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.)
Pending
Application number
JP2012194743A
Other languages
English (en)
Inventor
Taro Shibahara
太郎 芝原
Kenji Suzuki
賢治 鈴木
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.)
Nomura Research Institute Ltd
Original Assignee
Nomura Research Institute 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 Nomura Research Institute Ltd filed Critical Nomura Research Institute Ltd
Priority to JP2012194743A priority Critical patent/JP2014053658A/ja
Publication of JP2014053658A publication Critical patent/JP2014053658A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Abstract

【課題】大規模なネットワークシステムにおける障害の際に、論理障害の場合も含めて障害の被疑部位を迅速に推定して絞り込むことを可能とする。
【解決手段】監視対象NW300の正常時に、各ノードに至る通信経路上のインタフェースからなる経路情報を取得して経路情報DB130に記録する経路情報取得部110と、監視対象NW300の障害時に、障害ノードに至る経路情報を経路情報DB130からそれぞれ取得し、経路情報に含まれる各インタフェースに対して逐次ポーリングを行って、OKもしくはNGの結果を収集するホップバイホップポーリング部121と、NGとなった最も手前のインタフェースとその1つ手前のOKとなったインタフェースとを被疑ペアとし、各障害ノードについて被疑ペアを抽出して被疑ペア集合を取得する被疑ペア抽出部122と、被疑ペア集合と経路情報とに基いて障害被疑部位を抽出して出力する障害部位出力部123とを有する。
【選択図】図1

Description

本発明は、ネットワークの管理技術に関し、特に、ネットワーク障害の際に障害部位を推定する障害部位推定システムおよび障害部位推定プログラムに適用して有効な技術に関するものである。
通常、ネットワークシステムを運用・管理する際には、例えばネットワーク監視システム等により障害の監視・検知と障害部位の特定などが行われる。一般的に、ネットワーク監視システムは、例えば、ベンダー等から提供・市販されているソフトウェアやシステム、装置等により構成される。
しかしながら、大規模なネットワークシステムでは、例えば、コアとなるネットワーク機器に障害が発生したような場合には、他の機器にも影響が及び、ネットワーク監視システムで障害として検知されるネットワーク機器が一時的に膨大な数となる場合も多く、正確な障害部位を特定することが困難な場合がある。特に、障害となったネットワーク機器がハードウェア障害等により完全に停止等してしまったような状態ではなく、正常な処理とエラー処理とが繰り返されるような「半死」の状態の場合は、ネットワーク監視システムにより障害部位を特定することはさらに困難となる。
通常このような場合は、SE(System Engineer)等の当該ネットワークシステムに精通した技術者や開発者が手動で障害を解析し切り分けて、障害部位を特定することになる。しかしながら、このような障害解析や障害部位の特定手法は属人的であり、また、効率も悪く、対応策(例えば、特定のネットワーク機器の再起動など)の実施までに長時間を要する結果となる場合も多い。
これに対し、ネットワークシステムにおける障害部位の特定を効率的に行う仕組みとして、例えば、特開2006−229421号公報(特許文献1)には、分岐と端末で構成されたツリー型のネットワークのトポロジを、ツリーの根本側が上層側で先端側が下層側であり、各分岐にて1つ下の層が現れ、各分岐とその下層側の端末が関連づけられた階層構造で表現する階層構造テーブルを用い、ある分岐からツリー先端に向かうすべての下層側端末の故障が検出されたときに、当該分岐部分を推定故障箇所として求めることで、ネットワークの端末以外の故障を容易に診断する技術が記載されている。
また、特開2006−238052号公報(特許文献2)には、ネットワークの利用者が流しているフローの送信者アドレス、受信者アドレス及び通信品質を含むフロー品質情報を収集するフロー品質情報収集部と、ネットワークの構成情報を収集する経路情報収集手段と、収集されたフロー品質情報及びネットワークの構成情報とに基づき、フローが経由するリンクを求め、かつフローの品質劣化の有無を判定し、その結果をテーブルとして管理するフロー品質/経由リンクテーブル管理部及びテーブル記憶部と、管理されているテーブルにおいて、1つ以上のフローに品質劣化があった場合、その品質劣化を起こした任意のフローの集合が経由するリンクの集合の部分集合の中で、品質劣化を起こした任意のフローが経由しているリンクを含む部分集合であって、かつ、最小の要素数をもつ部分集合を、品質劣化箇所として出力する品質劣化箇所推定部とを有することで、精度高くかつ高速な品質劣化箇所推定を可能にする技術が記載されている。
また、特開2010−147595号公報(特許文献3)には、管理対象装置とその装置への経路上の管理対象装置を示す経路情報とを対応づけて保持するネットワーク構成DB記憶部と、送達確認に対する応答がなかった場合は、その応答がなかった管理対象装置の経路情報を保持している情報から抽出して、その経路情報の管理対象装置に対する送達確認を実施し、その送達確認に対する応答のなかった管理対象装置を障害発生装置として特定するネットワーク管理部とを備えることで、ネットワーク層における障害監視を送達確認により実施し、ネットワーク障害の原因装置を迅速に切り分ける技術が記載されている。
特開2006−229421号公報 特開2006−238052号公報 特開2010−147595号公報
特許文献1に記載されたような技術では、ツリー型のネットワークトポロジから故障箇所の分岐部分を推定することができる。しかしながら、そのためには、例えばCAD等により予めネットワークのトポロジに係る情報を作成しておく必要があり、ネットワークの構成変更などを考慮すると、簡潔性や柔軟性に欠ける場合がある。また、ポーリングに対する応答の有無によって故障を判断しており、ネットワーク機器が論理障害等による「半死」の状態では的確に障害を判断することができない場合も生じ得る。
また、特許文献2に記載されたような技術では、パケットロスや遅延などの通信品質に基づいてフローの品質劣化を判断し、品質劣化を起こしたフローの集合が経由しているリンクの集合の情報に基づいて品質劣化箇所を推定することができる。しかしながら、ネットワークの障害により末端部分の機器等からは品質情報自体が収集できない場合も想定され、障害の態様によっては推定の精度が維持できない場合も生じ得る。
また、特許文献3に記載されたような技術では、管理対象装置への送達確認に対する応答がなかった場合は、その経路上の管理対象装置への送達確認を行うことで、障害の原因装置を特定することができるが、やはり、送達確認に対する応答の有無によって障害を判断しているため、ネットワーク機器が論理障害等による「半死」の状態では的確に障害を判断することができない場合も生じ得る。
そこで本発明の目的は、大規模なネットワークシステムにおける障害の際に、障害原因となったネットワーク機器が論理障害の場合も含めて、障害の被疑部位を迅速に推定して絞り込むことを可能とする障害部位推定システムおよび障害部位推定プログラムを提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。
本発明の代表的な実施の形態による障害部位推定システムは、ネットワーク機器からなるノードがツリー型に接続された構成を有する監視対象ネットワークにおいて障害が発生した場合に障害被疑部位を推定する障害部位推定システムであって、以下の特徴を有するものである。
すなわち、前記監視対象ネットワークの正常時に、前記監視対象ネットワーク内の各ノードについて、当該ノードに至る通信経路上の各ノードのインタフェースからなる経路情報を取得して、経路情報記録手段に記録する経路情報取得部と、前記監視対象ネットワークの障害時に、障害となっている各ノードに至る経路情報を前記経路情報記録手段からそれぞれ取得し、当該経路情報に含まれる各インタフェースに対して逐次ポーリングを行って、OKもしくはNGの結果を収集する逐次ポーリング部と、経路情報に含まれる各インタフェースにおいて、前記ポーリングの結果がNGとなった最も手前のインタフェースと、その1つ手前の前記ポーリングの結果がOKとなったインタフェースとを被疑ペアとし、障害となっている各ノードについて被疑ペアを抽出して被疑ペア集合を取得する被疑ペア抽出部と、前記被疑ペア集合と前記経路情報記録手段に記録された経路情報とに基いて、障害被疑部位を抽出して出力する障害部位出力部とを有することを特徴とする。
また、本発明は、コンピュータを上記のような障害部位推定システムとして動作させるプログラムにも適用することができる。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
すなわち、本発明の代表的な実施の形態によれば、大規模なネットワークシステムにおける障害の際に、障害原因となったネットワーク機器が論理障害の場合も含めて、障害の被疑部位を迅速に推定して絞り込むことが可能となる。
本発明の一実施の形態における障害部位推定システムを有するネットワーク監視システムの構成例について概要を示した図である。 本発明の一実施の形態におけるネットワーク監視の例について概要を示した図である。 本発明の一実施の形態における経路情報および品質情報を取得する処理の例について概要を示した図である。 本発明の一実施の形態における経路情報および品質情報を取得する処理の例について概要を示した図である。 本発明の一実施の形態における経路情報および品質情報を取得する処理の例について概要を示した図である。 本発明の一実施の形態におけるホップバイホップリストを得るためのソースコードの例を示した図である。 本発明の一実施の形態における障害が検知されたノードに対して被疑ペア集合を取得する処理の例について概要を示した図である。 本発明の一実施の形態における障害被疑部位を推定して出力する処理の例について概要を示したフローチャートである。 本発明の一実施の形態における被疑ペア集合に基いて障害被疑部位を推定する処理の例について概要を示した図である。 従来技術におけるネットワーク監視の例について概要を示した図である。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下においては、本発明の特徴を分かり易くするために、従来の技術と比較して説明する。
<概要>
図10は、従来技術におけるネットワーク監視の例について概要を示した図である。図10では、複数のルータ等のネットワーク(NW)機器310により構成されるツリー型の監視対象ネットワーク(NW)300に対して、ベンダー各社から提供される市販のツール等により構成される障害監視システム200が接続され、監視対象NW300での障害発生を常時監視する構成を示している。ここでは、障害監視システム200は、各NW機器310に対して、例えば、ICMP(Internet Control Message Protocol)/SNMP(Simple Network Management Protocol)ポーリングにより死活監視を行う。
ここで例えば、NW機器310aで障害が発生した場合、一般的な障害監視システム200では、ネットワーク構成上で配下の各機器(図中の網掛けされたNW機器310)についても、オペレータが確認する監視画面上で障害として表示してしまう。特に、NW機器310aが論理障害等による「半死」状態のような場合には、障害監視システム200による死活監視のポーリングのタイミングによって、障害機器がランダムかつ大量に表示され、監視画面上では、どの部位が障害の根本原因となっているのかを判別することが困難となる。
このような場合には、SE等の技術者が呼ばれて障害解析・切り分け等を行い、障害部位をNW機器310aであると特定することになる。しかしながら、ハードウェア障害ではなく論理障害の場合には、機器のログ等を参照しても障害の発生状況が不明である場合もあり、このような人手による手法では、障害部位を特定するまでに数十分から数時間という長時間を要してしまう場合がほとんどである。特に大規模システムでは、より迅速な障害部位の特定と対応策の実施が望まれる。
障害部位の正確な特定をシステムで自動的に行うには、これに応じた大掛かりな監視システムや解析システム等が必要となる。一方で、より低コストで簡易的に行うには、例えば、障害の被疑部位をある程度絞り込んで通知するところまでを自動化し、その後は絞り込まれた対象のNW機器310の全部、もしくはそこから人手によりさらに絞り込んだ一部の機器に対して対応策を実施することで、迅速に復旧を図ることが可能となる場合もある。
論理障害(例えば、ルーティングテーブルの異常など)の場合には、一般的な傾向として、例えば、NW機器310からエラーや異常なログなどは出力されず、一見して正常に稼働しているように見える場合がある。また、pingが通らなくなるケースの他にpingが通ったり通らなかったりするケースがあること、ショートフレームのpingは通るがロングフレームのpingは通らなかったりするケースがあることなどから、pingのやり方を工夫することで論理障害を把握することが可能である。また、論理障害の迅速な復旧のためには障害部位を特定して切り離す(電源断や再起動など)ことが効果的である。
そこで、本発明の一実施の形態である障害部位推定システムは、例えば、ハードウェア障害で障害監視システム200に大量に障害メッセージ等が表示されるような場合であっても、迅速に障害部位を特定して効率的にログの確認などが行えるようにするとともに、論理障害の場合にも迅速に障害の被疑部位を推定して絞り込み、対応策の実施を可能とする。
簡易的に迅速に障害部位を推定して絞り込むことを可能とするために、本実施の形態では、正常時に定期的に監視対象NW300における経路情報と品質情報を収集して記録しておき、障害時・異常時(障害監視システム200で障害を検知した場合)に、正常時に取得しておいた通信経路に従ってホップバイホップでpingによるポーリングを行う。このポーリングの成否(死活情報)に基づいて障害部位の集合を抽出し、そこから所定のロジックにより原因となる障害被疑部位を推定して抽出する。ここで、ポーリングの成否は、応答の有無だけに限らず、正常時の品質情報との比較に基づいて一定以上品質の劣化があった場合に障害部位と判断することで、論理障害のような「半死」の場合でも障害部位の推定を可能とする。
図2は、本発明の一実施の形態におけるネットワーク監視の例について概要を示した図である。ここでは、従来の障害監視システム200に加えて、障害部位の推定を行う障害部位推定システム100を有し、障害監視システム200等においてNW機器310aが原因の障害を検知した場合に(図10の場合と同様に、配下のNW機器310が障害状態として検知される)、障害部位推定システム100において、障害となっている各NW機器310への経路情報と、通信経路上の死活情報とを分析して、NW機器310aが障害の被疑部位であると推定することを可能とするものである。
<システム構成>
図1は、本発明の一実施の形態である障害部位推定システム100を有するネットワーク監視システムの構成例について概要を示した図である。ネットワーク監視システムは、上述の図2において示したように、監視対象NW300に対して、障害監視システム200と障害部位推定システム100が接続される構成を有している。
監視対象NW300は、ルータ等の多数のNW機器310から構成されるツリー型のネットワークであり、各NW機器310は必要に応じて経路情報を保持するルーティングテーブル311を有している。また、障害監視システム200は、上述したような、ベンダー各社から提供される市販のツール等により構成され、監視対象NW300の各NW機器310に対して、例えば、ICMP/SNMPポーリングにより死活監視を行って障害を検知し、これをネットワークトポロジを表現したマップ上に表示したり、障害通知メッセージとして表示したりして通知する情報処理システムである。
障害部位推定システム100は、障害監視システム200において監視対象NW300内の複数のノード(NW機器310)での障害を検知した場合に、各ノードへの経路情報と通信経路上の各ノードにおける死活情報とに基づいて、各ノード障害の原因となる通信経路上の共通部位を特定して障害部位として推定するシステムである。なお、本実施の形態では、障害部位推定システム100を障害監視システム200とは別個のシステムとして構成する例を示しているが、これらを1つのシステムとして構成することも当然可能である。
この障害部位推定システム100は、例えば、PC(Personal Computer)やサーバ機器などにより構成される情報処理システムであり、ソフトウェアとして実装される経路情報取得部110および障害部位推定部120と、データベースやファイルテーブル等として実装される経路情報データベース(DB)130などを有する。
経路情報取得部110は、監視対象NW300が正常時に、監視対象NW300内の全ノード(NW機器310)に対してping/tracerouteおよびSNMPによる経路探索を実行して正常時の経路情報を取得し、経路情報DB130に記録する機能を有する。経路情報の取得処理の内容については後述する。
障害部位推定部120は、監視対象NW300が障害時・異常時(障害監視システム200等によって障害を検知した場合)に、障害が検知されているNW機器310から原因となる障害の被疑部位を推定して出力する機能を有し、例えば、ホップバイホップ(逐次)ポーリング部121、被疑ペア抽出部122および障害部位出力部123などの各部を有する。ホップバイホップポーリング部121は、障害が検知されているIPアドレスに対して、経路情報DB130から正常時の経路情報を取得し、当該通信経路上にある全てのIPアドレス(ホップバイホップリスト)に対して逐次(ホップバイホップで)pingによるポーリングを行なって、結果(OK/NG)を収集することにより各ノードの状態を把握する機能を有する。
被疑ペア抽出部122は、ホップバイホップポーリング部121によるポーリングにおいて、pingの結果に異常があったIPアドレスのうち、通信経路上最も手前の(障害部位推定システム100に最も近い)IPアドレスと、通信経路上その1つ手前のホップのIPアドレス(pingの結果は正常)とを被疑ペアとして抽出し、これを障害が検知されている各IPアドレスに対して行なって、被疑ペア集合を得る機能を有する。障害部位出力部123は、被疑ペア抽出部122により抽出された被疑ペア集合をユニーク処理し、その結果に基づいて所定のロジックにより障害被疑部位を抽出して出力する機能を有する。障害被疑部位を推定する処理の内容についても後述する。
<経路情報取得処理>
以下では、まず、正常時における経路情報取得部110による経路情報の取得処理の内容について説明する。ここでは、監視対象NW300における全ての監視対象のノード(NW機器310)に至る正常時の通信経路上の完全なIPアドレスのリストを作成して経路情報とするとともに、当該通信経路(監視対象のノード)における正常時の品質情報を取得して経路情報DB130に記録する。なお、この処理は正常時に定期的に実行するか、少なくとも通信経路や通信品質に影響を与え得るシステムやネットワークの構成変更があった場合に実行するのが望ましい。
図3〜図5は、経路情報および品質情報を取得する処理の例について概要を示した図である。ここでは、障害部位推定システム100をノード“n00”とし、監視対象NW300内のルータ等の各NW機器310をノード“n01”、“n21”、“n22”、“n41”、“n42”、“n43”として表したツリー型のネットワーク構成の例を示している(レイヤー2スイッチ等の機器については省略している)。また、各ノードは、それぞれ、“i00”〜“i43”として表したインタフェース(IF)312を有していることを示している。なお、図3〜図5の例では、“i41”のインタフェース312(IPアドレス)についての経路情報および品質情報を取得する場合を例として説明している。
まず、正常時の品質情報を取得するため、図3に示すように、障害部位推定システム100(ノード“n00”)の経路情報取得部110は、監視対象のインタフェース312(“i41”)に対してpingコマンドを発行し、その応答からパケットロス率(loss rate)および平均遅延時間を取得する。図3の例では、pingによる“i41”のインタフェース312に対するechoパケットに対して応答としてecho−replyパケットを受け取る状態を矢印で示している。なお、取得した品質情報は、対象のインタフェース312と関連付けて経路情報DB130に記録する。なお、この品質情報を一定期間蓄積しておき、これに対して所定の統計処理を施すことで品質のベースラインを得るようにしてもよい。
次に、正常時の経路情報を取得するため、図4に示すように、監視対象のインタフェース312(“i41”)に対してtracerouteコマンドを発行し、当該インタフェース312に至るまでに経由するノードの情報を取得する。図4の例では、通信経路上のノード“n01”、“n21”、“n41”に対して順次echoパケットを送信し、応答としてtime−exceededパケットを受け取る状態を矢印で示している。
次に、tracerouteにより取得した各経由ノードに対して、それぞれSNMPによる経路探索を実行し、ホップするノード毎の入力のインタフェース312と出力のインタフェース312を全て取得する。図5の例では、宛先のノード“n41”に対する経由ノード“n01”、“n21”のそれぞれについて、snmpgetコマンドを発行した状態を矢印で示している。当該コマンドにより、各ノードのルーティングテーブル311等に基づいて得られるMIB(Management Information Base)の管理情報から、入力および出力のインタフェース312の情報を取得することができる。
上記の図4の例に示す処理により取得した経由ノードの情報と、図5の例に示す処理により取得した各経由ノードでの入力および出力のインタフェース312の情報とに基づいて、図5の下段の表に示すように、障害部位推定システム100(ノード“n00”)のインタフェース312(“i00”)から監視対象のNW機器310(ノード“n41”)のインタフェース312(“i41”)に至る通信経路上におけるインタフェース312のリスト(ホップバイホップリスト131)を作成する。作成したホップバイホップリスト131の情報は、監視対象のインタフェース312と関連付けて経路情報DB130に記録する。なお、品質情報と経路情報を取得する順序は上記の順に限らず、経路情報を先に取得してもよい。
図6は、ホップバイホップリスト131を得るためのソースコードの例を参考情報として示した図である。上段の図では、対象のネットワーク構成例として、障害部位推定システム100(ノード“n00”)およびそのインタフェース312のIPアドレスと、ターゲットのノード(NW機器310)およびインタフェース312、中継するノード(NW機器310)およびその入力と出力のインタフェース312とルーティングテーブル311を示している。また、下段の図では、上段の図に示したような構成において、ターゲットのインタフェース312に至るまでのインタフェース312のリストを得るためのソースコード111の一例を示している。
<障害部位推定処理>
以下では、障害時・異常時における障害部位推定部120による障害部位の推定処理の内容について説明する。障害監視システム200もしくは障害部位推定システム100が、例えば、監視対象NW300内の各ノードに対して定期的にpingによるポーリングを行う等して監視することによりネットワーク障害を検知した場合、障害部位推定部120のホップバイホップポーリング部121は、障害が検知された各インタフェース312(IPアドレス)に対してホップバイホップでpingを実行する。すなわち、対象のインタフェース312に至る経路情報(ホップバイホップリスト131)を経路情報DB130から取得し、リストに含まれる各インタフェース312のIPアドレスに対してそれぞれpingによるポーリングを行なって、通信のOK/NGを判定する。
なお、pingによるポーリングにおける障害の検知や、通信のOK/NGの判定の際は、pingの応答を受信したか否かのみで判定するのではなく、パケットロス率や平均遅延などの品質情報の値について、経路情報DB130に記録された正常時の品質情報(ベースライン)と比較することで判定する。例えば、現在の各品質情報の値がベースラインから所定の閾値以上低下しているか否かにより判定してもよいし、統計的な手法を利用して障害か否かを推測するようにしてもよい。
さらに、障害部位推定部120の被疑ペア抽出部122が、上記のポーリングの結果がNGであったインタフェース312のうち、通信経路上最も手前のインタフェース312と、通信経路上その1つ手前のホップのインタフェース312とを被疑ペアとして抽出する。これを障害が検知されている各インタフェース312に対して行なって、被疑ペア集合132を取得する。
図7は、障害が検知されたノードに対して被疑ペア集合132を取得する処理の例について概要を示した図である。ここでは、図の上段左側に示した監視対象NW300の構成(図3〜図5の例で示したものと同様)において、“i21”のインタフェース312が障害となった場合を例としている。
このとき、障害監視システム200において障害が検知される(pingによるポーリングがNGとなる)各ノード(“n21”、“n41”、“n42”)に対して、ホップバイホップポーリング部121が、通信経路上の各インタフェース312に対してホップバイホップでpingによるポーリングを行う。このとき、図7の例では、例えば、“i21”、“i31”、“i32”、“i41”、“i42”の各インタフェース312(上段左側の図中で網掛けで示したもの)ではポーリングがNGとなり、他のインタフェース312ではOKとなる。このポーリングの結果をホップバイホップリスト131の表に追記・反映させたものが図7の上段右側の表である。表中のOK/NGの値は、対象のインタフェース312に対するpingによるポーリングの結果を示している。
ここで、各インタフェース312に対するホップバイホップでのポーリングの結果がNGであった経路上のインタフェース312のうち、最も手前のインタフェース312と、その1つ手前のホップのインタフェース312とを被疑ペアとして抽出する。すなわち、ホップバイホップリスト131において、ポーリングの結果がOKからNGに変わる境界部分のインタフェース312を被疑ペアとして抽出し、被疑ペア集合132(図7の下段の表)を作成する。
被疑ペア集合132において、“NG”の項目は境界部分におけるポーリング結果がNGのインタフェース312を示し、“PREV”の項目はその手前のホップのポーリング結果がOKのインタフェース312を示している。図7の例では、全ての監視対象のインタフェース312において、“PREV”が“i11”、“NG”が“i21”となっている。
次に、障害部位推定部120の障害部位出力部123が、被疑ペア集合132および経路情報DB130に記録された経路情報に基いて、障害被疑部位を推定して出力する。図8は、障害被疑部位を推定して出力する処理の例について概要を示したフローチャートである。まず、被疑ペア集合132の各エントリのNG項目のインタフェース312に対してユニーク処理(重複するものを排除)する(S01)。次に、ユニーク処理した結果のエントリ数(NG項目のインタフェース312の数)が1であるか否かを判定する(S02)。エントリ数が1である場合は、当該エントリのNG項目のインタフェース312を障害被疑部位として出力する(パターン1)(S03)。すなわち、図示するように、OKとNGの境界におけるNGのインタフェース312(1つだけ存在する)を障害被疑部位として出力する。
ステップS02においてNG項目のエントリが複数ある場合は、さらに、被疑ペア集合132の各エントリ(NG項目についてユニーク処理済み)のPREV項目のインタフェース312に対してユニーク処理する(S04)。次に、ユニーク処理した結果のエントリ数(PREV項目のインタフェース312の数)が1であるか否かを判定する(S05)。エントリ数が1である場合は、当該エントリのPREV項目のインタフェース312と、NG項目のインタフェース312との間の区間を障害被疑部位として出力する(パターン2)(S06)。すなわち、図示するように、OKとNGの境界部分の区間(図示するようにこの部分にプロバイダ等により提供されるネットワークを含む場合もある)を障害被疑部位として出力する。
ステップS05においてPREV項目のエントリが複数ある場合は、これらのインタフェース312のユニーク集合を障害被疑部位として出力する(パターン3)(S07)。すなわち、図示するように、OKとNGの境界におけるOKのインタフェース312(複数存在する)を障害被疑部位として出力する。
図9は、被疑ペア集合132に基いて障害被疑部位を推定する処理の例について概要を示した図である。ここでは、図7に示した例において取得した被疑ペア集合132に基いて、図8に示した障害被疑部位の推定手法の例によって障害被疑部位を推定する場合を示している。図9の例では、被疑ペア集合132に対して、図8のステップS01の処理によりNG項目のインタフェース312についてユニーク処理を行った結果、NG項目のエントリは“i21”の1レコードのみとなるため、パターン1により、当該インタフェース“i21”を障害被疑部位と推定して出力する。
出力の態様は特に限定されず、例えば、障害監視システム200などの画面における監視対象NW300のトポロジを表したマップ上に障害被疑部位を特定可能なように強調表示してもよい。また、障害被疑部位に該当するIPアドレスやインタフェース312、NW機器310の識別情報などをメッセージとして表示する構成であってもよい。ここで出力される障害被疑部位は、障害の原因部位であると疑われる部位であり、正確な原因部位以外の構成要素を含む場合もあり得るが、迅速な障害対応という観点では非常に重要な情報となるものである。
以上に説明したように、本発明の一実施の形態である障害部位推定システム100によれば、正常時に定期的に監視対象NW300における経路情報と品質情報を収集して記録しておき、障害時・異常時(障害監視システム200で障害を検知した場合)に、正常時に取得した通信経路に従ってホップバイホップでpingによるポーリングを行う。このポーリングの成否(死活情報)に基づいて障害部位の集合を抽出し、そこから所定のロジックにより原因となる障害被疑部位を推定して抽出する。ここで、ポーリングの成否は、応答の有無だけに限らず、正常時の品質情報との比較に基づいて一定以上品質の劣化があった場合に障害部位と判断することで、論理障害のような「半死」の場合でも障害部位の推定を可能とする。
これにより、大規模なネットワーク障害の場合でも、障害部位推定システム100において、障害となっている各ノード(NW機器310)への経路情報と、通信経路上の死活情報とを分析して、簡易的に迅速に障害被疑部位を推定して絞り込むことが可能となる。また、難しい操作を必要とせず、オペレータ等でも容易に障害被疑部位の推定を行うことが可能であるため、早期に障害被疑部位を絞り込み、状況によっては即時に対応策をとることも可能となる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。
本発明は、ネットワーク障害の際に障害部位を推定する障害部位推定システムおよび障害部位推定プログラムに利用可能である。
1…ネットワーク(NW)監視システム、
100…障害部位推定システム、110…経路情報取得部、111…ソースコード、120…障害部位推定部、121…ホップバイホップ(逐次)ポーリング部、122…被疑ペア抽出部、123…障害部位出力部、130…経路情報データベース(DB)、131…ホップバイホップリスト、132…被疑ペア集合、
200…障害監視システム、
300…監視対象ネットワーク(NW)、310、310a…ネットワーク(NW)機器、311…ルーティングテーブル、312…インタフェース。

Claims (8)

  1. ネットワーク機器からなるノードがツリー型に接続された構成を有する監視対象ネットワークにおいて障害が発生した場合に障害被疑部位を推定する障害部位推定システムであって、
    前記監視対象ネットワークの正常時に、前記監視対象ネットワーク内の各ノードについて、当該ノードに至る通信経路上の各ノードのインタフェースからなる経路情報を取得して、経路情報記録手段に記録する経路情報取得部と、
    前記監視対象ネットワークの障害時に、障害となっている各ノードに至る経路情報を前記経路情報記録手段からそれぞれ取得し、当該経路情報に含まれる各インタフェースに対して逐次ポーリングを行って、OKもしくはNGの結果を収集する逐次ポーリング部と、
    経路情報に含まれる各インタフェースにおいて、前記ポーリングの結果がNGとなった最も手前のインタフェースと、その1つ手前の前記ポーリングの結果がOKとなったインタフェースとを被疑ペアとし、障害となっている各ノードについて被疑ペアを抽出して被疑ペア集合を取得する被疑ペア抽出部と、
    前記被疑ペア集合と前記経路情報記録手段に記録された経路情報とに基いて、障害被疑部位を抽出して出力する障害部位出力部とを有することを特徴とする障害部位推定システム。
  2. 請求項1に記載の障害部位推定システムにおいて、
    前記経路情報取得部は、前記監視対象ネットワークの正常時に、前記監視対象ネットワーク内の各ノードに至る通信経路についての品質情報を取得して前記経路情報記録手段に記録し、
    前記逐次ポーリング部は、前記逐次ポーリングの際に取得した品質情報と、前記経路情報記録手段に記録された対応する通信経路についての正常時の品質情報との比較に基いて、前記逐次ポーリングの結果がOKもしくはNGであるかを判断することを特徴とする障害部位推定システム。
  3. 請求項2に記載の障害部位推定システムにおいて、
    前記経路情報記録手段に記録する品質情報は、pingコマンドに対する応答に含まれるパケットロス率および/または平均遅延時間の情報であることを特徴とする障害部位推定システム。
  4. 請求項1〜3のいずれか1項に記載の障害部位推定システムにおいて、
    前記経路情報取得部は、前記監視対象ネットワーク内の各ノードに対してtracerouteコマンドを発行して通信経路上のノードの情報を取得し、取得した通信経路上の各ノードに対してSNMPによる経路探索を行なって、入力および/または出力のインタフェースの情報を取得することによって経理情報を取得することを特徴とする障害部位推定システム。
  5. 請求項1〜4のいずれか1項に記載の障害部位推定システムにおいて、
    前記障害部位出力部は、前記被疑ペア集合における、前記ポーリングの結果がNGとなったインタフェースについて重複を排除したエントリの数が1の場合は、当該エントリに係る前記ポーリングの結果がNGとなったインタフェースを障害被疑部位として出力することを特徴とする障害部位推定システム。
  6. 請求項1〜5のいずれか1項に記載の障害部位推定システムにおいて、
    前記障害部位出力部は、前記被疑ペア集合における、前記ポーリングの結果がNGとなったインタフェースについて重複を排除したエントリの数が複数であり、かつ、これらのエントリにおいて、前記ポーリングの結果がOKとなったインタフェースについて重複を排除したエントリの数が1の場合は、当該エントリに係る前記ポーリングの結果がOKとなったインタフェースと、前記ポーリングの結果がNGとなったインタフェースとの間の区間を障害被疑部位として出力することを特徴とする障害部位推定システム。
  7. 請求項1〜6のいずれか1項に記載の障害部位推定システムにおいて、
    前記障害部位出力部は、前記被疑ペア集合における、前記ポーリングの結果がNGとなったインタフェースについて重複を排除したエントリの数が複数であり、かつ、これらのエントリにおいて、前記ポーリングの結果がOKとなったインタフェースについて重複を排除したエントリの数が複数である場合は、当該エントリに係る前記ポーリングの結果がOKとなったインタフェースを障害被疑部位として出力することを特徴とする障害部位推定システム。
  8. ネットワーク機器からなるノードがツリー型に接続された構成を有する監視対象ネットワークにおいて障害が発生した場合に障害被疑部位を推定する障害部位推定システムとしてコンピュータを動作させる障害部位推定プログラムであって、
    前記監視対象ネットワークの正常時に、前記監視対象ネットワーク内の各ノードについて、当該ノードに至る通信経路上の各ノードのインタフェースからなる経路情報を取得して、経路情報記録手段に記録する経路情報取得処理と、
    前記監視対象ネットワークの障害時に、障害となっている各ノードに至る経路情報を前記経路情報記録手段からそれぞれ取得し、当該経路情報に含まれる各インタフェースに対して逐次ポーリングを行って、OKもしくはNGの結果を収集する逐次ポーリング処理と、
    経路情報に含まれる各インタフェースにおいて、前記ポーリングの結果がNGとなった最も手前のインタフェースと、その1つ手前の前記ポーリングの結果がOKとなったインタフェースとを被疑ペアとし、障害となっている各ノードについて被疑ペアを抽出して被疑ペア集合を取得する被疑ペア抽出処理と、
    前記被疑ペア集合と前記経路情報記録手段に記録された経路情報とに基いて、障害被疑部位を抽出して出力する障害部位出力処理とをコンピュータに実行させることを特徴とする障害部位推定プログラム。
JP2012194743A 2012-09-05 2012-09-05 障害部位推定システムおよび障害部位推定プログラム Pending JP2014053658A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2012194743A JP2014053658A (ja) 2012-09-05 2012-09-05 障害部位推定システムおよび障害部位推定プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2012194743A JP2014053658A (ja) 2012-09-05 2012-09-05 障害部位推定システムおよび障害部位推定プログラム

Publications (1)

Publication Number Publication Date
JP2014053658A true JP2014053658A (ja) 2014-03-20

Family

ID=50611760

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012194743A Pending JP2014053658A (ja) 2012-09-05 2012-09-05 障害部位推定システムおよび障害部位推定プログラム

Country Status (1)

Country Link
JP (1) JP2014053658A (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018151290A1 (ja) * 2017-02-20 2018-08-23 日本電気株式会社 情報処理装置、情報処理方法および記憶媒体
JP2020061685A (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 故障箇所推定方法及び故障箇所推定装置
JP2020068510A (ja) * 2018-10-26 2020-04-30 日本電信電話株式会社 推定方法、推定装置及び推定プログラム
JPWO2020179704A1 (ja) * 2019-03-01 2020-09-10

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2018151290A1 (ja) * 2017-02-20 2018-08-23 日本電気株式会社 情報処理装置、情報処理方法および記憶媒体
JPWO2018151290A1 (ja) * 2017-02-20 2019-12-19 日本電気株式会社 情報処理装置、情報処理方法および記憶媒体
JP7110990B2 (ja) 2017-02-20 2022-08-02 日本電気株式会社 情報処理装置、情報処理方法および記憶媒体
JP2020061685A (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 故障箇所推定方法及び故障箇所推定装置
WO2020075587A1 (ja) * 2018-10-11 2020-04-16 日本電信電話株式会社 故障箇所推定方法及び故障箇所推定装置
US11516073B2 (en) 2018-10-11 2022-11-29 Nippon Telegraph And Telephone Corporation Malfunction point estimation method and malfunction point estimation apparatus
JP2020068510A (ja) * 2018-10-26 2020-04-30 日本電信電話株式会社 推定方法、推定装置及び推定プログラム
WO2020085050A1 (ja) * 2018-10-26 2020-04-30 日本電信電話株式会社 推定方法、推定装置及び推定プログラム
US11902137B2 (en) 2018-10-26 2024-02-13 Nippon Telegraph And Telephone Corporation Service path failure location estimation method, apparatus, and program
JPWO2020179704A1 (ja) * 2019-03-01 2020-09-10

Similar Documents

Publication Publication Date Title
US11038744B2 (en) Triggered in-band operations, administration, and maintenance in a network environment
US10560311B2 (en) Management apparatus, management method, and recording medium
JP4758259B2 (ja) ネットワーク監視装置及び方法
EP3882773A1 (en) Method and system for automatic real-time causality analysis of end user impacting system anomalies using causality rules and topological understanding of the system to effectively filter relevant monitoring data
Yan et al. G-rca: a generic root cause analysis platform for service quality management in large ip networks
CN104798341B (zh) 在电子网络上表征服务水平
US20110270957A1 (en) Method and system for logging trace events of a network device
JP4412031B2 (ja) ネットワーク監視システム及びその方法、プログラム
EP2081321A2 (en) Sampling apparatus distinguishing a failure in a network even by using a single sampling and a method therefor
US8245079B2 (en) Correlation of network alarm messages based on alarm time
EP3326330A1 (en) Methods, systems, and apparatus to generate information transmission performance alerts
US20140355453A1 (en) Method and arrangement for fault analysis in a multi-layer network
JP5342082B1 (ja) ネットワーク障害解析システムおよびネットワーク障害解析プログラム
CN113037564B (zh) 一种网络故障诊断方法及装置
US7564796B2 (en) Method and system for managing a network slowdown
JP2014053658A (ja) 障害部位推定システムおよび障害部位推定プログラム
JP4464256B2 (ja) ネットワーク上位監視装置
CN109218050B (zh) 一种域名系统故障处理方法和系统
CN114338103A (zh) 一种基于tr069协议结合日志分析的异常流量处方法及系统
KR100887874B1 (ko) 인터넷 망의 장애 관리 시스템 및 그 방법
JP2004104540A (ja) ネットワーク性能障害分析支援システム
CN118250154A (zh) 故障定位方法、装置、设备及存储介质
CN112636965A (zh) 一种云环境下虚机网络连通性监控方法
US20250016042A1 (en) Enhanced event-driven diagnostics for communication networks
CN112994910A (zh) 网络端口告警信息的处理方法及装置