JP4910488B2 - 網の経路状態を調査する管理装置及びその網システム - Google Patents

Description

本発明は、網の経路状態を調査する管理装置、及びその網システムに関する。詳しくは、網の経路状態が即時取得可能で経路変動も検出可能な管理装置等に関する。

従来から、網（又はネットワーク、以下「網」と称す）の経路状態を把握するコマンドとして、ｔｒａｃｅｒｏｕｔｅコマンドがある。

ｔｒａｃｅｒｏｕｔコマンドの起動により、ＴＴＬ（Time to Live：パケットの有効期限）を「１」から順に大きくしたパケットが宛て先アドレスに送出される。ＴＴＬの値に従い、当該コマンドを発行した端末から数えて１ホップ目、２ホップ目、・・・のネットワークノードは、有効期限エラーを示すパケットを返信する。宛て先アドレスの端末がこのパケットを返信するまで、ＴＴＬを順に大きくすることで、その間の経路が明らかになる。

また、他の従来技術として、コマンド発行端末から経路トレースを示すフラグを付したフォーマット信号が送信され、各ノードは受信ポートのアドレス及び送出ポートのアドレスを付加して次のノードに送信し、付加累積された受信ポート及び送出ポートのアドレスの繋がりから送信経路をトレースするようにしたものがある（例えば、以下の特許文献１）。

更に、送信されたフィルタ設定パケットから、経路に沿った動的パケットフィルタを設定し、このフィルタによって検出されたデータの収集により、ネットワーク内の実パケットを追跡することで、経路情報を取得するようにしたものも開示される（例えば、以下の特許文献２）。
特開２０００−２４４５６３号公報 特開２００５−３１２０３３号公報

しかしながら、ｔｒａｃｅｒｏｕｔｅコマンドは、網オペレータ又はユーザ（以下、「網オペレータ等」と称す）が自ら端末を操作して発行させる必要がある。元来、当該コマンドは、網オペレータ等が何らかの方法で網の障害を認識した後で発行されるコマンドである。従って、障害発生時点で当該コマンドを発行した場合でなければ、障害発生時点での経路状態を取得することは困難である。

また、ｔｒａｃｅｒｏｕｔｅコマンドの発行をスクリプト等により、ある程度自動化（例えば、一定時間）することも考えられる。しかし、同様に、障害が発生した時点でコマンドが発行されなければ障害発生時点での経路状態を取得することは困難である。

更に、ｔｒａｃｅｒｏｕｔｅコマンドはその場限りのコマンドであり、当該コマンドの起動により発行される各パケットにおいて、その前後の結果を比較して経路変動を把握することはできない。従って、当該コマンドでは、経路が変動した場合でも、網オペレータ等に通知することができない。

一方、特許文献１及び２に関しても、フォーマット信号やフィルタ設定パケットを網オペレータ等が端末の操作により自ら発行させる必要があり、障害発生時点での経路状態を取得することが困難である。

そこで、本発明は、上記問題点に鑑みてなされたもので、その目的は、ユーザトラフィックに応じて網の経路状態を即時取得できる管理装置、管理方法、プログラム、及びその網システムを提供することにある。

また、本発明の他の目的は、網の経路変動を検出できる管理装置等を提供することにある。

上記目的を達成するために、本発明の一実施態様によれば、網の経路状態を調査する管理装置において、前記網からのトラフィックを受信するパケット送受信部と、受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。

また、本発明の他の実施態様によれば、前記管理装置において、更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する。

更に、本発明の他の実施態様によれば、前記管理装置において、前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記パケット送受信部は、前記プローブ応答パケットを受信するともに、前記網に転送されずループバック機能により前記プローブパケットを受信し、前記結果保存部は、前記プローブ応答パケットと、前記ループバック機能により受信した前記プローブパケットとから前記経路情報を作成することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブパケット生成部は抽出された前記アドレス情報に対して予め設定されたホップ数分の前記プローブパケットを生成することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブパケット生成部は前記プローブパケットごとに異なる識別子を生成された前記プローブパケットに付加することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記識別子は前記プローブパケットの送信先であるターゲットごとにユニークなシーケンス番号と、送信される前記プローブパケットのホップ数を示す値とを含むことを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記結果保存部は前記シーケンス番号が同一の前記プローブ応答パケットを同一エントリ内にまとめて保存することを特徴とする。

更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブ応答パケットには前記プローブパケットの送信された前記ターゲットのアドレス情報が含まれ、前記結果保存部には前記アドレス情報が前記エントリ内に含まれることを特徴とする。

また、上記目的を達成するために本発明の他の実施態様によれば、網の経路状態を調査する管理方法において、前記網からのトラフィックを受信し、受信した前記トラフィックから、アドレス情報を抽出し、抽出された前記アドレス情報を送信先とするプローブパケットを生成し、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。

更に、上記目的を達成するために本発明の他の実施態様によれば、網の経路状態を調査する管理プログラムにおいて、前記網からのトラフィックを受信する処理と、受信した前記トラフィックから、アドレス情報を抽出する処理と、抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信する処理と、をコンピュータに実行させることを特徴とする。

更に、上記目的を達成するために本発明の他の実施態様によれば、端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、前記管理装置には、前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。

本発明によれは、ユーザトラフィックに応じて網の経路状態を即時取得できる管理装置、管理方法、プログラム、及びその網システムを提供することができる。また、本発明によれば、網の経路変動を検出できる管理装置等を提供することができる。

以下、図面を参照して本発明を実施するための最良の形態を説明する。

まず、実施例１について説明する。本実施例１は、網に転送されるトラフィック（又はパケットデータ）をキャプチャし、そのパケットと同じアドレスを持つプローブパケットを、トラフィックの転送と略同時に網に転送させて、その応答パケット等を保存する等により、経路状態を即時に取得することができるようにした例である。

図１は、実施例１において適用されるネットワークシステム（網システム）１００の構成例を示す図である。ネットワークシステム１００は、キャプチャ／プローブ端末（以下、「キャプチャ端末」と称す）１と、端末２００と、サーバ４００とから構成される。キャプチャ端末１等はＩＰ（Internet Protocol）ネットワーク３００を介して互いに接続される。

また、ＩＰネットワーク３００は、複数のノード３１０〜３７０を有し、図１に示す経路により互いに接続される。

図２は、キャプチャ端末１の構成例を示す図である。キャプチャ端末１は、パケット送受信部１０と、ユーザトラフィック抽出部２０と、プローブパケット生成部３０、及びプローブ受信部４０を備える。このキャプチャ端末１が、網の経路状態を調査する管理装置としての役割を果たす。

パケット送受信部１０は、パケット受信部１１と、振り分け部１２、及びパケット送信部１３を備える。

パケット受信部１１は、端末２００や各ノード３１０〜３７０、サーバ４００から送信されたパケットデータを受信する。

振り分け部１２は、パケット受信部１１で受信したパケットが、ユーザトラフィックのパケットか、後述するプローブ応答パケット（或いはプローブパケット）か、を判別する。そして、振り分け部１２は、ユーザトラフィックのパケットをユーザトラフィック抽出部２０に、プローブ応答パケット等はプローブ受信部４０に振り分ける（又は、廃棄する）。振り分けは、受信したパケットデータのプロトコルフィールドやポート番号を利用する。詳細は後述する。

パケット送信部１３は、プローブパケット生成部３０で生成されたプローブパケットを、ＩＰネットワーク３００を介して、端末２００や各ノード３１０〜３７０、サーバ４００に送信する。前述のプローブ応答パケットは、プローブパケットを受信した各ノード３１０〜３７０等がキャプチャ端末１に対して送信するパケットである。

ユーザトラフィック抽出部２０は、アドレス抽出部２１を備える。アドレス抽出部２１は、ユーザトラフィックのパケットから、送信元アドレス（Ｓｒｃアドレス）と、宛て先アドレス（Ｄｓｔアドレス）とを抽出する。アドレス抽出部２１は、抽出した送信元アドレス等をプローブパケット生成部３０に出力する。

プローブパケット生成部３０は、パケット生成部３１と、ターゲット定義テーブル３２と、シーケンス値カウンタ３３とを備える。

パケット生成部３１は、送信元アドレスと宛て先アドレスとから、プローブパケットを生成する。パケット生成部３１は、ターゲット定義テーブル３２を参照して、合致した送信元アドレス及び宛て先アドレスの組がある場合にプローブパケットを生成する。また、パケット生成部３１は、シーケンス値カウンタ３３を参照し、プローブパケットのシーケンス番号を演算し、プローブパケットの所定フィールドに格納する。詳細は後述する。パケット生成部３１は、生成したプローブパケットをパケット送信部１３に出力する。

ターゲット定義テーブル３２は、プローブパケットの送信を行うターゲットを定義するテーブルである。具体的には、ターゲット定義テーブル３２には、ターゲット（プローブパケットの送信先）のアドレスが記憶される。

シーケンス値カウンタ３３は、シーケンス番号のベースとなる値を保持するカウンタである。シーケンス番号は、どのターゲット宛てのプローブパケットか、ターゲットの重複を識別するために、或いは、ターゲットが同じになるようなプローブパケットを送信するときにターゲットの重複を区別するために、プローブパケットに付与される番号である。詳細は後述する。

プローブ受信部４０は、結果保存部４１と、結果保存データベース（ＤＢ）４２とを備える。

結果保存部４１は、振り分け部１２からのプローブパケットとプローブ応答パケットとを分類して結果保存ＤＢ４２に格納する。結果保存ＤＢ４２には、後述するように各パケットに基づくエントリが記憶され、調査した経路状態を把握することができる。

次に、キャプチャ端末１の動作について説明するが、その前に、まずユーザトラフィックのパケットである、ＩＰパケットの例について説明する。

図３（Ａ）は、パケット受信部１１で受信するＩＰパケット５００の構成例を示す図である。ＩＰパケット５００は、プロトコルを識別するためのデータが格納されるプロトコルフィールド５１０と、送信元と宛て先の夫々のＩＰアドレスが格納される送信元ＩＰアドレスフィールド５１１及び宛て先ＩＰアドレスフィールド５１２と、送信元と宛て先の夫々のポート番号が格納される送信元ポート番号フィールド５１３及び宛て先ポート番号フィールド５１４と、種々のデータが格納されるペイロード５１５とから構成される。

パケット送受信部１０の振り分け部１２では、パケットを振り分けることになるが、例としてＨＴＴＰパケットをユーザトラフィックのパケットとした場合は以下のようになる。即ち、振り分け部１２は、送信元ポート番号と宛て先ポート番号とを、受信したＩＰパケット５００の該当フィールド５１３、５１４から取り出す。そして、そのいずれかの番号が「８０」又は「８０８０」のとき、振り分け部１２は受信したパケットがＨＴＴＰパケットであるとしてユーザトラフィック抽出部２０に出力する。

なお、振り分け部１２は、ユーザトラフィックのパケットを振り分けた後、引き続いてプローブパケット、プローブ応答パケットの振り分け処理を行う。即ち、受信したＩＰパケット５００のプロトコルフィールド５１０を取り出し、それがプローブパケット又はプローブ応答パケット（ＩＣＭＰパケット）であることを示すものであったとき、振り分け部１２は受信したパケットがプローブパケット又はプローブ応答パケットであるとしてプローブ受信部４０に出力する。

図４は、ユーザトラフィック抽出部２０で実行されるアドレス抽出処理のフローチャートの例である。

まず、ユーザトラフィック抽出部２０は、アドレス抽出機能を実行するための処理を開始すると（Ｓ１０）、振り分け部１２から出力されたＨＴＴＰパケットから、送信元アドレス（Ｓｒｃアドレス）と宛て先アドレス（Ｄｓｔアドレス）とを抽出する（Ｓ１１）。そして、抽出した各アドレスをプローブパケット生成部３０のパケット生成部３１に出力する（Ｓ１２）。そして、アドレス抽出機能の処理が終了する。

その後、プローブパケット生成部３０において、抽出したアドレスに基づいて、プローブパケットの生成機能が実行される。図５は、そのフローチャートの例である。

尚、本実施例では、この機能が実行される前に、以下の処理が行われる。まず、オペレータ等は、ターゲット定義テーブル３２にターゲットを記憶しておく。図３（Ｂ）は、ターゲット定義テーブル３２の例である。同図に示すように、プローブパケットのターゲットとなるべき、サーバ４００等のアドレスが記憶される。

また、オペレータ等はプローブパケットを送信するホップ数も予め設定しておく。例えば、キャプチャ端末１のメモリ等に記憶する。調査したいホップ数を設定するもので、網の規模等によって数も変動する。

更に、オペレータ等は、シーケンス値カウンタ３３を任意の値で初期化する。

本実施例では、ターゲット定義テーブル３２を「＊」（すべてのターゲット、即ち、ノード３１０を通る全てのＨＴＴＰパケットを対象にする）、ホップ数を「５」、シーケンス値カウンタ３３の初期値を「１」とする。

図５に戻り、プローブパケット生成機能を実行するための処理が開始されると（Ｓ２０）、パケット生成部３１は、ＴＴＬカウンタ値を「０」にして初期化する（Ｓ２１）。

ＴＴＬカウンタ値とは、送信するプローブパケットのホップ数をカウントするための値である。予め設定されたホップ数分のプローブパケットの生成が終了すると、プローブ生成処理が終了する。

次いで、パケット生成部３１は、ターゲット定義テーブル３２に記憶されたエントリを参照して、ユーザトラフィック抽出部２０で抽出されたアドレスがターゲット定義テーブル３２に存在するか否かを判断する（Ｓ２２）。ターゲット定義テーブル３２に存在しないと（Ｓ２２で「ない」）、プローブパケット生成機能は終了する。

一方、ターゲット定義テーブル３２に抽出したアドレスが存在すれば（Ｓ２２で「あり」）、パケット生成部３１は、ＴＴＬカウンタ値を「＋１」加算する（Ｓ２３）。上記設定では、ターゲット定義テーブル３２は「＊」のため、抽出したアドレスが存在し、ＴＴＬカウンタ値が「１」となる。

次いで、パケット生成部３１は、実際にプローブパケットの生成処理（Ｓ２４、Ｓ２５）を行う。２つの処理により、それぞれ異なるプローブパケットが生成される。

図６（Ａ）及び（Ｂ）は、プローブパケットの例を示す図である。プローブパケット５３０は、送信元と宛て先のＩＰアドレスが夫々格納される送信元（Ｓｒｃ）ＩＰアドレス５３２及び宛て先（Ｄｓｔ）ＩＰアドレスフィールド５３３と、シーケンス番号が格納されるシーケンス番号フィールド５３５と、ＴＴＬカウンタ値が格納されるＴＴＬフィールド５３６とを有する。

同図に示す例では、Ｓ２４の処理により図６（Ａ）に示すプローブパケットが生成され、Ｓ２５の処理により図６（Ｂ）に示すプローブパケットが生成される。

まず、Ｓ２４の処理において、パケット生成部３１は、ユーザトラフィック抽出部２０により取得したＨＴＴＰパケットの宛て先アドレスを、プローブパケットの宛て先ＩＰアドレスフィールド５３３に格納する。また、送信元ＩＰアドレスフィールド５３２にキャプチャ端末１自身のＩＰアドレスを格納する。

そして、シーケンス番号フィールド５３５に、「シーケンスカウンタ値×バイアス値（Ｄ）＋ＴＴＬカウンタ値」を格納する。上記設定では、シーケンスカウンタ値は「１」、ＴＴＬカウンタ値はＳ２３により「１」となる。また、バイアス値（Ｄ）は本実施例では「１００」とすると、シーケンス番号は、１×１００＋１＝１０１となる。

また、Ｓ２５の処理において、パケット生成部３１は、取得したパケットの送信元アドレスを、さらに別のプローブパケット５３０の宛て先ＩＰアドレスフィールド５３３に格納する。送信元ＩＰアドレスフィールド５３２は、キャプチャ端末１自身のＩＰアドレスが格納される。

そして、シーケンス番号フィールド５３５に、「シーケンス値カウンタ×バイアス値（Ｓ１）＋バイアス値（Ｓ２）＋ＴＴＬカウンタ値」を格納する。バイアス値（Ｓ１）を「１００」、バイアス値（Ｓ２）を「５０」とすると、シーケンス番号は、１×１００＋５０＋１＝１５１となる。

次いで、パケット生成部３１は、生成したプローブパケットをパケット送信部１３に転送する（Ｓ２６）。生成された２つのプローブパケットが網に送信されることになるが、一方のプローブパケットは、宛て先が「取得した宛て先アドレス」のため、ＨＴＴＰパケットの送信先（例えば、サーバ４００）に送信される。

他方のプローブパケットは、宛て先が「取得した送信元アドレス」のため、ＨＴＴＰパケットの送信元（例えば、端末２００）に送信される。

そして、設定したホップ数分（ｍ回）繰り返したか否か判断する（Ｓ２７）。上述の例では、ホップ数は「５」のため、上述の処理を５回繰り返すことになる。

２回目の処理のときは、Ｓ２３により、ＴＴＬカウンタ値が「２」となり、Ｓ２４の処理により、シーケンス番号が１×１００＋２＝１０２であるプローブパケットが生成される。また、３回目の処理のときは、シーケンス番号が１×１００＋３＝１０３であるプローブパケットが生成される。このように、ユーザトラフィックのパケットの送信先（例えば、サーバ４００）に送信されるプローブパケットのシーケンス番号は、パケットごとに夫々異なる番号を有することになる。

一方、Ｓ２５の処理により生成されるプローブパケットは、２回目の処理で、１×１００＋５０＋２＝１５２のシーケンス番号、３回目の処理で１×１００＋５０＋３＝１５３のシーケンス番号を、夫々有することになる。このように、ユーザトラフィックのパケットの送信元（例えば、端末２００）に送信されるプローブパケットもパケットごとに夫々異なる番号を有する。更に、サーバ４００に送信されるプローブパケットと端末２００に送信されるプローブパケットとも夫々異なる番号を有し、ユニークな番号となる。

上述の例では、ホップ数は「５」（＝ｍ）のため、夫々「５」個の計「１０」個のプローブパケットが生成される（夫々異なるシーケンス番号を有する）。

図５に戻り、ｍ回繰り返したとき（Ｓ２７でＹＥＳ）、パケット生成部３１は、シーケンス値カウンタ３３を「＋１」加算する。この加算により、更に、キャプチャ端末１から送信されるプローブパケットのユニーク性が保証される。

即ち、シーケンス値カウンタ３３が「＋１」加算され、更に別途ＨＴＴＰパケットを受信すると、Ｓ２４の処理により生成されるプローブパケットのシーケンス番号は「２×１００＋１＝２０１」、２回目の処理では、「２×１００＋２＝２０２」となる。最初の処理で生成されたプローブパケットの各シーケンス番号と比較しても、ユニークなものとなる。

そして、パケット送信部１３から、生成されたプローブパケットが送信される。図７（Ａ）は、プローブパケットの構成例を示す図である。図６（Ａ）等と同一部分には同一の符号を付している。

このプローブパケット５３０を受けた各ノード３１０〜３７０等は、プローブ応答パケットを生成してキャプチャ端末１に順次送信する。

図７（Ｂ）は、プローブ応答パケット５５０の構成例を示す図である。全体の構成は、プローブパケット５３０と同様である。送信元ＩＰアドレスフィールド５５２には、各ノード３１０〜３７０等のＩＰアドレスが格納される。また、宛て先ＩＰアドレスフィールド５５３には、キャプチャ端末１のＩＰアドレスが格納される。

プローブパケットを送信後、しばらくすると、パケット受信部１１は、プローブ応答パケットとプローブパケットを相次いで受信（又は、キャプチャ）する。

ここでプローブパケットは、パケット送信部１３からノード３１０〜３７０等を介さずに直接パケット受信部１１で受信される。これは、パケット送信部１３やパケット受信部１１がループバック機能を用いているからである。このようなループバック機能は、パケット受信部１１等を構成するインターフェースが標準的に装備している。

振り分け部１２は、ループバック機能によるプローブパケット及びプローブ応答パケットと、ユーザトラフィックのパケットとを振り分ける。上述のように、パケットのプロトコルフィールドに格納された値により振り分ける。

プローブ受信部４０は、振り分けられたプローブパケットとプローブ応答パケットとに対して結果保存機能の処理を実行する。図８は、結果保存部４１におけるフローチャートの例である。

結果保存部４１は、結果保存機能を実行するための処理を開始すると（Ｓ４０）、パケット（プローブパケット又はプローブ応答パケット）からシーケンス番号を抽出し、シーケンス番号からシーケンスカウンタ値を逆算する（Ｓ４１）。

前述の例では、シーケンス番号の「１００」の位を確認すれば判明できる。例えば、シーケンス番号が「１０１」のとき、シーケンス値カウンタは「１」、シーケンス番号が「２０３」のとき、シーケンス値カウンタは「２」であると判明できる。

次いで、結果保存部４１は、シーケンス値カウンタと宛て先（Ｄｓｔ）アドレスとをキーにして、結果保存ＤＢ４２に既存エントリが存在するか否かを判断する（Ｓ４２）。

これにより、受信したパケットが既に受信している途中の経路調査用のプローブパケット群の一部であるか、又は、新たに調査を始めた経路調査用のプローブパケットであるかを判別することができる。

図９は、結果保存ＤＢ４２の構成例である。１エントリは、プローブパケットに基づくサブエントリ４２１〜４２５と、サブエントリ４２１〜４２５の要素４３１〜４３５とから構成される。各エントリ４２１〜４２５等は、ＴＴＬ順に並べられる。本フローチャートによりこの結果保存ＤＢ４２が構築される。

既に受信している途中の経路調査用のプローブパケットとは、結果保存ＤＢ４２に、サブエントリ４２１〜４２５のいずれかが存在している場合のパケットである。また、新たに調査を始めた経路調査用のプローブパケットとは、結果保存ＤＢ４２に該当するサブエントリ４２１〜４２５等が存在しない場合のパケットである。

図８に戻り、受信したパケットが新たに調査を始めた経路調査用のプローブパケットのとき（結果保存ＤＢ４２に既存エントリが存在しないとき、Ｓ４２で「エントリ存在しない」）、シーケンス値カウンタと、プローブパケットの宛て先アドレスをキーにして、結果保存ＤＢ４２に新たにエントリを追加する（Ｓ４６）。そして、結果保存機能の処理が終了する（Ｓ４７）。

一方、受信したプローブパケットが現在受信途中の経路調査用のプローブパケットのとき（結果保存ＤＢ４２に既存エントリが存在するとき、Ｓ４２で「エントリ存在する」）、結果保存部４１は、受信したパケットがプローブパケットかプローブ応答パケットかを判別する（Ｓ４３）。

この判別は、図７（Ａ）又は同図（Ｂ）に示すように、リクエスト又はレスポンスを示す値が格納されるフィールド５５４から判別できる。例えば、プローブパケットの場合、このフィールド５５４にリクエストを示す「０」、プローブ応答パケットの場合、このフィールド５５４にレスポンスを示す「１」が格納されているので、この値から判別する。

プローブパケットのとき（Ｓ４３で「プローブパケット」）、結果保存部４１はシーケンス値カウンタと受信パケットの宛て先（Ｄｓｔ）アドレスをキーとして、結果保存ＤＢ４２の該当するエントリに、ＴＴＬ順にサブエントリを追加する（Ｓ４８）。

図９の例では、サブエントリ４２１〜４２４に対して、更にサブエントリ４２５を追加する処理等が本処理（Ｓ４８）に該当する。

一方、プローブ応答パケットのとき（Ｓ４３で「応答パケット」）、結果保存部４１は、結果保存ＤＢ４２に該当するサブエントリが存在しているため、ＴＴＬを参照して、該当するサブエントリに要素として自パケットの送信元（Ｓｒｃ）アドレスを格納する（Ｓ４４）。

図９の例では、サブエントリ４２１に要素４３１として、プローブ応答パケットの送信元（Ｓｒｃ）アドレスを格納する処理が本処理（Ｓ４４）に該当する。そして、結果保存機能の一連の処理が終了する。

結果保存部４１は、プローブパケットやプローブ応答パケットを受信するごとに、上述の処理を行い、結果保存ＤＢ４２を構築する。そして、最終的に構築された結果保存ＤＢ４２では、プローブ応答パケットの送信元（Ｓｒｃ）アドレスが順番に並べられている。この送信元アドレスは、プローブパケットを送信したノード３１０〜３７０等のアドレスを示す。従って、結果保存ＤＢ４２の順番に並べられた送信元アドレスが経路を示すことになり、その経路が結果保存ＤＢ４２に蓄積される。

図１０は、本実施例１における効果を説明するための図である。端末２００から、ユーザトラフィックのパケットを、ノード３１０、３３０、３４０を経由して、サーバ４００に送信するとき、キャプチャ端末１は、ノード３１０を通過するパケットを受信（キャプチャ）する。

そして、キャプチャ端末１は、キャプチャしたパケットから、そのパケットの送信先（又は送信元）を宛て先とするプローブパケットを生成して網に送信する。即ち、端末２００からのユーザトラフィックのパケットと、プローブパケットとが略同時にノード３１０を経由して、順次同じ経路に伝送される。その後キャプチャ端末１は、プローブ応答パケットを受信することで、結果保存ＤＢ４２に経路が蓄積される。

従って、本実施例１では、経路状態をユーザトラフィックに応じて即時的に取得することが可能となる。また、キャプチャ端末１を操作する網オペレータがプローブパケットを生成するためのトリガとなる操作を別途行う必要がない。よって、経路状態を即時的に取得できるため、障害発生時点での経路状態も即時取得できる。

上述した例では、キャプチャ端末１を備えるネットワークシステム１００の例で説明したが、例えば、ユーザが使用する端末２１０に、上述したキャプチャ端末１の機能を備えるようにしてもよい。図１１は、そのような場合のネットワークシステム１００の構成例を示す図である。

この場合、端末２１０は、網を流れる多数のユーザのトラフィックをキャプチャするのではなく、ユーザ自身が（端末２１０自身が）送受信するトラフィックを対象としてキャプチャする。

また、プローブパケットは、ユーザトラフィックの宛て先アドレスにのみ送信される。ユーザトラフィックの送信元アドレスは端末２１０のアドレスのため、例えば図６（Ｂ）のようなプローブパケットは生成されず、送信されない。

更に、結果保存ＤＢ４２に蓄積される経路情報は、ユーザがアクセスした先（ユーザトラフィックの宛て先アドレスを持つサーバ４００など）に関するものとなる。

この場合でも、上述した例と同様に経路状態を即時取得可能で、障害発生時点での経路状態も取得可能である。

次に実施例２について説明する。本実施例２は、以前に保存した経路情報と、新たに抽出した経路情報とを比較し、変動があればその旨を網オペレータやユーザに通知するようにした例である。

図１２は、本実施例２において適用されるキャプチャ端末１の構成例である。実施例１のキャプチャ端末１と同一の構成部分には同一の符号を付している。異なるのは、プローブ受信部４０において、結果比較部４３と差分データベース（ＤＢ）４４とを更に備える点である。

結果保存部４１により結果保存ＤＢ４２が構築されるまでは実施例１と同様である。結果保存機能の処理（図８）が終了した後、結果比較機能を実行するための処理が開示され、経路の変動が網オペレータやユーザに通知される。図１３は、結果比較機能を実行するためのフローチャートの例である。

結果比較部４３は、結果比較機能を実行するための処理を開始すると（Ｓ５０）、以前の結果比較処理でメモリに展開された結果（後述）を差分ＤＢ４４に記録する（Ｓ５１）。そして、結果保存機能の処理（図８）と同様に、結果保存部４１は受信したパケット（プローブパケット又はプローブ応答パケット）に対してメモリに結果保存ＤＢ４２と同様のエントリの作成等を行う。メモリに記憶されたエントリは、その後、差分ＤＢ４４と比較することで経路の比較に用いられる。

次いで、結果比較部４３は、パケットが最終応答パケットか否かを判断する（Ｓ５２）。即ち、受信したパケット（プローブパケット又はプローブ応答パケット）が最終ホップ目の宛て先（Ｄｓｔ）アドレスに対する応答パケットか否かを判断する。

これは、受信パケットの送信元アドレスが、差分ＤＢ４４のエントリにあるプローブパケットの宛て先（Ｄｓｔ）アドレスと同一か否かにより判断する。或いは、プローブパケットを受信した各ノード３１０〜３７０等は、プローブパケットをプローブ応答パケットのペイロード５５７に格納しているため（図７（Ａ）及び同図（Ｂ）参照）、ペイロード５５７に格納されたプローブパケットの宛て先アドレスを参照して、差分ＤＢ４４のエントリと比較するようにしてもよい。又は、受信パケットのＴＴＬフィールド５３６、５５６に格納された値が、例えば「５」（ホップ数として最初に設定した値）であれば、最終応答パケットと判断してもよい。

受信したパケットが最終応答パケットではないとき（Ｓ５２で「最終応答パケットではない」）、結果比較処理は終了する（Ｓ５６）。これは、最終パケットを受信するまでは、同一エントリ内のサブエントリや要素が全て構築されておらず、その後の処理で経路の比較を行うことができないからである。

一方、受信パケットが最終応答パケットのとき（Ｓ５２で、「最終応答パケット」）、経路の比較作業を実際に行うことになる。まず、結果比較部４３は差分ＤＢ４４を参照し、メモリに記憶されたエントリのうち宛て先（Ｄｓｔ）アドレスと同一のエントリが差分ＤＢ４４に存在するか否かを判断する（Ｓ５３）。過去に同一経路について経路の比較調査を行ったか否かを判断するためである。

同じ宛て先（Ｄｓｔ）アドレスのエントリが差分ＤＢ４４に存在しないとき（Ｓ５３で「存在しない」）、処理は終了する（Ｓ５７）。その経路については始めて調査することになるため差分は抽出することはできないからである。

一方、同じ宛て先（Ｄｓｔ）アドレスのエントリが差分ＤＢ４４に存在するとき（Ｓ５３で「存在する」）、結果比較部４３は、差分ＤＢ４４の内容（エントリ内のシーケンス値カウンタやＳｒｃアドレス等）とメモリに記憶された内容を全て比較して、差分ＤＢ４４の内容が一致するか否か判断する（Ｓ５４）。

一つでも内容が異なれば（Ｓ５４で「一致しない」）、結果比較部４３は経路に差異が存在することになるため、変動があった旨を網オペレータ又はユーザに通知する（Ｓ５８）。

通知は、例えば、結果比較部４３が変動があった旨をモニタ等の表示部に表示させるようにしてもよいし、メモリ等に発生時間とともに記憶してログを取るようにしてもよい。

一方、差異がないとき（Ｓ５４で「一致する」）、又は差異があって変動があった旨を通知した後、結果比較部４３は差分ＤＢ４４の既存エントリを削除して終了する（Ｓ５５）。この処理と、上述のメモリに展開された結果の差分ＤＢ４４への記録（Ｓ５１）により、常に、新しい結果が差分ＤＢ４４に保存されることになる。

このように、本実施例２では、ある時点で突然経路の変動が生じた場合、差分ＤＢ４４の内容とメモリに記憶された内容とが一致しなくなり、その旨が網オペレータやユーザに通知されるため、経路の変動を網オペレータ等が把握することができる。

尚、結果比較機能の処理が実行される前までは、実施例１と同様の処理が実行されるため、本実施例２においても実施例１と同様の作用効果を奏する。

上述した例において、結果比較部４３は差分ＤＢ４４のすべての内容を比較するようにしたが（図１３のＳ５４）、例えば、比較対象をサブエントリの要素のみを比較するようにしてもよい。図９の例では、要素４３１〜４３５、４５１のみ比較するようにしてもよい。差分ＤＢ４４（結果保存ＤＢ４２と同一の構成）のサブエントリ４２１〜４２５、４４１〜４４２、４６１は、経路が変動してもしなくても、その内容に変化はなく、経路に変動があったとき、プローブ応答パケットの送信元（Ｓｒｃ）アドレスが変化するからである。この場合、結果比較部４３は、すべての内容を比較していないため、その分処理を早くすることができる。勿論、上述した例と同様の作用効果も奏する。

次に実施例３について説明する。本実施例３は、重複したプローブパケットの送信を防止し、網に対する調査を低負荷で行い得るようにした例である。

図２において、パケット生成部３１は、アドレス抽出部２１から抽出されたアドレスが入力される度にプローブパケットを生成することになる。以前に送信した同じアドレスに対して、プローブパケットを重複して生成し、網に送信することもある。

そこで、本実施例３では、同じアドレスにプローブパケットを送信するような、重複したプローブパケットの送信を防止するようにしている。

図１４は、本実施例３におけるキャプチャ端末１の構成例を示す図である。実施例１（図２）と異なるのは、ユーザトラフィック抽出部２０において、ユーザトラフィックテーブル２２とタイムアウト部２３とを備える点である。

ユーザトラフィックテーブル２２は、アドレス抽出部２１により抽出された送信元（Ｓｒｃ）アドレスと宛て先（Ｄｓｔ）アドレスとの組が記憶される。

また、タイムアウト部２３は、網オペレータ等により設定された時間が経過すると、ユーザトラフィックテーブル２２に記憶されたエントリを削除する。

図１５は、重複プローブ防止機能を実行するための処理の動作を示すフローチャートの例である。タイムアウトの処理も付加されている。

アドレス抽出部２１は、アドレス抽出機能を実行する処理を開始すると（Ｓ６０）、ユーザトラフィックのパケットから送信元（Ｓｒｃ）アドレスと、宛て先（Ｄｓｔ）アドレスとを抽出する（Ｓ６１）。実施例１と同様である。

次いで、アドレス抽出部２１は、ユーザトラフィックテーブル２２を参照して、アドレスの組によるエントリが存在するか否か判断する（Ｓ６２）。

ユーザトラフィックテーブル２２には、以前にプローブパケットを送信したアドレスの組が記憶されている。従って、アドレス抽出部２１が、例えば、宛て先アドレスをキーにして検索し、マッチするアドレスが存在すれば以前にプローブパケットを送信したことを意味することになる。

よって、ユーザトラフィックテーブル２２にエントリが存在すれば（Ｓ６２で「エントリ存在する」）、アドレス抽出部２１はパケットを破棄して処理を終了させる（Ｓ６３）。この場合、パケット生成部３１に各アドレスが出力されないため、プローブパケットは生成されない。

一方、ユーザトラフィックテーブル２２にエントリが存在しなければ（Ｓ６２で「エントリ存在しない」）、アドレス抽出部２１は、ユーザトラフィックテーブル２２に対して、送信元（Ｓｒｃ）と宛て先（Ｄｓｔ）のアドレスの組である新たなエントリを作成する（Ｓ６４）。このとき、アドレス抽出部２１は、テーブル２２にエントリを作成した時間（タイムスタンプ）も同時に記憶する。

そして、アドレス抽出部２１は各アドレスをパケット生成部３１に出力し、プローブパケットが生成される。その後の処理は実施例１と同様である。

また、タイムアウト部２３では、予め網オペレータ等が設定した時間（ｎ分：例えば、メモリに記憶されたタイムアウト時間）から、エントリの「タイムスタンプ」が現在よりｎ分前か否かを判断する（Ｓ７１）。つまり、タイムアウト部２３は「タイムスタンプ」の時間から、「タイムアウト時間」経過したか否かを判断する。勿論、タイムアウト時間は「分」単位ではなく、「秒」単位でもよい。

設定したタイムアウト時間経過したとき（Ｓ７１で「はい」）、タイムアウト部２３はユーザトラフィックテーブル２２の該当エントリを削除する（Ｓ７２）。これにより、ユーザトラフィックテーブル２２のエントリが増大するのを防止できる。

一方、決定したタイムアウト時間経過していないとき（Ｓ７１で「いいえ」）、又は該当エントリ削除後、タイムアウト部２３はテーブル２２内の全エントリを走査し（Ｓ７３）、常にタイムアウト時間経過したか否か調査することになる。

一定時間経過してもパケットを網に送信し続けるトラフィックに対しては、エントリが削除された後、再度、エントリがテーブル２２内に作成されるため、プローブパケットの送信は継続することができる。

このように、本実施例３では、ユーザトラフィックテーブル２２に同一のアドレスが記憶されていれば、プローブパケットが生成、送信されないため、重複したプローブパケットの送信を防止することができ、網に対して低負荷で実施例１と同様の調査を行うことができる。

また、この際にユーザトラフィックテーブル２２に対して一定時間経過後、該当エントリを削除してエントリの増大を防ぐとともに、一定時間経過しても通信が継続するトラフィックに対しては継続調査を行うこともできる。

尚、本実施例３は、上述した実施例２においても実施可能であり、実施例２と同様の作用効果を奏する。

以上まとめると付記のようになる。

（付記１）
網の経路状態を調査する管理装置において、
前記網からのトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理装置。

（付記２）
更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する付記１記載の管理装置。

（付記３）
前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする付記２記載の管理装置。

（付記４）
前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする付記１記載の管理装置。

（付記５）
前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする付記４記載の管理装置。

（付記６）
前記パケット送受信部は、前記プローブ応答パケットを受信するともに、前記網に転送されずループバック機能により前記プローブパケットを受信し、
前記結果保存部は、前記プローブ応答パケットと、前記ループバック機能により受信した前記プローブパケットとから前記経路情報を作成することを特徴とする付記２記載の管理装置。

（付記７）
前記プローブパケット生成部は、抽出された前記アドレス情報に対して、予め設定されたホップ数分の前記プローブパケットを生成することを特徴とする付記１記載の管理装置。

（付記８）
前記プローブパケット生成部は、前記プローブパケットごとに異なる識別子を、生成された前記プローブパケットに付加することを特徴とする付記１記載の管理装置。

（付記９）
前記識別子は、前記プローブパケットの送信先であるターゲットごとにユニークなシーケンス番号と、送信される前記プローブパケットのホップ数を示す値とを含むことを特徴とする付記８記載の管理装置。

（付記１０）
前記結果保存部は、前記シーケンス番号が同一の前記プローブ応答パケットを同一エントリ内にまとめて保存することを特徴とする付記９記載の管理装置。

（付記１１）
前記プローブ応答パケットには前記プローブパケットの送信された前記ターゲットのアドレス情報が含まれ、前記結果保存部には前記アドレス情報が前記エントリ内に含まれることを特徴とする付記１０記載の管理装置。

（付記１２）
網の経路状態を調査する管理方法において、
前記網からのトラフィックを受信し、
受信した前記トラフィックから、アドレス情報を抽出し、
抽出された前記アドレス情報を送信先とするプローブパケットを生成し、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理方法。

（付記１３）
網の経路状態を調査する管理プログラムにおいて、
前記網からのトラフィックを受信する処理と、
受信した前記トラフィックから、アドレス情報を抽出する処理と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信する処理と、
をコンピュータに実行させることを特徴とする管理プログラム。

（付記１４）
端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、
前記管理装置には、
前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする網システム。

ネットワークシステムの構成例を示す図である。 キャプチャ／プローブ端末の構成例を示す図である。 図３（Ａ）はＩＰパケットの構成例、同図（Ｂ）はターゲット定義テーブルの構成例を示す図である。 ユーザトラフィック抽出部における処理の動作を示すフローチャートの例である。 プローブパケット生成部における処理の動作を示すフローチャートの例である。 図６（Ａ）及び（Ｂ）は、プローブパケットの例を示す図である。 図７（Ａ）はプローブパケットの例、同図（Ｂ）はプローブ応答パケットの例を示す図である。 結果保存部にける処理の動作を示すフローチャートの例である。 結果保存データベースの構成例を示す図である。 ネットワークシステムにおけるパケットの転送例を示す図である。 ネットワークシステムにおけるパケットの転送例を示す図である。 キャプチャ／プローブ端末の他の構成例を示す図である。 結果比較機能を実行するための処理の動作を示すフローチャートの例である。 キャプチャ／プローブ端末の他の構成例を示す図である。 重複プローブ防止機能を実行するための処理の動作を示すフローチャートの例である。

符号の説明

１ キャプチャ／プローブ端末
１０ パケット送受信部
１１ パケット受信部
１２ 振り分け部
１３ パケット送信部
２０ ユーザトラフィック抽出部
２１ アドレス抽出部
２２ ユーザトラフィックテーブル
２３ タイムアウト部
３０ プローブパケット生成部
３１ パケット生成部
３２ ターゲット定義テーブル
３３ シーケンス値カウンタ
４０ プローブ受信部
４１ 結果保存部
４２ 結果保存データベース（結果保存ＤＢ）
４３ 結果比較部
４４ 差分データベース（差分ＤＢ）
２００、２１０ 端末
３００ ＩＰネットワーク
３１０〜３７０ ノード
４００ サーバ
５００ ＩＰパケット
５３０ プローブパケット
５５０ プローブ応答パケット
４２１〜４２５、４４１〜４４２、４６１ サブエントリ
４３１〜４３５、４５１ サブエントリの要素

Claims (8)

1. 網の経路状態を調査する管理装置において、
   前記網からのトラフィックを受信するパケット送受信部と、
   受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
   抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
   前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記プローブパケットに対するプローブ応答パケットを受信し、
   前記プローブパケット生成部は、抽出された前記アドレス情報を送信先とする前記プローブパケットに対して予め設定されたホップ数分の前記プローブパケットを生成し、更に、前記プローブパケットごとに異なる識別子を前記プローブパケットに付加することを特徴とする管理装置。
2. 更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する請求項１記載の管理装置。
3. 前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする請求項２記載の管理装置。
4. 前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする請求項１記載の管理装置。
5. 前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする請求項４記載の管理装置。
6. 網の経路状態を調査する管理方法において、
   前記網からのトラフィックを受信し、
   受信した前記トラフィックから、アドレス情報を抽出し、
   抽出された前記アドレス情報を送信先とするプローブパケットを生成し、
   生成された前記プローブパケットを前記網に送信するとともに、前記プローブパケットに対するプローブ応答パケットを受信し、
   前記プローブパケットを生成するとき、抽出された前記アドレス情報を送信先とする前記プローブパケットに対して予め設定されたホップ数分の前記プローブパケットを生成し、更に、前記プローブパケットごとに異なる識別子を前記プローブパケットに付加することを特徴とする管理方法。
7. 網の経路状態を調査する管理プログラムにおいて、
   前記網からのトラフィックを受信する処理と、
   受信した前記トラフィックから、アドレス情報を抽出する処理と、
   抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、
   生成された前記プローブパケットを前記網に送信するとともに、前記プローブパケットに対するプローブ応答パケットを受信する処理と、
   をコンピュータに実行させ、
   前記プローブパケットを生成する処理において、抽出された前記アドレス情報を送信先とする前記プローブパケットに対して予め設定されたホップ数分の前記プローブパケットを生成し、更に、前記プローブパケットごとに異なる識別子を前記プローブパケットに付加する処理を前記コンピュータに実行させることを特徴とする管理プログラム。
8. 端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、
   前記管理装置には、
   前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、
   受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
   抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
   前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記プローブパケットに対するプローブ応答パケットを受信し、
   前記プローブパケット生成部は、抽出された前記アドレス情報を送信先とする前記プローブパケットに対して予め設定されたホップ数分の前記プローブパケットを生成し、更に、前記プローブパケットごとに異なる識別子を前記プローブパケットに付加するすることを特徴とする網システム。

Images