JP3722277B2 - インターネットの障害推定方法 - Google Patents
インターネットの障害推定方法 Download PDFInfo
- Publication number
- JP3722277B2 JP3722277B2 JP2000276881A JP2000276881A JP3722277B2 JP 3722277 B2 JP3722277 B2 JP 3722277B2 JP 2000276881 A JP2000276881 A JP 2000276881A JP 2000276881 A JP2000276881 A JP 2000276881A JP 3722277 B2 JP3722277 B2 JP 3722277B2
- Authority
- JP
- Japan
- Prior art keywords
- failure
- procedure
- network
- level
- retry
- 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
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、インターネットの障害推定方法に係り、特に、ハードウェア的な障害のみならず、ソウトウェア的な障害の原因や部位も推定できるインターネットの障害推定方法に関する。
【０００２】
【従来の技術】
インターネットの普及に伴い、トラヒックの集中によるネットワークやサーバの輻輳、システムダウンなどによる通信不能などの障害が問題となっている。このような障害発生時には、障害が発生した個所とその原因を早急に特定することが必要である。このため、従来からＳＮＭＰ（Simple Network Management Protocol）に基づくネットワーク管理方式や、回線あるいは端末内を監視するモニタリング方式による障害検知システムが提案されている。
【０００３】
ところで、インターネットにおける障害には、図６にも例示したように、回線切断やルータ・サーバの故障に代表されるハードウェア的な障害のみならず、輻輳、プログラムバグ、運用者の操作誤り、プロトコル手順などに起因するソフトウェア的な障害が考えられる。
【０００４】
【発明が解決しようとする課題】
上記したように、インターネットにおいて有効な障害検知およびその原因推定を実現するためには、従来のようなハードウェア的障害にとどまらず、ソフトウェア的な障害の検知も可能とする必要がある。しかしながら、上記した従来のＳＮＭＰに基づくネットワーク管理方式は、ハードウェア的障害の検知を基本としており、ソフトウェア的な障害を検知することは難しかった。
【０００５】
さらに、従来のモニタリング方式では、障害検知の対象となる個所の全てに監視装置を設置しなければならないので、今日のように広く普及したインターネット環境には適さないという問題があった。
【０００６】
本発明の目的は、上記した従来技術の課題を解決し、通信回線や経路情報交換の監視と、障害のあった通信の再試行を組み合わせて、プロトコル手順や操作誤りなどに起因するさまざまな障害を検出し、その原因を推定できるとともに、多数の設備を導入する必要のないインターネットの障害推定方法を提供することにある。
【０００７】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、独立に管理・運営されるネットワークごとに障害検知サーバを設け、第１のネットワーク上のアクセス元端末と第２のネットワーク上のアクセス先端末との間に発生した通信障害の原因を推定するインターネットの障害推定方法において、前記第１のネットワーク上の障害検知サーバは、前記アクセス元端末とアクセス先端末との間の通信障害を前記アクセス元端末から申告され、その後、前記申告内容に基づいて、障害の発生した通信を再試行する再試行手順と、前記再試行で収集した障害情報に基づいて障害原因を推定する障害推定手順とを実行し、前記再試行手順では、前記障害の発生した通信の経路上に配置された各ネットワーク機器に対して、ＩＰレベルで各ネットワーク機器およびそのリンクの障害状況を確認する下位レベル再試行と、アクセス元端末として振るまってアクセス先端末とＴＣＰおよび上位レベルの通信を行い、その障害状況を確認する上位レベル再試行とを実行し、前記障害推定手順では、前記下位レベルおよび上位レベル再試行で収集した障害情報に基づいて障害原因を推定することを特徴とする。
【０００８】
上記した特徴によれば、再試行手順における下位レベルの再試行では、障害の発生している通信で使用される通信経路上の各ルータに対して、ルータやそのリンクの障害／輻輳状況を確認できる。また、上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認できる。したがって、輻輳、プログラムバグ、プロトコル手順などに起因するソフトウェア的な障害を検知できる。
【０００９】
【発明の実施の形態】
以下、図面を参照して本発明を詳細に説明する。図１は、本発明の障害推定方法を適用したネットワークの構成を模式的に示した図であり、図２、３、４は、各ネットワーク機器間で実行される通信プロトコルのシーケンスを示した図である。
【００１０】
本実施形態では、独立に管理・運営されるＬＡＮやＩＳＰ（Internet Service Provider ：インターネット接続事業者）等のネットワークごとに障害検知サーバを設け、第１のネットワーク上のアクセス元端末と第２のネットワーク上のアクセス先端末との間に発生した障害を検知する。
【００１１】
図１において、ＩＳＰ１では、アクセス元端末としてのユーザ端末Ｔが、ネットワーク機器としてのルータＲ１、Ｒ２を介してＩＳＰ２に接続されている。各ルータＲ１、Ｒ２およびそのリンクの状況は障害検知サーバＳ１により監視されている。ＩＳＰ２では、アクセス先端末としてのＷＷＷサーバＷが、ネットワーク機器としてのルータＲ３、Ｒ４，Ｒ５を選択的に介してＩＳＰ１と接続されている。各ルータＲ３、Ｒ４，Ｒ５およびそのリンクの状況は障害検知サーバＳ２により監視されている。
【００１２】
以下、本実施形態における障害推定方法を、ＩＳＰ１に属するユーザ端末ＴがＩＳＰ２に属するＷＷＷサーバＷにアクセスした際に生じる応答時間や転送スループットの悪化を例にして説明する。
【００１３】
ソフトウェア的な障害を検知するためには、通信における例外的なやり取りを検出し、その原因を解析する必要がある。すなわち、障害検知を実現するためには、ＴＣＰ／ＩＰプロトコルの振舞いを解釈する必要がある。そこで、本実施形態では、ＴＣＰ／ＩＰプロトコルの振舞いを解釈するために、障害の発生した通信を再試行する手順［手順３］を新たに採用し、さらには、ハードウェア的な障害を検知する既存の手順［手順１、２］をこれに組み合わせ、各手順［手順１〜３］により得られた障害情報から総合的に判断して、障害の発生した部位およびその原因を推定［手順４］するようにしている。
【００１４】
図５は、上記した各手順を実行する本発明の障害検知サーバＳ１の主要部の構成を示したブロック図であり、ユーザ端末Ｔからの障害申告を受け付ける障害申告受付部１００と、前記手順１を実行するＳＮＭＰ実行部１０１と、前記手順２を実行する経路変更履歴収集部１０２と、前記手順３を実行する再試行部１０３と、前記手順４を実行する障害原因推定部１０４とを含む。
【００１５】
さらに、前記再試行部１０３には、障害の発生した通信経路上の各ルータに対して、当該各ルータおよびそのリンクの障害状況を順次確信する下位レベル再試行部１０３ａと、アクセス先端末間との間でＴＣＰおよび上位レベルで通信を行い、その障害状況を確認する上位レベル再試行部１０３ｂとを設けた。以下、各手順について説明する。
【００１６】
手順１：ＳＮＭＰによるハードウェア障害検知
各障害検知サーバＳ１、Ｓ２は、それぞれ自身の管理下にあるネットワークＩＳＰ１，ＩＳＰ２内のルータやサーバなどのネットワーク機器とＳＮＭＰにより通信を行う。そして、定期的に各ネットワーク機器の状況を調査し、回線切断やルータの故障などのハードウェア障害が生じているかどうかを調べる。図１の例では、ＩＳＰ２の障害検知サーバＳ２が、ＳＮＭＰによりルータＲ３、Ｒ５から得た情報に基づいて、ルータＲ３、Ｒ５間のリンクに障害が発生したことを検知できる［図２(a) ］。
【００１７】
手順２：経路情報の変更履歴に基づく障害検知
各障害検知サーバＳ１、Ｓ２は、通常のルータとして機能することで他のルータとルーチングプロトコルに従った通信を行い、経路情報の変更に関する履歴情報を得る。各障害検知サーバＳ１、Ｓ２は、経路変更履歴を受信するたびに、ネットワーク全体の経路状況を再計算し、経路情報の頻繁な変更、特定の地域への経路情報の欠如などを検査する。
【００１８】
図１の例では、障害検知サーバＳ２がルーチングプロトコルを実行することにより、ルータＲ５においてルータＲ３宛てのパケット転送がルータＲ４経由の経路に変更され、ルータＲ３においてルータＲ５宛てのパケット転送がルータＲ４経由に変更されたことを把握する［図２(b) ］。
【００１９】
手順３：通信再試行による障害検知
ユーザ端末Ｔから障害内容の申告を受けた障害検知サーバＳ１が、そのユーザが行おうとした通信を、下位（ＩＰ）レベルおよび上位（ＴＣＰ以上）レベルで再試行する。
【００２０】
下位レベルの再試行では、その通信で使用される通信経路上の各ルータに対して、ルータやリンクの障害／輻輳状況を確認する。上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認する。以下、各レベルでの再試行について説明する。
【００２１】
手順３−１：下位レベルの再試行
ユーザ端末Ｔが属するネットワークＩＳＰ１の障害検知サーバＳ１は、ユーザ端末Ｔが最初に通信するルータＲ１の輻輳状況や故障状況を調査するとともに、通信相手にパケットを転送するためのネクストホップルータ（本実施形態では、ルータＲ２）を検索する。この処理を繰り返し、ネクストホップルータが他のネットワークに属するルータとなった場合、障害検知サーバＳ１は、次のネットワークの障害検知サーバに、ユーザ端末Ｔのアドレス、サーバのアドレス、ユーザ端末Ｔに対応する障害検知サーバなどの情報とともに、ＩＰレベルの再試行を依頼する。
【００２２】
再試行を依頼された障害検知サーバ（本実施形態では、障害検知サーバＳ２）は同様な処理を繰り返す。さらに、このような再試行については、ＷＷＷサーバＷからユーザ端末Ｔへの方向についても行う。以下、下位レベルの再試行方法を、図３のシーケンス図を参照して説明する。
【００２３】
初めに、ユーザ端末Ｔのユーザが、ＷＷＷサーバＷからの応答速度やデータ転送スループットが低下したことを認識すると、ＩＳＰ１の障害検知サーバＳ１に対して、障害が発生している旨およびその内容を申告する［図３(c) ］。前記申告内容は、例えば通信で使用したアプリケーションの種別、通信相手のＵＲＬやメールアドレスなどである。
【００２４】
障害検知サーバＳ１は、前記申告を検知すると、ユーザ端末Ｔが接続されているルータＲ１に対し、回線障害等の有無を問い合わせるとともに、ＷＷＷサーバＷのアドレスに基づいてネクストホップであるルータＲ２を検索する。ルータＲ１において特に問題がなければ、ネクストホップのルータＲ２に対して同様な処理を行う［同図(d) ］。
【００２５】
ルータＲ２のネクストホップであるルータＲ３はＩＳＰ２に属するため、障害検知サーバＴは、ＩＳＰ２の障害検知サーバＳ２に対して、通信相手ＷＷＷサーバＷのアドレスなどの必要な情報とともに、下位レベルの再試行による障害検知作業を依頼する［同図(e) ］。
【００２６】
障害検知サーバＳ２は、はじめにルータＲ３に対して問い合わせを行う。本実施形態では、この問い合わせ結果から、ルータＲ３、Ｒ５間のリンクで障害が発生し、ルータＲ３からルータＲ５へのパケット転送経路が、ルータＲ４経由の経路に変更されていることを確認する［同図(f) ］。
【００２７】
障害検知サーバＳ２は、同様にルータＲ４、Ｒ５にも問い合わせる。本実施形態では、この問い合わせ結果から、ルータＲ５内での出力バッファ溢れなどが原因で、ルータＲ５からルータＲ４へのリンクが輻輳していることを検知する［同図(g) ］。
【００２８】
以下、上記したＩＰレベルの再試行の実現形態の詳細について説明する。ＩＰレベルの再試行においては、障害検知サーバＳ１は、申告のあった通信において経由したルータの状態を調査する。この状態の検査およびネクストホップルータの検索は、標準で定められているＭＩＢ（Management Information Base ）の内、以下の情報(1) 、(2) を利用する。
【００２９】
(1) ＩＰルーチングテーブル（IP Route Table）の、あて先アドレス（IP Route Dest)、インタフェース識別子（IP Route If Index ）、ネクストホップのアドレス（IP Route Next Hop ）。
【００３０】
(2) インタフェーステーブル (if Table) の、インタフェース速度（ifSpeed ）) 、入出力バイト・パケット数（InOctets, OutOctets, InUcastPkts, OutUcastPkts）、入出力廃棄パケット数（InDiscards, OutDiscards ）、出力キュー長（OutQLen ）。
【００３１】
これらのうち、入出力バイト・パケット数、入出力廃棄パケット数、出力キュー長などについては、定期的に読み出しを行って時間的変化を記録し、再試行時におけるネットワークの状況が正確に判定可能となるようにする。また、隣接するネットワークの障害検知サーバＳ２との間では、事前に検知サーバ間の契約を締結しておくこととする。このため、ＩＰレベルの再試行において管理ドメインをまたがる場合は、次のドメイン（Autonomous System ）がどれかによって、再試行を依頼する障害検知サーバが決定可能であるとする。
【００３２】
手順３−２：上位レベルの再試行
上位レベルの再試行では、初めに、ユーザ端末Ｔに対応する障害検知サーバＳ１が、ユーザ端末Ｔの代わりにアクセス先端末のＷＷＷサーバＷと通信し、その中で、通信に使用される各種のプロトコルの手順を解釈し、データの再送や異常処理の起動の状況などのプロトコルの振舞いを検査し、障害を検知する。また、サーバ輻輳を確認するために、通信相手のＷＷＷサーバＷに最も近い障害検知サーバＳ２からも再試行を行う。
【００３３】
さらに、上位レベルのプロトコルに関して、ユーザ端末ＴとＷＷＷサーバＷとが通信した場合のみに発生する固有障害を検出するために、ユーザ端末Ｔにも障害検知サーバＳ１と通信させ、その中で障害検知サーバＳ１がＷＷＷサーバＷになり代わって、ユーザ端末Ｔにおける各種プロトコルの振舞いを検査する。ここでは遅延の挿入や、急激なパケット損失・遅延の発生などを行う。以下、上位レベルの再試行を、図４のシーケンス図を参照して説明する。
【００３４】
ＩＳＰ１の障害検知サーバＳ１は、ユーザ端末Ｔに成り代わってＷＷＷサーバＷとの通信を再試行し、ＷＷＷサーバ側のプロトコルの振舞い検査や関連するパラメータ設定値の推定などを行うとともに、応答時間／スループットの測定を行う［同図(h) ］。この結果、本実施形態では、障害検知サーバＳ１からＷＷＷサーバＷにアクセスした場合も応答速度が悪いという結果が得られる。
【００３５】
一方、障害検知サーバＳ１は、ＷＷＷサーバＷに成り代わってユーザ端末Ｔとの間でも上位レベルの再試行を行い、ユーザ端末Ｔ側のプロトコルの振舞い検査や関連するパラメータ設定値の推定を行い、ユーザ端末Ｔの問題や、パラメータ設定に関するＷＷＷサーバＷとの相性の問題などを検査する［同図(i) ］。本実施形態では、ユーザ端末Ｔには問題がないとの結果が得られたものとする。
【００３６】
さらに、障害検知サーバＳ１は、ＷＷＷサーバＷに隣接している障害検知サーバＳ２に対しても、必要な情報とともに上位レベルでの再試行を依頼する［同図(j) ］。障害検知サーバＳ２はユーザ端末に成り代わって通信を行うが、本実施形態では、応答速度に問題がないとの結果が得られたものとする。
【００３７】
手順４：障害検知サーバにおける結果の総合判断
以上の各手順により得られた障害情報に基づいて、障害検知サーバＳ１は以下の点を把握する。
【００３８】
▲１▼ＳＮＭＰ［手順１］／ルーチングプロトコル［手順２］の実行によって、ルータＲ３−Ｒ５間のリンクに障害が発生し、ルータＲ３−Ｒ５間のＩＰパケット転送がルータＲ４経由に変更された。
【００３９】
▲２▼ＩＰレベルでの再試行［手順３−１］により、ユーザ端末ＴからＷＷＷサーバＷへの通信経路にルータＲ４、Ｒ５が含まれ、ルータＲ５からルータＲ４へのリンクに輻輳が生じている。
【００４０】
▲３▼上位レベルでの再試行［手順３−２］により、ユーザ端末ＴやＷＷＷサーバＷのプロトコル動作に問題はなく、ＩＳＰ２の障害検知サーバＳ２からＷＷＷサーバＷへのアクセスでも応答速度に問題がないが、ＩＳＰ１の障害検知サーバＳ１からＷＷＷサーバＷへのアクセスでは応答速度に問題がある。
【００４１】
障害検知サーバＳ１は、以上の情報を総合的に判断し、「ユーザ端末ＴとＷＷＷサーバＷ間の通常の経路であるルータＲ３−Ｒ５間のリンクで障害が発生し、ルータＲ４経由の迂回経路が設定されたが、ルータＲ５からルータＲ４へのリンクで輻輳が発生したために応答速度が低下した」という結果をユーザに回答する［同図(k) ］。
【００４２】
上記したように、本実施形態によれば、ユーザから通信障害の申告を受けた障害検知サーバが、この障害が生じている通信を下位レベルおよび上位レベルで再試行し、再試行時に各ルータおよび他の障害検知サーバから得られる情報に基づいて、各ルータおよびそのリンクの状況を認識できる。
【００４３】
なお、通常の通信プロトコルでは、上記したＷＷＷサーバＷへのアクセスに先立ち、ユーザ端末Ｔは、ＷＷＷサーバＷのドメイン名からＩＰアドレスを得るために、ＤＮＳに従ってネームサーバへアクセスする。このネームサーバとの通信に障害が発生した場合には、前記再試行手順３を以下のように適用することができる。
【００４４】
ユーザ端末Ｔは通常、ＩＰアドレスを取得するためにローカルなネームサーバにアクセスする。また、各ドメイン名に対しては、権威あるネームサーバ（Authoritative Server）が割り当てられている。そこで、論理名の正当性を確認するために、まず、ユーザがアクセスしたドメイン名に対応する権威あるサーバのアドレスの取得を試みる。そのサーバが不明の場合は、この通信をＩＰレベルで再試行し、ネームサーバが正しく動作している場合は、与えられたドメイン名が不良であったと判断する。
【００４５】
次に、ローカルなネームサーバにキャッシュされているＩＰアドレスと、権威あるネームサーバで照会したＩＰアドレスとを比較して、ローカルなネームサーバの動作を確認する。
【００４６】
以上のようにして、ＤＮＳによるＩＰアドレスの照会が完了すると、ユーザ端末は、それぞれのアプリケーションに応じた通信を開始する。ＨＴＴＰによるＷＷＷサーバへのアクセスを例に取り、この再試行手順を以下に示す。
【００４７】
ユーザ端末Ｔに対応する障害検知サーバＳ１と、ＷＷＷサーバＷの所属する管理ドメインの障害検知サーバＳ２とは独立に再試行を行う。このとき、サーバ側の障害検知サーバＳ２の検出は、ＩＰレベルの再試行時に順に障害検知サーバを辿っていく際に行い、その時点で再試行の依頼および必要な情報（端末に対応する障害検知サーバのアドレス等）を渡すものとする。
【００４８】
ＨＴＴＰの場合はＴＣＰに着目し、ＳＹＮパケットの受け付け／拒否の状況、ＴＣＰレベルのスループットの評価、セグメント再送とそれに伴うの輻輳回避手順の発生状況などを調査する。また、その際、通信に使用された経路の帯域（ＩＰレベルの再試行で調査した）などを参考情報に用いる。
【００４９】
【発明の効果】
本発明によれば、以下のような効果が達成される。
【００５０】
(1) 障害の発生した通信を、下位（ＩＰ）レベルおよび上位（ＴＣＰ以上）レベルでそれぞれ再試行する。そして、下位レベルの再試行では、その通信で使用される通信経路上の各ルータに対して、ルータやリンクの障害／輻輳状況を確認し、上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認するので、輻輳、プログラムバグ、プロトコル手順などに起因するソフトウェア的な障害を検知できる。
【００５１】
(2) 障害の発生した通信を再試行してソフトウェア的な障害を検知する手順と、ルータやそのリンク等のハードウェア的な障害を検知する手順とを組み合わせ、これらの手順により得られた情報から総合的に判断して障害原因を推定するようにしたので、ソフトウェア的な障害およびハードウェア的な障害のいずれも検知できるようになる。
【図面の簡単な説明】
【図１】 本発明の障害推定方法を適用したネットワークの構成を模式的に示した図である。
【図２】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その１）である。
【図３】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その２）である。
【図４】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その３）である。
【図５】 障害検知サーバの機能ブロック図である。
【図６】 検知すべき障害の種別を示した図である。
【符号の説明】
Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５…ルータ、Ｓ１，Ｓ２…障害検知サーバ、Ｔ…ユーザ端末、Ｗ…ＷＷＷサーバ
【発明の属する技術分野】
本発明は、インターネットの障害推定方法に係り、特に、ハードウェア的な障害のみならず、ソウトウェア的な障害の原因や部位も推定できるインターネットの障害推定方法に関する。
【０００２】
【従来の技術】
インターネットの普及に伴い、トラヒックの集中によるネットワークやサーバの輻輳、システムダウンなどによる通信不能などの障害が問題となっている。このような障害発生時には、障害が発生した個所とその原因を早急に特定することが必要である。このため、従来からＳＮＭＰ（Simple Network Management Protocol）に基づくネットワーク管理方式や、回線あるいは端末内を監視するモニタリング方式による障害検知システムが提案されている。
【０００３】
ところで、インターネットにおける障害には、図６にも例示したように、回線切断やルータ・サーバの故障に代表されるハードウェア的な障害のみならず、輻輳、プログラムバグ、運用者の操作誤り、プロトコル手順などに起因するソフトウェア的な障害が考えられる。
【０００４】
【発明が解決しようとする課題】
上記したように、インターネットにおいて有効な障害検知およびその原因推定を実現するためには、従来のようなハードウェア的障害にとどまらず、ソフトウェア的な障害の検知も可能とする必要がある。しかしながら、上記した従来のＳＮＭＰに基づくネットワーク管理方式は、ハードウェア的障害の検知を基本としており、ソフトウェア的な障害を検知することは難しかった。
【０００５】
さらに、従来のモニタリング方式では、障害検知の対象となる個所の全てに監視装置を設置しなければならないので、今日のように広く普及したインターネット環境には適さないという問題があった。
【０００６】
本発明の目的は、上記した従来技術の課題を解決し、通信回線や経路情報交換の監視と、障害のあった通信の再試行を組み合わせて、プロトコル手順や操作誤りなどに起因するさまざまな障害を検出し、その原因を推定できるとともに、多数の設備を導入する必要のないインターネットの障害推定方法を提供することにある。
【０００７】
【課題を解決するための手段】
上記した目的を達成するために、本発明は、独立に管理・運営されるネットワークごとに障害検知サーバを設け、第１のネットワーク上のアクセス元端末と第２のネットワーク上のアクセス先端末との間に発生した通信障害の原因を推定するインターネットの障害推定方法において、前記第１のネットワーク上の障害検知サーバは、前記アクセス元端末とアクセス先端末との間の通信障害を前記アクセス元端末から申告され、その後、前記申告内容に基づいて、障害の発生した通信を再試行する再試行手順と、前記再試行で収集した障害情報に基づいて障害原因を推定する障害推定手順とを実行し、前記再試行手順では、前記障害の発生した通信の経路上に配置された各ネットワーク機器に対して、ＩＰレベルで各ネットワーク機器およびそのリンクの障害状況を確認する下位レベル再試行と、アクセス元端末として振るまってアクセス先端末とＴＣＰおよび上位レベルの通信を行い、その障害状況を確認する上位レベル再試行とを実行し、前記障害推定手順では、前記下位レベルおよび上位レベル再試行で収集した障害情報に基づいて障害原因を推定することを特徴とする。
【０００８】
上記した特徴によれば、再試行手順における下位レベルの再試行では、障害の発生している通信で使用される通信経路上の各ルータに対して、ルータやそのリンクの障害／輻輳状況を確認できる。また、上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認できる。したがって、輻輳、プログラムバグ、プロトコル手順などに起因するソフトウェア的な障害を検知できる。
【０００９】
【発明の実施の形態】
以下、図面を参照して本発明を詳細に説明する。図１は、本発明の障害推定方法を適用したネットワークの構成を模式的に示した図であり、図２、３、４は、各ネットワーク機器間で実行される通信プロトコルのシーケンスを示した図である。
【００１０】
本実施形態では、独立に管理・運営されるＬＡＮやＩＳＰ（Internet Service Provider ：インターネット接続事業者）等のネットワークごとに障害検知サーバを設け、第１のネットワーク上のアクセス元端末と第２のネットワーク上のアクセス先端末との間に発生した障害を検知する。
【００１１】
図１において、ＩＳＰ１では、アクセス元端末としてのユーザ端末Ｔが、ネットワーク機器としてのルータＲ１、Ｒ２を介してＩＳＰ２に接続されている。各ルータＲ１、Ｒ２およびそのリンクの状況は障害検知サーバＳ１により監視されている。ＩＳＰ２では、アクセス先端末としてのＷＷＷサーバＷが、ネットワーク機器としてのルータＲ３、Ｒ４，Ｒ５を選択的に介してＩＳＰ１と接続されている。各ルータＲ３、Ｒ４，Ｒ５およびそのリンクの状況は障害検知サーバＳ２により監視されている。
【００１２】
以下、本実施形態における障害推定方法を、ＩＳＰ１に属するユーザ端末ＴがＩＳＰ２に属するＷＷＷサーバＷにアクセスした際に生じる応答時間や転送スループットの悪化を例にして説明する。
【００１３】
ソフトウェア的な障害を検知するためには、通信における例外的なやり取りを検出し、その原因を解析する必要がある。すなわち、障害検知を実現するためには、ＴＣＰ／ＩＰプロトコルの振舞いを解釈する必要がある。そこで、本実施形態では、ＴＣＰ／ＩＰプロトコルの振舞いを解釈するために、障害の発生した通信を再試行する手順［手順３］を新たに採用し、さらには、ハードウェア的な障害を検知する既存の手順［手順１、２］をこれに組み合わせ、各手順［手順１〜３］により得られた障害情報から総合的に判断して、障害の発生した部位およびその原因を推定［手順４］するようにしている。
【００１４】
図５は、上記した各手順を実行する本発明の障害検知サーバＳ１の主要部の構成を示したブロック図であり、ユーザ端末Ｔからの障害申告を受け付ける障害申告受付部１００と、前記手順１を実行するＳＮＭＰ実行部１０１と、前記手順２を実行する経路変更履歴収集部１０２と、前記手順３を実行する再試行部１０３と、前記手順４を実行する障害原因推定部１０４とを含む。
【００１５】
さらに、前記再試行部１０３には、障害の発生した通信経路上の各ルータに対して、当該各ルータおよびそのリンクの障害状況を順次確信する下位レベル再試行部１０３ａと、アクセス先端末間との間でＴＣＰおよび上位レベルで通信を行い、その障害状況を確認する上位レベル再試行部１０３ｂとを設けた。以下、各手順について説明する。
【００１６】
手順１：ＳＮＭＰによるハードウェア障害検知
各障害検知サーバＳ１、Ｓ２は、それぞれ自身の管理下にあるネットワークＩＳＰ１，ＩＳＰ２内のルータやサーバなどのネットワーク機器とＳＮＭＰにより通信を行う。そして、定期的に各ネットワーク機器の状況を調査し、回線切断やルータの故障などのハードウェア障害が生じているかどうかを調べる。図１の例では、ＩＳＰ２の障害検知サーバＳ２が、ＳＮＭＰによりルータＲ３、Ｒ５から得た情報に基づいて、ルータＲ３、Ｒ５間のリンクに障害が発生したことを検知できる［図２(a) ］。
【００１７】
手順２：経路情報の変更履歴に基づく障害検知
各障害検知サーバＳ１、Ｓ２は、通常のルータとして機能することで他のルータとルーチングプロトコルに従った通信を行い、経路情報の変更に関する履歴情報を得る。各障害検知サーバＳ１、Ｓ２は、経路変更履歴を受信するたびに、ネットワーク全体の経路状況を再計算し、経路情報の頻繁な変更、特定の地域への経路情報の欠如などを検査する。
【００１８】
図１の例では、障害検知サーバＳ２がルーチングプロトコルを実行することにより、ルータＲ５においてルータＲ３宛てのパケット転送がルータＲ４経由の経路に変更され、ルータＲ３においてルータＲ５宛てのパケット転送がルータＲ４経由に変更されたことを把握する［図２(b) ］。
【００１９】
手順３：通信再試行による障害検知
ユーザ端末Ｔから障害内容の申告を受けた障害検知サーバＳ１が、そのユーザが行おうとした通信を、下位（ＩＰ）レベルおよび上位（ＴＣＰ以上）レベルで再試行する。
【００２０】
下位レベルの再試行では、その通信で使用される通信経路上の各ルータに対して、ルータやリンクの障害／輻輳状況を確認する。上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認する。以下、各レベルでの再試行について説明する。
【００２１】
手順３−１：下位レベルの再試行
ユーザ端末Ｔが属するネットワークＩＳＰ１の障害検知サーバＳ１は、ユーザ端末Ｔが最初に通信するルータＲ１の輻輳状況や故障状況を調査するとともに、通信相手にパケットを転送するためのネクストホップルータ（本実施形態では、ルータＲ２）を検索する。この処理を繰り返し、ネクストホップルータが他のネットワークに属するルータとなった場合、障害検知サーバＳ１は、次のネットワークの障害検知サーバに、ユーザ端末Ｔのアドレス、サーバのアドレス、ユーザ端末Ｔに対応する障害検知サーバなどの情報とともに、ＩＰレベルの再試行を依頼する。
【００２２】
再試行を依頼された障害検知サーバ（本実施形態では、障害検知サーバＳ２）は同様な処理を繰り返す。さらに、このような再試行については、ＷＷＷサーバＷからユーザ端末Ｔへの方向についても行う。以下、下位レベルの再試行方法を、図３のシーケンス図を参照して説明する。
【００２３】
初めに、ユーザ端末Ｔのユーザが、ＷＷＷサーバＷからの応答速度やデータ転送スループットが低下したことを認識すると、ＩＳＰ１の障害検知サーバＳ１に対して、障害が発生している旨およびその内容を申告する［図３(c) ］。前記申告内容は、例えば通信で使用したアプリケーションの種別、通信相手のＵＲＬやメールアドレスなどである。
【００２４】
障害検知サーバＳ１は、前記申告を検知すると、ユーザ端末Ｔが接続されているルータＲ１に対し、回線障害等の有無を問い合わせるとともに、ＷＷＷサーバＷのアドレスに基づいてネクストホップであるルータＲ２を検索する。ルータＲ１において特に問題がなければ、ネクストホップのルータＲ２に対して同様な処理を行う［同図(d) ］。
【００２５】
ルータＲ２のネクストホップであるルータＲ３はＩＳＰ２に属するため、障害検知サーバＴは、ＩＳＰ２の障害検知サーバＳ２に対して、通信相手ＷＷＷサーバＷのアドレスなどの必要な情報とともに、下位レベルの再試行による障害検知作業を依頼する［同図(e) ］。
【００２６】
障害検知サーバＳ２は、はじめにルータＲ３に対して問い合わせを行う。本実施形態では、この問い合わせ結果から、ルータＲ３、Ｒ５間のリンクで障害が発生し、ルータＲ３からルータＲ５へのパケット転送経路が、ルータＲ４経由の経路に変更されていることを確認する［同図(f) ］。
【００２７】
障害検知サーバＳ２は、同様にルータＲ４、Ｒ５にも問い合わせる。本実施形態では、この問い合わせ結果から、ルータＲ５内での出力バッファ溢れなどが原因で、ルータＲ５からルータＲ４へのリンクが輻輳していることを検知する［同図(g) ］。
【００２８】
以下、上記したＩＰレベルの再試行の実現形態の詳細について説明する。ＩＰレベルの再試行においては、障害検知サーバＳ１は、申告のあった通信において経由したルータの状態を調査する。この状態の検査およびネクストホップルータの検索は、標準で定められているＭＩＢ（Management Information Base ）の内、以下の情報(1) 、(2) を利用する。
【００２９】
(1) ＩＰルーチングテーブル（IP Route Table）の、あて先アドレス（IP Route Dest)、インタフェース識別子（IP Route If Index ）、ネクストホップのアドレス（IP Route Next Hop ）。
【００３０】
(2) インタフェーステーブル (if Table) の、インタフェース速度（ifSpeed ）) 、入出力バイト・パケット数（InOctets, OutOctets, InUcastPkts, OutUcastPkts）、入出力廃棄パケット数（InDiscards, OutDiscards ）、出力キュー長（OutQLen ）。
【００３１】
これらのうち、入出力バイト・パケット数、入出力廃棄パケット数、出力キュー長などについては、定期的に読み出しを行って時間的変化を記録し、再試行時におけるネットワークの状況が正確に判定可能となるようにする。また、隣接するネットワークの障害検知サーバＳ２との間では、事前に検知サーバ間の契約を締結しておくこととする。このため、ＩＰレベルの再試行において管理ドメインをまたがる場合は、次のドメイン（Autonomous System ）がどれかによって、再試行を依頼する障害検知サーバが決定可能であるとする。
【００３２】
手順３−２：上位レベルの再試行
上位レベルの再試行では、初めに、ユーザ端末Ｔに対応する障害検知サーバＳ１が、ユーザ端末Ｔの代わりにアクセス先端末のＷＷＷサーバＷと通信し、その中で、通信に使用される各種のプロトコルの手順を解釈し、データの再送や異常処理の起動の状況などのプロトコルの振舞いを検査し、障害を検知する。また、サーバ輻輳を確認するために、通信相手のＷＷＷサーバＷに最も近い障害検知サーバＳ２からも再試行を行う。
【００３３】
さらに、上位レベルのプロトコルに関して、ユーザ端末ＴとＷＷＷサーバＷとが通信した場合のみに発生する固有障害を検出するために、ユーザ端末Ｔにも障害検知サーバＳ１と通信させ、その中で障害検知サーバＳ１がＷＷＷサーバＷになり代わって、ユーザ端末Ｔにおける各種プロトコルの振舞いを検査する。ここでは遅延の挿入や、急激なパケット損失・遅延の発生などを行う。以下、上位レベルの再試行を、図４のシーケンス図を参照して説明する。
【００３４】
ＩＳＰ１の障害検知サーバＳ１は、ユーザ端末Ｔに成り代わってＷＷＷサーバＷとの通信を再試行し、ＷＷＷサーバ側のプロトコルの振舞い検査や関連するパラメータ設定値の推定などを行うとともに、応答時間／スループットの測定を行う［同図(h) ］。この結果、本実施形態では、障害検知サーバＳ１からＷＷＷサーバＷにアクセスした場合も応答速度が悪いという結果が得られる。
【００３５】
一方、障害検知サーバＳ１は、ＷＷＷサーバＷに成り代わってユーザ端末Ｔとの間でも上位レベルの再試行を行い、ユーザ端末Ｔ側のプロトコルの振舞い検査や関連するパラメータ設定値の推定を行い、ユーザ端末Ｔの問題や、パラメータ設定に関するＷＷＷサーバＷとの相性の問題などを検査する［同図(i) ］。本実施形態では、ユーザ端末Ｔには問題がないとの結果が得られたものとする。
【００３６】
さらに、障害検知サーバＳ１は、ＷＷＷサーバＷに隣接している障害検知サーバＳ２に対しても、必要な情報とともに上位レベルでの再試行を依頼する［同図(j) ］。障害検知サーバＳ２はユーザ端末に成り代わって通信を行うが、本実施形態では、応答速度に問題がないとの結果が得られたものとする。
【００３７】
手順４：障害検知サーバにおける結果の総合判断
以上の各手順により得られた障害情報に基づいて、障害検知サーバＳ１は以下の点を把握する。
【００３８】
▲１▼ＳＮＭＰ［手順１］／ルーチングプロトコル［手順２］の実行によって、ルータＲ３−Ｒ５間のリンクに障害が発生し、ルータＲ３−Ｒ５間のＩＰパケット転送がルータＲ４経由に変更された。
【００３９】
▲２▼ＩＰレベルでの再試行［手順３−１］により、ユーザ端末ＴからＷＷＷサーバＷへの通信経路にルータＲ４、Ｒ５が含まれ、ルータＲ５からルータＲ４へのリンクに輻輳が生じている。
【００４０】
▲３▼上位レベルでの再試行［手順３−２］により、ユーザ端末ＴやＷＷＷサーバＷのプロトコル動作に問題はなく、ＩＳＰ２の障害検知サーバＳ２からＷＷＷサーバＷへのアクセスでも応答速度に問題がないが、ＩＳＰ１の障害検知サーバＳ１からＷＷＷサーバＷへのアクセスでは応答速度に問題がある。
【００４１】
障害検知サーバＳ１は、以上の情報を総合的に判断し、「ユーザ端末ＴとＷＷＷサーバＷ間の通常の経路であるルータＲ３−Ｒ５間のリンクで障害が発生し、ルータＲ４経由の迂回経路が設定されたが、ルータＲ５からルータＲ４へのリンクで輻輳が発生したために応答速度が低下した」という結果をユーザに回答する［同図(k) ］。
【００４２】
上記したように、本実施形態によれば、ユーザから通信障害の申告を受けた障害検知サーバが、この障害が生じている通信を下位レベルおよび上位レベルで再試行し、再試行時に各ルータおよび他の障害検知サーバから得られる情報に基づいて、各ルータおよびそのリンクの状況を認識できる。
【００４３】
なお、通常の通信プロトコルでは、上記したＷＷＷサーバＷへのアクセスに先立ち、ユーザ端末Ｔは、ＷＷＷサーバＷのドメイン名からＩＰアドレスを得るために、ＤＮＳに従ってネームサーバへアクセスする。このネームサーバとの通信に障害が発生した場合には、前記再試行手順３を以下のように適用することができる。
【００４４】
ユーザ端末Ｔは通常、ＩＰアドレスを取得するためにローカルなネームサーバにアクセスする。また、各ドメイン名に対しては、権威あるネームサーバ（Authoritative Server）が割り当てられている。そこで、論理名の正当性を確認するために、まず、ユーザがアクセスしたドメイン名に対応する権威あるサーバのアドレスの取得を試みる。そのサーバが不明の場合は、この通信をＩＰレベルで再試行し、ネームサーバが正しく動作している場合は、与えられたドメイン名が不良であったと判断する。
【００４５】
次に、ローカルなネームサーバにキャッシュされているＩＰアドレスと、権威あるネームサーバで照会したＩＰアドレスとを比較して、ローカルなネームサーバの動作を確認する。
【００４６】
以上のようにして、ＤＮＳによるＩＰアドレスの照会が完了すると、ユーザ端末は、それぞれのアプリケーションに応じた通信を開始する。ＨＴＴＰによるＷＷＷサーバへのアクセスを例に取り、この再試行手順を以下に示す。
【００４７】
ユーザ端末Ｔに対応する障害検知サーバＳ１と、ＷＷＷサーバＷの所属する管理ドメインの障害検知サーバＳ２とは独立に再試行を行う。このとき、サーバ側の障害検知サーバＳ２の検出は、ＩＰレベルの再試行時に順に障害検知サーバを辿っていく際に行い、その時点で再試行の依頼および必要な情報（端末に対応する障害検知サーバのアドレス等）を渡すものとする。
【００４８】
ＨＴＴＰの場合はＴＣＰに着目し、ＳＹＮパケットの受け付け／拒否の状況、ＴＣＰレベルのスループットの評価、セグメント再送とそれに伴うの輻輳回避手順の発生状況などを調査する。また、その際、通信に使用された経路の帯域（ＩＰレベルの再試行で調査した）などを参考情報に用いる。
【００４９】
【発明の効果】
本発明によれば、以下のような効果が達成される。
【００５０】
(1) 障害の発生した通信を、下位（ＩＰ）レベルおよび上位（ＴＣＰ以上）レベルでそれぞれ再試行する。そして、下位レベルの再試行では、その通信で使用される通信経路上の各ルータに対して、ルータやリンクの障害／輻輳状況を確認し、上位レベルの再試行では、ユーザ端末または通信相手との間でＴＣＰおよび上位レベルでエンド・ツー・エンドの通信を再現し、通信性能の確認、通信相手のプロトコル手順およびネットワークパラメータ設定等の問題を確認するので、輻輳、プログラムバグ、プロトコル手順などに起因するソフトウェア的な障害を検知できる。
【００５１】
(2) 障害の発生した通信を再試行してソフトウェア的な障害を検知する手順と、ルータやそのリンク等のハードウェア的な障害を検知する手順とを組み合わせ、これらの手順により得られた情報から総合的に判断して障害原因を推定するようにしたので、ソフトウェア的な障害およびハードウェア的な障害のいずれも検知できるようになる。
【図面の簡単な説明】
【図１】 本発明の障害推定方法を適用したネットワークの構成を模式的に示した図である。
【図２】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その１）である。
【図３】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その２）である。
【図４】 各ルータおよびサーバ間で実行される通信のシーケンスを示した図（その３）である。
【図５】 障害検知サーバの機能ブロック図である。
【図６】 検知すべき障害の種別を示した図である。
【符号の説明】
Ｒ１，Ｒ２，Ｒ３，Ｒ４，Ｒ５…ルータ、Ｓ１，Ｓ２…障害検知サーバ、Ｔ…ユーザ端末、Ｗ…ＷＷＷサーバ
Claims (4)
- 独立に管理・運営されるネットワークごとに障害検知サーバを設け、第１のネットワーク上のアクセス元端末と第２のネットワーク上のアクセス先端末との間に発生した通信障害の原因を推定するインターネットの障害推定方法において、
前記第１のネットワーク上の障害検知サーバは、
前記アクセス元端末とアクセス先端末との間の通信障害を前記アクセス元端末から申告され、これを受け付ける手順と、
前記申告内容に基づいて、前記障害の発生した通信の経路上に配置された各ネットワーク機器に対して、ＩＰレベルで各ネットワーク機器およびそのリンクの障害状況を確認する下位レベル再試行手順と、
アクセス元端末として振るまってアクセス先端末とＴＣＰおよび上位レベルの通信を行い、その障害状況を確認する第１の上位レベル再試行手順と、
アクセス先端末として振るまってアクセス元端末とＴＣＰおよび上位レベルの通信を行い、その障害状況を確認する第２の上位レベル再試行手順と、
前記第２のネットワーク上の障害検知サーバをアクセス元端末として振るまわせてアクセス先端末とＴＣＰおよび上位レベルの通信を行わせ、その障害状況を確認させる第３の上位レベル再試行手順と、
前記下位レベルおよび各上位レベル再試行で収集した障害情報に基づいて障害原因を推定する障害推定手順とを含むことを特徴とするインターネットの障害推定方法。 - 前記各障害検知サーバは、ネットワーク内のネットワーク機器とＳＮＭＰを定期的に実行し、当該ネットワーク機器およびそのリンクの障害を検知するＳＮＭＰ手順をさらに実行し、前記障害推定手順では、前記再試行手順およびＳＮＭＰ手順で収集した障害情報に基づいて障害原因を推定することを特徴とする請求項１に記載のインターネットの障害推定方法。
- 前記障害検知サーバは、ネットワーク内の各ネットワーク機器とルーチングプロトコルを実行し、各ネットワーク機器での経路変更履歴を把握する経路変更履歴収集手順をさらに実行し、前記障害推定手順では、前記再試行手順および経路変更履歴収集手順で収集した障害情報に基づいて障害原因を推定することを特徴とする請求項１に記載のインターネットの障害推定方法。
- 前記障害検知サーバは、ネットワーク内のネットワーク機器とＳＮＭＰを定期的に実行し、当該ネットワーク機器およびそのリンクの障害を検知するＳＮＭＰ手順と、ネットワーク内の各ネットワーク機器とルーチングプロトコルを実行し、各ネットワーク機器での経路変更履歴を把握する経路変更履歴収集手順とをさらに実行し、前記障害推定手順では、前記再試行手順、ＳＮＭＰ手順および経路変更履歴収集手順で収集した各障害情報に基づいて障害を推定することを特徴とする請求項１に記載のインターネットの障害推定方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000276881A JP3722277B2 (ja) | 2000-09-12 | 2000-09-12 | インターネットの障害推定方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000276881A JP3722277B2 (ja) | 2000-09-12 | 2000-09-12 | インターネットの障害推定方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002094507A JP2002094507A (ja) | 2002-03-29 |
| JP3722277B2 true JP3722277B2 (ja) | 2005-11-30 |
Family
ID=18762285
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000276881A Expired - Fee Related JP3722277B2 (ja) | 2000-09-12 | 2000-09-12 | インターネットの障害推定方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3722277B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4616020B2 (ja) * | 2005-01-27 | 2011-01-19 | 富士通株式会社 | ネットワーク監視プログラム及びネットワークシステム |
| JP5061210B2 (ja) * | 2009-08-25 | 2012-10-31 | ヤフー株式会社 | 複数バックエンドサーバ監視用のアプリケーションサーバ及びその方法 |
| JP2011155364A (ja) * | 2010-01-26 | 2011-08-11 | Kddi Corp | 障害検知装置、監視制御装置およびコンピュータプログラム |
| JP6549959B2 (ja) * | 2015-10-02 | 2019-07-24 | 株式会社日立製作所 | 障害切り分け方法および障害切り分けを行う管理サーバ |
-
2000
- 2000-09-12 JP JP2000276881A patent/JP3722277B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002094507A (ja) | 2002-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Sherwood et al. | Touring the Internet in a TCP sidecar | |
| Sherwood et al. | Discarte: a disjunctive internet cartographer | |
| Dhamdhere et al. | NetDiagnoser: Troubleshooting network unreachabilities using end-to-end probes and routing data | |
| US8135828B2 (en) | Cooperative diagnosis of web transaction failures | |
| US7974219B2 (en) | Network troubleshooting using path topology | |
| CN101933290B (zh) | 基于流信息对网络设备上的acl进行配置的方法 | |
| JP4031959B2 (ja) | リアルタイム・マルチメディア・データフローの高速リルーティングを提供するシステム及び方法 | |
| JP5300076B2 (ja) | コンピュータシステム、及びコンピュータシステムの監視方法 | |
| WO2021128977A1 (zh) | 一种故障诊断方法及装置 | |
| US20060203739A1 (en) | Profiling wide-area networks using peer cooperation | |
| JP4065398B2 (ja) | インターネットルータトラフィックを測定する方法および装置 | |
| JP5494110B2 (ja) | ネットワークの通信経路推定方法、通信経路推定プログラム及び監視装置 | |
| JP3722277B2 (ja) | インターネットの障害推定方法 | |
| US7898955B1 (en) | System and method for real-time diagnosis of routing problems | |
| JP2000278264A (ja) | データネットワーク監視方法 | |
| US11765059B2 (en) | Leveraging operation, administration and maintenance protocols (OAM) to add ethernet level intelligence to software-defined wide area network (SD-WAN) functionality | |
| Cisco | Troubleshooting Internetworking Systems | |
| Cisco | Troubleshooting TCP/IP Connectivity | |
| Cisco | Troubleshooting TCP/IP Connectivity | |
| Cisco | Troubleshooting TCP/IP Connectivity | |
| Cisco | AppleTalk Routing Commands | |
| Cisco | AppleTalk Routing Commands | |
| Cisco | AppleTalk Routing Commands | |
| Cisco | Troubleshooting TCP/IP Connectivity | |
| Cisco | Troubleshooting TCP/IP Connectivity |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040119 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20050610 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050615 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050811 |
|
| 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: 20050907 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050907 |
|
| 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: 20080922 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313114 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313532 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080922 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080922 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090922 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |