(57)【要約】【課題】ユーザトラフィックに応じて網の経路状態を即時取得できる管理装置、管理方法、プログラム、及びその網システムを提供すること。また、網の経路変動を検出できる管理装置等を提供すること。【解決手段】パケット受信部１１は、網に転送されるユーザトラフィックのパケットを受信する。受信したパケットは、振り分け部１２を介してアドレス抽出部２１に転送され、送信元アドレスと宛て先アドレスとを抽出する。パケット生成部３１は、これらのアドレスに基づいてそのアドレス先を転送先とするプローブパケットを生成する。パケット送信部１３はプローブパケットを網に送信する。送信されたプローブパケットは、プローブ応答パケットとしてパケット受信部１１で受信する。パケット受信部１１で受信したプローブ応答パケットは、振り分け部１２を介して結果保存部４１に転送される。結果保存部４１は、結果保存ＤＢ４２にそのプローブパケットに含まれる送信元アドレスを保存する。【選択図】図２
2007325154.tif 000002
【特許請求の範囲】
【請求項１】
網の経路状態を調査する管理装置において、
前記網からのトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理装置。  
【請求項２】
更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する請求項１記載の管理装置。
【請求項３】
前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする請求項２記載の管理装置。
【請求項４】
前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする請求項１記載の管理装置。
【請求項５】
前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする請求項４記載の管理装置。
【請求項６】
網の経路状態を調査する管理方法において、
前記網からのトラフィックを受信し、
受信した前記トラフィックから、アドレス情報を抽出し、
抽出された前記アドレス情報を送信先とするプローブパケットを生成し、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理方法。
【請求項７】
網の経路状態を調査する管理プログラムにおいて、
前記網からのトラフィックを受信する処理と、
受信した前記トラフィックから、アドレス情報を抽出する処理と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信する処理と、
をコンピュータに実行させることを特徴とする管理プログラム。
【請求項８】
端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、
前記管理装置には、
前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする網システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、網の経路状態を調査する管理装置、及びその網システムに関する。詳しくは、網の経路状態が即時取得可能で経路変動も検出可能な管理装置等に関する。
【背景技術】
【０００２】
従来から、網（又はネットワーク、以下「網」と称す）の経路状態を把握するコマンドとして、ｔｒａｃｅｒｏｕｔｅコマンドがある。
【０００３】
ｔｒａｃｅｒｏｕｔコマンドの起動により、ＴＴＬ（Time to Live：パケットの有効期限）を「１」から順に大きくしたパケットが宛て先アドレスに送出される。ＴＴＬの値に従い、当該コマンドを発行した端末から数えて１ホップ目、２ホップ目、・・・のネットワークノードは、有効期限エラーを示すパケットを返信する。宛て先アドレスの端末がこのパケットを返信するまで、ＴＴＬを順に大きくすることで、その間の経路が明らかになる。
【０００４】
また、他の従来技術として、コマンド発行端末から経路トレースを示すフラグを付したフォーマット信号が送信され、各ノードは受信ポートのアドレス及び送出ポートのアドレスを付加して次のノードに送信し、付加累積された受信ポート及び送出ポートのアドレスの繋がりから送信経路をトレースするようにしたものがある（例えば、以下の特許文献１）。
【０００５】
更に、送信されたフィルタ設定パケットから、経路に沿った動的パケットフィルタを設定し、このフィルタによって検出されたデータの収集により、ネットワーク内の実パケットを追跡することで、経路情報を取得するようにしたものも開示される（例えば、以下の特許文献２）。
【特許文献１】特開２０００−２４４５６３号公報
【特許文献２】特開２００５−３１２０３３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、ｔｒａｃｅｒｏｕｔｅコマンドは、網オペレータ又はユーザ（以下、「網オペレータ等」と称す）が自ら端末を操作して発行させる必要がある。元来、当該コマンドは、網オペレータ等が何らかの方法で網の障害を認識した後で発行されるコマンドである。従って、障害発生時点で当該コマンドを発行した場合でなければ、障害発生時点での経路状態を取得することは困難である。
【０００７】
また、ｔｒａｃｅｒｏｕｔｅコマンドの発行をスクリプト等により、ある程度自動化（例えば、一定時間）することも考えられる。しかし、同様に、障害が発生した時点でコマンドが発行されなければ障害発生時点での経路状態を取得することは困難である。
【０００８】
更に、ｔｒａｃｅｒｏｕｔｅコマンドはその場限りのコマンドであり、当該コマンドの起動により発行される各パケットにおいて、その前後の結果を比較して経路変動を把握することはできない。従って、当該コマンドでは、経路が変動した場合でも、網オペレータ等に通知することができない。
【０００９】
一方、特許文献１及び２に関しても、フォーマット信号やフィルタ設定パケットを網オペレータ等が端末の操作により自ら発行させる必要があり、障害発生時点での経路状態を取得することが困難である。
【００１０】
そこで、本発明は、上記問題点に鑑みてなされたもので、その目的は、ユーザトラフィックに応じて網の経路状態を即時取得できる管理装置、管理方法、プログラム、及びその網システムを提供することにある。
【００１１】
また、本発明の他の目的は、網の経路変動を検出できる管理装置等を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、本発明の一実施態様によれば、網の経路状態を調査する管理装置において、前記網からのトラフィックを受信するパケット送受信部と、受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。
【００１３】
また、本発明の他の実施態様によれば、前記管理装置において、更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する。
【００１４】
更に、本発明の他の実施態様によれば、前記管理装置において、前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする。
【００１５】
更に、本発明の他の実施態様によれば、前記管理装置において、前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする。
【００１６】
更に、本発明の他の実施態様によれば、前記管理装置において、前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする。
【００１７】
更に、本発明の他の実施態様によれば、前記管理装置において、前記パケット送受信部は、前記プローブ応答パケットを受信するともに、前記網に転送されずループバック機能により前記プローブパケットを受信し、前記結果保存部は、前記プローブ応答パケットと、前記ループバック機能により受信した前記プローブパケットとから前記経路情報を作成することを特徴とする。
【００１８】
更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブパケット生成部は抽出された前記アドレス情報に対して予め設定されたホップ数分の前記プローブパケットを生成することを特徴とする。
【００１９】
更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブパケット生成部は前記プローブパケットごとに異なる識別子を生成された前記プローブパケットに付加することを特徴とする。
【００２０】
更に、本発明の他の実施態様によれば、前記管理装置において、前記識別子は前記プローブパケットの送信先であるターゲットごとにユニークなシーケンス番号と、送信される前記プローブパケットのホップ数を示す値とを含むことを特徴とする。
【００２１】
更に、本発明の他の実施態様によれば、前記管理装置において、前記結果保存部は前記シーケンス番号が同一の前記プローブ応答パケットを同一エントリ内にまとめて保存することを特徴とする。
【００２２】
更に、本発明の他の実施態様によれば、前記管理装置において、前記プローブ応答パケットには前記プローブパケットの送信された前記ターゲットのアドレス情報が含まれ、前記結果保存部には前記アドレス情報が前記エントリ内に含まれることを特徴とする。
【００２３】
また、上記目的を達成するために本発明の他の実施態様によれば、網の経路状態を調査する管理方法において、前記網からのトラフィックを受信し、受信した前記トラフィックから、アドレス情報を抽出し、抽出された前記アドレス情報を送信先とするプローブパケットを生成し、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。
【００２４】
更に、上記目的を達成するために本発明の他の実施態様によれば、網の経路状態を調査する管理プログラムにおいて、前記網からのトラフィックを受信する処理と、受信した前記トラフィックから、アドレス情報を抽出する処理と、抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信する処理と、をコンピュータに実行させることを特徴とする。
【００２５】
更に、上記目的を達成するために本発明の他の実施態様によれば、端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、前記管理装置には、前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする。
【発明の効果】
【００２６】
本発明によれは、ユーザトラフィックに応じて網の経路状態を即時取得できる管理装置、管理方法、プログラム、及びその網システムを提供することができる。また、本発明によれば、網の経路変動を検出できる管理装置等を提供することができる。
【発明を実施するための最良の形態】
【００２７】
以下、図面を参照して本発明を実施するための最良の形態を説明する。
【実施例１】
【００２８】
まず、実施例１について説明する。本実施例１は、網に転送されるトラフィック（又はパケットデータ）をキャプチャし、そのパケットと同じアドレスを持つプローブパケットを、トラフィックの転送と略同時に網に転送させて、その応答パケット等を保存する等により、経路状態を即時に取得することができるようにした例である。
【００２９】
図１は、実施例１において適用されるネットワークシステム（網システム）１００の構成例を示す図である。ネットワークシステム１００は、キャプチャ／プローブ端末（以下、「キャプチャ端末」と称す）１と、端末２００と、サーバ４００とから構成される。キャプチャ端末１等はＩＰ（Internet Protocol）ネットワーク３００を介して互いに接続される。
【００３０】
また、ＩＰネットワーク３００は、複数のノード３１０〜３７０を有し、図１に示す経路により互いに接続される。
【００３１】
図２は、キャプチャ端末１の構成例を示す図である。キャプチャ端末１は、パケット送受信部１０と、ユーザトラフィック抽出部２０と、プローブパケット生成部３０、及びプローブ受信部４０を備える。このキャプチャ端末１が、網の経路状態を調査する管理装置としての役割を果たす。
【００３２】
パケット送受信部１０は、パケット受信部１１と、振り分け部１２、及びパケット送信部１３を備える。
【００３３】
パケット受信部１１は、端末２００や各ノード３１０〜３７０、サーバ４００から送信されたパケットデータを受信する。
【００３４】
振り分け部１２は、パケット受信部１１で受信したパケットが、ユーザトラフィックのパケットか、後述するプローブ応答パケット（或いはプローブパケット）か、を判別する。そして、振り分け部１２は、ユーザトラフィックのパケットをユーザトラフィック抽出部２０に、プローブ応答パケット等はプローブ受信部４０に振り分ける（又は、廃棄する）。振り分けは、受信したパケットデータのプロトコルフィールドやポート番号を利用する。詳細は後述する。
【００３５】
パケット送信部１３は、プローブパケット生成部３０で生成されたプローブパケットを、ＩＰネットワーク３００を介して、端末２００や各ノード３１０〜３７０、サーバ４００に送信する。前述のプローブ応答パケットは、プローブパケットを受信した各ノード３１０〜３７０等がキャプチャ端末１に対して送信するパケットである。
【００３６】
ユーザトラフィック抽出部２０は、アドレス抽出部２１を備える。アドレス抽出部２１は、ユーザトラフィックのパケットから、送信元アドレス（Ｓｒｃアドレス）と、宛て先アドレス（Ｄｓｔアドレス）とを抽出する。アドレス抽出部２１は、抽出した送信元アドレス等をプローブパケット生成部３０に出力する。
【００３７】
プローブパケット生成部３０は、パケット生成部３１と、ターゲット定義テーブル３２と、シーケンス値カウンタ３３とを備える。
【００３８】
パケット生成部３１は、送信元アドレスと宛て先アドレスとから、プローブパケットを生成する。パケット生成部３１は、ターゲット定義テーブル３２を参照して、合致した送信元アドレス及び宛て先アドレスの組がある場合にプローブパケットを生成する。また、パケット生成部３１は、シーケンス値カウンタ３３を参照し、プローブパケットのシーケンス番号を演算し、プローブパケットの所定フィールドに格納する。詳細は後述する。パケット生成部３１は、生成したプローブパケットをパケット送信部１３に出力する。
【００３９】
ターゲット定義テーブル３２は、プローブパケットの送信を行うターゲットを定義するテーブルである。具体的には、ターゲット定義テーブル３２には、ターゲット（プローブパケットの送信先）のアドレスが記憶される。
【００４０】
シーケンス値カウンタ３３は、シーケンス番号のベースとなる値を保持するカウンタである。シーケンス番号は、どのターゲット宛てのプローブパケットか、ターゲットの重複を識別するために、或いは、ターゲットが同じになるようなプローブパケットを送信するときにターゲットの重複を区別するために、プローブパケットに付与される番号である。詳細は後述する。
【００４１】
プローブ受信部４０は、結果保存部４１と、結果保存データベース（ＤＢ）４２とを備える。
【００４２】
結果保存部４１は、振り分け部１２からのプローブパケットとプローブ応答パケットとを分類して結果保存ＤＢ４２に格納する。結果保存ＤＢ４２には、後述するように各パケットに基づくエントリが記憶され、調査した経路状態を把握することができる。
【００４３】
次に、キャプチャ端末１の動作について説明するが、その前に、まずユーザトラフィックのパケットである、ＩＰパケットの例について説明する。
【００４４】
図３（Ａ）は、パケット受信部１１で受信するＩＰパケット５００の構成例を示す図である。ＩＰパケット５００は、プロトコルを識別するためのデータが格納されるプロトコルフィールド５１０と、送信元と宛て先の夫々のＩＰアドレスが格納される送信元ＩＰアドレスフィールド５１１及び宛て先ＩＰアドレスフィールド５１２と、送信元と宛て先の夫々のポート番号が格納される送信元ポート番号フィールド５１３及び宛て先ポート番号フィールド５１４と、種々のデータが格納されるペイロード５１５とから構成される。
【００４５】
パケット送受信部１０の振り分け部１２では、パケットを振り分けることになるが、例としてＨＴＴＰパケットをユーザトラフィックのパケットとした場合は以下のようになる。即ち、振り分け部１２は、送信元ポート番号と宛て先ポート番号とを、受信したＩＰパケット５００の該当フィールド５１３、５１４から取り出す。そして、そのいずれかの番号が「８０」又は「８０８０」のとき、振り分け部１２は受信したパケットがＨＴＴＰパケットであるとしてユーザトラフィック抽出部２０に出力する。
【００４６】
なお、振り分け部１２は、ユーザトラフィックのパケットを振り分けた後、引き続いてプローブパケット、プローブ応答パケットの振り分け処理を行う。即ち、受信したＩＰパケット５００のプロトコルフィールド５１０を取り出し、それがプローブパケット又はプローブ応答パケット（ＩＣＭＰパケット）であることを示すものであったとき、振り分け部１２は受信したパケットがプローブパケット又はプローブ応答パケットであるとしてプローブ受信部４０に出力する。
【００４７】
図４は、ユーザトラフィック抽出部２０で実行されるアドレス抽出処理のフローチャートの例である。
【００４８】
まず、ユーザトラフィック抽出部２０は、アドレス抽出機能を実行するための処理を開始すると（Ｓ１０）、振り分け部１２から出力されたＨＴＴＰパケットから、送信元アドレス（Ｓｒｃアドレス）と宛て先アドレス（Ｄｓｔアドレス）とを抽出する（Ｓ１１）。そして、抽出した各アドレスをプローブパケット生成部３０のパケット生成部３１に出力する（Ｓ１２）。そして、アドレス抽出機能の処理が終了する。
【００４９】
その後、プローブパケット生成部３０において、抽出したアドレスに基づいて、プローブパケットの生成機能が実行される。図５は、そのフローチャートの例である。
【００５０】
尚、本実施例では、この機能が実行される前に、以下の処理が行われる。まず、オペレータ等は、ターゲット定義テーブル３２にターゲットを記憶しておく。図３（Ｂ）は、ターゲット定義テーブル３２の例である。同図に示すように、プローブパケットのターゲットとなるべき、サーバ４００等のアドレスが記憶される。
【００５１】
また、オペレータ等はプローブパケットを送信するホップ数も予め設定しておく。例えば、キャプチャ端末１のメモリ等に記憶する。調査したいホップ数を設定するもので、網の規模等によって数も変動する。
【００５２】
更に、オペレータ等は、シーケンス値カウンタ３３を任意の値で初期化する。
【００５３】
本実施例では、ターゲット定義テーブル３２を「＊」（すべてのターゲット、即ち、ノード３１０を通る全てのＨＴＴＰパケットを対象にする）、ホップ数を「５」、シーケンス値カウンタ３３の初期値を「１」とする。
【００５４】
図５に戻り、プローブパケット生成機能を実行するための処理が開始されると（Ｓ２０）、パケット生成部３１は、ＴＴＬカウンタ値を「０」にして初期化する（Ｓ２１）。
【００５５】
ＴＴＬカウンタ値とは、送信するプローブパケットのホップ数をカウントするための値である。予め設定されたホップ数分のプローブパケットの生成が終了すると、プローブ生成処理が終了する。
【００５６】
次いで、パケット生成部３１は、ターゲット定義テーブル３２に記憶されたエントリを参照して、ユーザトラフィック抽出部２０で抽出されたアドレスがターゲット定義テーブル３２に存在するか否かを判断する（Ｓ２２）。ターゲット定義テーブル３２に存在しないと（Ｓ２２で「ない」）、プローブパケット生成機能は終了する。
【００５７】
一方、ターゲット定義テーブル３２に抽出したアドレスが存在すれば（Ｓ２２で「あり」）、パケット生成部３１は、ＴＴＬカウンタ値を「＋１」加算する（Ｓ２３）。上記設定では、ターゲット定義テーブル３２は「＊」のため、抽出したアドレスが存在し、ＴＴＬカウンタ値が「１」となる。
【００５８】
次いで、パケット生成部３１は、実際にプローブパケットの生成処理（Ｓ２４、Ｓ２５）を行う。２つの処理により、それぞれ異なるプローブパケットが生成される。
【００５９】
図６（Ａ）及び（Ｂ）は、プローブパケットの例を示す図である。プローブパケット５３０は、送信元と宛て先のＩＰアドレスが夫々格納される送信元（Ｓｒｃ）ＩＰアドレス５３２及び宛て先（Ｄｓｔ）ＩＰアドレスフィールド５３３と、シーケンス番号が格納されるシーケンス番号フィールド５３５と、ＴＴＬカウンタ値が格納されるＴＴＬフィールド５３６とを有する。
【００６０】
同図に示す例では、Ｓ２４の処理により図６（Ａ）に示すプローブパケットが生成され、Ｓ２５の処理により図６（Ｂ）に示すプローブパケットが生成される。
【００６１】
まず、Ｓ２４の処理において、パケット生成部３１は、ユーザトラフィック抽出部２０により取得したＨＴＴＰパケットの宛て先アドレスを、プローブパケットの宛て先ＩＰアドレスフィールド５３３に格納する。また、送信元ＩＰアドレスフィールド５３２にキャプチャ端末１自身のＩＰアドレスを格納する。
【００６２】
そして、シーケンス番号フィールド５３５に、「シーケンスカウンタ値×バイアス値（Ｄ）＋ＴＴＬカウンタ値」を格納する。上記設定では、シーケンスカウンタ値は「１」、ＴＴＬカウンタ値はＳ２３により「１」となる。また、バイアス値（Ｄ）は本実施例では「１００」とすると、シーケンス番号は、１×１００＋１＝１０１となる。
【００６３】
また、Ｓ２５の処理において、パケット生成部３１は、取得したパケットの送信元アドレスを、さらに別のプローブパケット５３０の宛て先ＩＰアドレスフィールド５３３に格納する。送信元ＩＰアドレスフィールド５３２は、キャプチャ端末１自身のＩＰアドレスが格納される。
【００６４】
そして、シーケンス番号フィールド５３５に、「シーケンス値カウンタ×バイアス値（Ｓ１）＋バイアス値（Ｓ２）＋ＴＴＬカウンタ値」を格納する。バイアス値（Ｓ１）を「１００」、バイアス値（Ｓ２）を「５０」とすると、シーケンス番号は、１×１００＋５０＋１＝１５１となる。
【００６５】
次いで、パケット生成部３１は、生成したプローブパケットをパケット送信部１３に転送する（Ｓ２６）。生成された２つのプローブパケットが網に送信されることになるが、一方のプローブパケットは、宛て先が「取得した宛て先アドレス」のため、ＨＴＴＰパケットの送信先（例えば、サーバ４００）に送信される。
【００６６】
他方のプローブパケットは、宛て先が「取得した送信元アドレス」のため、ＨＴＴＰパケットの送信元（例えば、端末２００）に送信される。
【００６７】
そして、設定したホップ数分（ｍ回）繰り返したか否か判断する（Ｓ２７）。上述の例では、ホップ数は「５」のため、上述の処理を５回繰り返すことになる。
【００６８】
２回目の処理のときは、Ｓ２３により、ＴＴＬカウンタ値が「２」となり、Ｓ２４の処理により、シーケンス番号が１×１００＋２＝１０２であるプローブパケットが生成される。また、３回目の処理のときは、シーケンス番号が１×１００＋３＝１０３であるプローブパケットが生成される。このように、ユーザトラフィックのパケットの送信先（例えば、サーバ４００）に送信されるプローブパケットのシーケンス番号は、パケットごとに夫々異なる番号を有することになる。
【００６９】
一方、Ｓ２５の処理により生成されるプローブパケットは、２回目の処理で、１×１００＋５０＋２＝１５２のシーケンス番号、３回目の処理で１×１００＋５０＋３＝１５３のシーケンス番号を、夫々有することになる。このように、ユーザトラフィックのパケットの送信元（例えば、端末２００）に送信されるプローブパケットもパケットごとに夫々異なる番号を有する。更に、サーバ４００に送信されるプローブパケットと端末２００に送信されるプローブパケットとも夫々異なる番号を有し、ユニークな番号となる。
【００７０】
上述の例では、ホップ数は「５」（＝ｍ）のため、夫々「５」個の計「１０」個のプローブパケットが生成される（夫々異なるシーケンス番号を有する）。
【００７１】
図５に戻り、ｍ回繰り返したとき（Ｓ２７でＹＥＳ）、パケット生成部３１は、シーケンス値カウンタ３３を「＋１」加算する。この加算により、更に、キャプチャ端末１から送信されるプローブパケットのユニーク性が保証される。
【００７２】
即ち、シーケンス値カウンタ３３が「＋１」加算され、更に別途ＨＴＴＰパケットを受信すると、Ｓ２４の処理により生成されるプローブパケットのシーケンス番号は「２×１００＋１＝２０１」、２回目の処理では、「２×１００＋２＝２０２」となる。最初の処理で生成されたプローブパケットの各シーケンス番号と比較しても、ユニークなものとなる。
【００７３】
そして、パケット送信部１３から、生成されたプローブパケットが送信される。図７（Ａ）は、プローブパケットの構成例を示す図である。図６（Ａ）等と同一部分には同一の符号を付している。
【００７４】
このプローブパケット５３０を受けた各ノード３１０〜３７０等は、プローブ応答パケットを生成してキャプチャ端末１に順次送信する。
【００７５】
図７（Ｂ）は、プローブ応答パケット５５０の構成例を示す図である。全体の構成は、プローブパケット５３０と同様である。送信元ＩＰアドレスフィールド５５２には、各ノード３１０〜３７０等のＩＰアドレスが格納される。また、宛て先ＩＰアドレスフィールド５５３には、キャプチャ端末１のＩＰアドレスが格納される。
【００７６】
プローブパケットを送信後、しばらくすると、パケット受信部１１は、プローブ応答パケットとプローブパケットを相次いで受信（又は、キャプチャ）する。
【００７７】
ここでプローブパケットは、パケット送信部１３からノード３１０〜３７０等を介さずに直接パケット受信部１１で受信される。これは、パケット送信部１３やパケット受信部１１がループバック機能を用いているからである。このようなループバック機能は、パケット受信部１１等を構成するインターフェースが標準的に装備している。
【００７８】
振り分け部１２は、ループバック機能によるプローブパケット及びプローブ応答パケットと、ユーザトラフィックのパケットとを振り分ける。上述のように、パケットのプロトコルフィールドに格納された値により振り分ける。
【００７９】
プローブ受信部４０は、振り分けられたプローブパケットとプローブ応答パケットとに対して結果保存機能の処理を実行する。図８は、結果保存部４１におけるフローチャートの例である。
【００８０】
結果保存部４１は、結果保存機能を実行するための処理を開始すると（Ｓ４０）、パケット（プローブパケット又はプローブ応答パケット）からシーケンス番号を抽出し、シーケンス番号からシーケンスカウンタ値を逆算する（Ｓ４１）。
【００８１】
前述の例では、シーケンス番号の「１００」の位を確認すれば判明できる。例えば、シーケンス番号が「１０１」のとき、シーケンス値カウンタは「１」、シーケンス番号が「２０３」のとき、シーケンス値カウンタは「２」であると判明できる。
【００８２】
次いで、結果保存部４１は、シーケンス値カウンタと宛て先（Ｄｓｔ）アドレスとをキーにして、結果保存ＤＢ４２に既存エントリが存在するか否かを判断する（Ｓ４２）。
【００８３】
これにより、受信したパケットが既に受信している途中の経路調査用のプローブパケット群の一部であるか、又は、新たに調査を始めた経路調査用のプローブパケットであるかを判別することができる。
【００８４】
図９は、結果保存ＤＢ４２の構成例である。１エントリは、プローブパケットに基づくサブエントリ４２１〜４２５と、サブエントリ４２１〜４２５の要素４３１〜４３５とから構成される。各エントリ４２１〜４２５等は、ＴＴＬ順に並べられる。本フローチャートによりこの結果保存ＤＢ４２が構築される。
【００８５】
既に受信している途中の経路調査用のプローブパケットとは、結果保存ＤＢ４２に、サブエントリ４２１〜４２５のいずれかが存在している場合のパケットである。また、新たに調査を始めた経路調査用のプローブパケットとは、結果保存ＤＢ４２に該当するサブエントリ４２１〜４２５等が存在しない場合のパケットである。
【００８６】
図８に戻り、受信したパケットが新たに調査を始めた経路調査用のプローブパケットのとき（結果保存ＤＢ４２に既存エントリが存在しないとき、Ｓ４２で「エントリ存在しない」）、シーケンス値カウンタと、プローブパケットの宛て先アドレスをキーにして、結果保存ＤＢ４２に新たにエントリを追加する（Ｓ４６）。そして、結果保存機能の処理が終了する（Ｓ４７）。
【００８７】
一方、受信したプローブパケットが現在受信途中の経路調査用のプローブパケットのとき（結果保存ＤＢ４２に既存エントリが存在するとき、Ｓ４２で「エントリ存在する」）、結果保存部４１は、受信したパケットがプローブパケットかプローブ応答パケットかを判別する（Ｓ４３）。
【００８８】
この判別は、図７（Ａ）又は同図（Ｂ）に示すように、リクエスト又はレスポンスを示す値が格納されるフィールド５５４から判別できる。例えば、プローブパケットの場合、このフィールド５５４にリクエストを示す「０」、プローブ応答パケットの場合、このフィールド５５４にレスポンスを示す「１」が格納されているので、この値から判別する。
【００８９】
プローブパケットのとき（Ｓ４３で「プローブパケット」）、結果保存部４１はシーケンス値カウンタと受信パケットの宛て先（Ｄｓｔ）アドレスをキーとして、結果保存ＤＢ４２の該当するエントリに、ＴＴＬ順にサブエントリを追加する（Ｓ４８）。
【００９０】
図９の例では、サブエントリ４２１〜４２４に対して、更にサブエントリ４２５を追加する処理等が本処理（Ｓ４８）に該当する。
【００９１】
一方、プローブ応答パケットのとき（Ｓ４３で「応答パケット」）、結果保存部４１は、結果保存ＤＢ４２に該当するサブエントリが存在しているため、ＴＴＬを参照して、該当するサブエントリに要素として自パケットの送信元（Ｓｒｃ）アドレスを格納する（Ｓ４４）。
【００９２】
図９の例では、サブエントリ４２１に要素４３１として、プローブ応答パケットの送信元（Ｓｒｃ）アドレスを格納する処理が本処理（Ｓ４４）に該当する。そして、結果保存機能の一連の処理が終了する。
【００９３】
結果保存部４１は、プローブパケットやプローブ応答パケットを受信するごとに、上述の処理を行い、結果保存ＤＢ４２を構築する。そして、最終的に構築された結果保存ＤＢ４２では、プローブ応答パケットの送信元（Ｓｒｃ）アドレスが順番に並べられている。この送信元アドレスは、プローブパケットを送信したノード３１０〜３７０等のアドレスを示す。従って、結果保存ＤＢ４２の順番に並べられた送信元アドレスが経路を示すことになり、その経路が結果保存ＤＢ４２に蓄積される。
【００９４】
図１０は、本実施例１における効果を説明するための図である。端末２００から、ユーザトラフィックのパケットを、ノード３１０、３３０、３４０を経由して、サーバ４００に送信するとき、キャプチャ端末１は、ノード３１０を通過するパケットを受信（キャプチャ）する。
【００９５】
そして、キャプチャ端末１は、キャプチャしたパケットから、そのパケットの送信先（又は送信元）を宛て先とするプローブパケットを生成して網に送信する。即ち、端末２００からのユーザトラフィックのパケットと、プローブパケットとが略同時にノード３１０を経由して、順次同じ経路に伝送される。その後キャプチャ端末１は、プローブ応答パケットを受信することで、結果保存ＤＢ４２に経路が蓄積される。
【００９６】
従って、本実施例１では、経路状態をユーザトラフィックに応じて即時的に取得することが可能となる。また、キャプチャ端末１を操作する網オペレータがプローブパケットを生成するためのトリガとなる操作を別途行う必要がない。よって、経路状態を即時的に取得できるため、障害発生時点での経路状態も即時取得できる。
【００９７】
上述した例では、キャプチャ端末１を備えるネットワークシステム１００の例で説明したが、例えば、ユーザが使用する端末２１０に、上述したキャプチャ端末１の機能を備えるようにしてもよい。図１１は、そのような場合のネットワークシステム１００の構成例を示す図である。
【００９８】
この場合、端末２１０は、網を流れる多数のユーザのトラフィックをキャプチャするのではなく、ユーザ自身が（端末２１０自身が）送受信するトラフィックを対象としてキャプチャする。
【００９９】
また、プローブパケットは、ユーザトラフィックの宛て先アドレスにのみ送信される。ユーザトラフィックの送信元アドレスは端末２１０のアドレスのため、例えば図６（Ｂ）のようなプローブパケットは生成されず、送信されない。
【０１００】
更に、結果保存ＤＢ４２に蓄積される経路情報は、ユーザがアクセスした先（ユーザトラフィックの宛て先アドレスを持つサーバ４００など）に関するものとなる。
【０１０１】
この場合でも、上述した例と同様に経路状態を即時取得可能で、障害発生時点での経路状態も取得可能である。
【実施例２】
【０１０２】
次に実施例２について説明する。本実施例２は、以前に保存した経路情報と、新たに抽出した経路情報とを比較し、変動があればその旨を網オペレータやユーザに通知するようにした例である。
【０１０３】
図１２は、本実施例２において適用されるキャプチャ端末１の構成例である。実施例１のキャプチャ端末１と同一の構成部分には同一の符号を付している。異なるのは、プローブ受信部４０において、結果比較部４３と差分データベース（ＤＢ）４４とを更に備える点である。
【０１０４】
結果保存部４１により結果保存ＤＢ４２が構築されるまでは実施例１と同様である。結果保存機能の処理（図８）が終了した後、結果比較機能を実行するための処理が開示され、経路の変動が網オペレータやユーザに通知される。図１３は、結果比較機能を実行するためのフローチャートの例である。
【０１０５】
結果比較部４３は、結果比較機能を実行するための処理を開始すると（Ｓ５０）、以前の結果比較処理でメモリに展開された結果（後述）を差分ＤＢ４４に記録する（Ｓ５１）。そして、結果保存機能の処理（図８）と同様に、結果保存部４１は受信したパケット（プローブパケット又はプローブ応答パケット）に対してメモリに結果保存ＤＢ４２と同様のエントリの作成等を行う。メモリに記憶されたエントリは、その後、差分ＤＢ４４と比較することで経路の比較に用いられる。
【０１０６】
次いで、結果比較部４３は、パケットが最終応答パケットか否かを判断する（Ｓ５２）。即ち、受信したパケット（プローブパケット又はプローブ応答パケット）が最終ホップ目の宛て先（Ｄｓｔ）アドレスに対する応答パケットか否かを判断する。
【０１０７】
これは、受信パケットの送信元アドレスが、差分ＤＢ４４のエントリにあるプローブパケットの宛て先（Ｄｓｔ）アドレスと同一か否かにより判断する。或いは、プローブパケットを受信した各ノード３１０〜３７０等は、プローブパケットをプローブ応答パケットのペイロード５５７に格納しているため（図７（Ａ）及び同図（Ｂ）参照）、ペイロード５５７に格納されたプローブパケットの宛て先アドレスを参照して、差分ＤＢ４４のエントリと比較するようにしてもよい。又は、受信パケットのＴＴＬフィールド５３６、５５６に格納された値が、例えば「５」（ホップ数として最初に設定した値）であれば、最終応答パケットと判断してもよい。
【０１０８】
受信したパケットが最終応答パケットではないとき（Ｓ５２で「最終応答パケットではない」）、結果比較処理は終了する（Ｓ５６）。これは、最終パケットを受信するまでは、同一エントリ内のサブエントリや要素が全て構築されておらず、その後の処理で経路の比較を行うことができないからである。
【０１０９】
一方、受信パケットが最終応答パケットのとき（Ｓ５２で、「最終応答パケット」）、経路の比較作業を実際に行うことになる。まず、結果比較部４３は差分ＤＢ４４を参照し、メモリに記憶されたエントリのうち宛て先（Ｄｓｔ）アドレスと同一のエントリが差分ＤＢ４４に存在するか否かを判断する（Ｓ５３）。過去に同一経路について経路の比較調査を行ったか否かを判断するためである。
【０１１０】
同じ宛て先（Ｄｓｔ）アドレスのエントリが差分ＤＢ４４に存在しないとき（Ｓ５３で「存在しない」）、処理は終了する（Ｓ５７）。その経路については始めて調査することになるため差分は抽出することはできないからである。
【０１１１】
一方、同じ宛て先（Ｄｓｔ）アドレスのエントリが差分ＤＢ４４に存在するとき（Ｓ５３で「存在する」）、結果比較部４３は、差分ＤＢ４４の内容（エントリ内のシーケンス値カウンタやＳｒｃアドレス等）とメモリに記憶された内容を全て比較して、差分ＤＢ４４の内容が一致するか否か判断する（Ｓ５４）。
【０１１２】
一つでも内容が異なれば（Ｓ５４で「一致しない」）、結果比較部４３は経路に差異が存在することになるため、変動があった旨を網オペレータ又はユーザに通知する（Ｓ５８）。
【０１１３】
通知は、例えば、結果比較部４３が変動があった旨をモニタ等の表示部に表示させるようにしてもよいし、メモリ等に発生時間とともに記憶してログを取るようにしてもよい。
【０１１４】
一方、差異がないとき（Ｓ５４で「一致する」）、又は差異があって変動があった旨を通知した後、結果比較部４３は差分ＤＢ４４の既存エントリを削除して終了する（Ｓ５５）。この処理と、上述のメモリに展開された結果の差分ＤＢ４４への記録（Ｓ５１）により、常に、新しい結果が差分ＤＢ４４に保存されることになる。
【０１１５】
このように、本実施例２では、ある時点で突然経路の変動が生じた場合、差分ＤＢ４４の内容とメモリに記憶された内容とが一致しなくなり、その旨が網オペレータやユーザに通知されるため、経路の変動を網オペレータ等が把握することができる。
【０１１６】
尚、結果比較機能の処理が実行される前までは、実施例１と同様の処理が実行されるため、本実施例２においても実施例１と同様の作用効果を奏する。
【０１１７】
上述した例において、結果比較部４３は差分ＤＢ４４のすべての内容を比較するようにしたが（図１３のＳ５４）、例えば、比較対象をサブエントリの要素のみを比較するようにしてもよい。図９の例では、要素４３１〜４３５、４５１のみ比較するようにしてもよい。差分ＤＢ４４（結果保存ＤＢ４２と同一の構成）のサブエントリ４２１〜４２５、４４１〜４４２、４６１は、経路が変動してもしなくても、その内容に変化はなく、経路に変動があったとき、プローブ応答パケットの送信元（Ｓｒｃ）アドレスが変化するからである。この場合、結果比較部４３は、すべての内容を比較していないため、その分処理を早くすることができる。勿論、上述した例と同様の作用効果も奏する。
【実施例３】
【０１１８】
次に実施例３について説明する。本実施例３は、重複したプローブパケットの送信を防止し、網に対する調査を低負荷で行い得るようにした例である。
【０１１９】
図２において、パケット生成部３１は、アドレス抽出部２１から抽出されたアドレスが入力される度にプローブパケットを生成することになる。以前に送信した同じアドレスに対して、プローブパケットを重複して生成し、網に送信することもある。
【０１２０】
そこで、本実施例３では、同じアドレスにプローブパケットを送信するような、重複したプローブパケットの送信を防止するようにしている。
【０１２１】
図１４は、本実施例３におけるキャプチャ端末１の構成例を示す図である。実施例１（図２）と異なるのは、ユーザトラフィック抽出部２０において、ユーザトラフィックテーブル２２とタイムアウト部２３とを備える点である。
【０１２２】
ユーザトラフィックテーブル２２は、アドレス抽出部２１により抽出された送信元（Ｓｒｃ）アドレスと宛て先（Ｄｓｔ）アドレスとの組が記憶される。
【０１２３】
また、タイムアウト部２３は、網オペレータ等により設定された時間が経過すると、ユーザトラフィックテーブル２２に記憶されたエントリを削除する。
【０１２４】
図１５は、重複プローブ防止機能を実行するための処理の動作を示すフローチャートの例である。タイムアウトの処理も付加されている。
【０１２５】
アドレス抽出部２１は、アドレス抽出機能を実行する処理を開始すると（Ｓ６０）、ユーザトラフィックのパケットから送信元（Ｓｒｃ）アドレスと、宛て先（Ｄｓｔ）アドレスとを抽出する（Ｓ６１）。実施例１と同様である。
【０１２６】
次いで、アドレス抽出部２１は、ユーザトラフィックテーブル２２を参照して、アドレスの組によるエントリが存在するか否か判断する（Ｓ６２）。
【０１２７】
ユーザトラフィックテーブル２２には、以前にプローブパケットを送信したアドレスの組が記憶されている。従って、アドレス抽出部２１が、例えば、宛て先アドレスをキーにして検索し、マッチするアドレスが存在すれば以前にプローブパケットを送信したことを意味することになる。
【０１２８】
よって、ユーザトラフィックテーブル２２にエントリが存在すれば（Ｓ６２で「エントリ存在する」）、アドレス抽出部２１はパケットを破棄して処理を終了させる（Ｓ６３）。この場合、パケット生成部３１に各アドレスが出力されないため、プローブパケットは生成されない。
【０１２９】
一方、ユーザトラフィックテーブル２２にエントリが存在しなければ（Ｓ６２で「エントリ存在しない」）、アドレス抽出部２１は、ユーザトラフィックテーブル２２に対して、送信元（Ｓｒｃ）と宛て先（Ｄｓｔ）のアドレスの組である新たなエントリを作成する（Ｓ６４）。このとき、アドレス抽出部２１は、テーブル２２にエントリを作成した時間（タイムスタンプ）も同時に記憶する。
【０１３０】
そして、アドレス抽出部２１は各アドレスをパケット生成部３１に出力し、プローブパケットが生成される。その後の処理は実施例１と同様である。
【０１３１】
また、タイムアウト部２３では、予め網オペレータ等が設定した時間（ｎ分：例えば、メモリに記憶されたタイムアウト時間）から、エントリの「タイムスタンプ」が現在よりｎ分前か否かを判断する（Ｓ７１）。つまり、タイムアウト部２３は「タイムスタンプ」の時間から、「タイムアウト時間」経過したか否かを判断する。勿論、タイムアウト時間は「分」単位ではなく、「秒」単位でもよい。
【０１３２】
設定したタイムアウト時間経過したとき（Ｓ７１で「はい」）、タイムアウト部２３はユーザトラフィックテーブル２２の該当エントリを削除する（Ｓ７２）。これにより、ユーザトラフィックテーブル２２のエントリが増大するのを防止できる。
【０１３３】
一方、決定したタイムアウト時間経過していないとき（Ｓ７１で「いいえ」）、又は該当エントリ削除後、タイムアウト部２３はテーブル２２内の全エントリを走査し（Ｓ７３）、常にタイムアウト時間経過したか否か調査することになる。
【０１３４】
一定時間経過してもパケットを網に送信し続けるトラフィックに対しては、エントリが削除された後、再度、エントリがテーブル２２内に作成されるため、プローブパケットの送信は継続することができる。
【０１３５】
このように、本実施例３では、ユーザトラフィックテーブル２２に同一のアドレスが記憶されていれば、プローブパケットが生成、送信されないため、重複したプローブパケットの送信を防止することができ、網に対して低負荷で実施例１と同様の調査を行うことができる。
【０１３６】
また、この際にユーザトラフィックテーブル２２に対して一定時間経過後、該当エントリを削除してエントリの増大を防ぐとともに、一定時間経過しても通信が継続するトラフィックに対しては継続調査を行うこともできる。
【０１３７】
尚、本実施例３は、上述した実施例２においても実施可能であり、実施例２と同様の作用効果を奏する。
【０１３８】
以上まとめると付記のようになる。
【０１３９】
（付記１）
網の経路状態を調査する管理装置において、
前記網からのトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理装置。  
【０１４０】
（付記２）
更に、前記プローブ応答パケットから経路情報を作成し、前記経路情報を保存する結果保存部を備えることを特徴する付記１記載の管理装置。
【０１４１】
（付記３）
前記結果保存部は、保存した第１の経路情報と、新たに受信した前記プローブ応答パケットから作成した第２の経路情報とを比較することで、前記網に転送される前記トラフィックの経路の変動を検出することを特徴とする付記２記載の管理装置。
【０１４２】
（付記４）
前記ユーザトラフィック抽出部は、抽出した前記アドレス情報を保存し、新たに受信した前記トラフィックから抽出した前記アドレス情報と同一のときは、前記プローブパケット生成部に対し前記プローブパケットを生成させないようにすることを特徴とする付記１記載の管理装置。
【０１４３】
（付記５）
前記ユーザトラフィック抽出部は、保存した前記アドレス情報を一定時間経過後消去することを特徴とする付記４記載の管理装置。
【０１４４】
（付記６）
前記パケット送受信部は、前記プローブ応答パケットを受信するともに、前記網に転送されずループバック機能により前記プローブパケットを受信し、
前記結果保存部は、前記プローブ応答パケットと、前記ループバック機能により受信した前記プローブパケットとから前記経路情報を作成することを特徴とする付記２記載の管理装置。
【０１４５】
（付記７）
前記プローブパケット生成部は、抽出された前記アドレス情報に対して、予め設定されたホップ数分の前記プローブパケットを生成することを特徴とする付記１記載の管理装置。
【０１４６】
（付記８）
前記プローブパケット生成部は、前記プローブパケットごとに異なる識別子を、生成された前記プローブパケットに付加することを特徴とする付記１記載の管理装置。
【０１４７】
（付記９）
前記識別子は、前記プローブパケットの送信先であるターゲットごとにユニークなシーケンス番号と、送信される前記プローブパケットのホップ数を示す値とを含むことを特徴とする付記８記載の管理装置。
【０１４８】
（付記１０）
前記結果保存部は、前記シーケンス番号が同一の前記プローブ応答パケットを同一エントリ内にまとめて保存することを特徴とする付記９記載の管理装置。
【０１４９】
（付記１１）
前記プローブ応答パケットには前記プローブパケットの送信された前記ターゲットのアドレス情報が含まれ、前記結果保存部には前記アドレス情報が前記エントリ内に含まれることを特徴とする付記１０記載の管理装置。
【０１５０】
（付記１２）
網の経路状態を調査する管理方法において、
前記網からのトラフィックを受信し、
受信した前記トラフィックから、アドレス情報を抽出し、
抽出された前記アドレス情報を送信先とするプローブパケットを生成し、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする管理方法。
【０１５１】
（付記１３）
網の経路状態を調査する管理プログラムにおいて、
前記網からのトラフィックを受信する処理と、
受信した前記トラフィックから、アドレス情報を抽出する処理と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成する処理と、
生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信する処理と、
をコンピュータに実行させることを特徴とする管理プログラム。
【０１５２】
（付記１４）
端末とサーバとが網を介して接続されるとともに、網の経路状態を調査する管理装置が前記網に接続された網システムにおいて、
前記管理装置には、
前記端末から前記サーバに転送されるトラフィックを受信するパケット送受信部と、
受信した前記トラフィックから、アドレス情報を抽出するアドレス抽出部と、
抽出された前記アドレス情報を送信先とするプローブパケットを生成するプローブパケット生成部とを備え、
前記パケット送受信部は、生成された前記プローブパケットを前記網に送信するとともに、前記トラフィックが転送される前記網の経路に沿って送信された前記プローブパケットに対するプローブ応答パケットを受信することを特徴とする網システム。
【図面の簡単な説明】
【０１５３】
【図１】ネットワークシステムの構成例を示す図である。
【図２】キャプチャ／プローブ端末の構成例を示す図である。
【図３】図３（Ａ）はＩＰパケットの構成例、同図（Ｂ）はターゲット定義テーブルの構成例を示す図である。
【図４】ユーザトラフィック抽出部における処理の動作を示すフローチャートの例である。
【図５】プローブパケット生成部における処理の動作を示すフローチャートの例である。
【図６】図６（Ａ）及び（Ｂ）は、プローブパケットの例を示す図である。
【図７】図７（Ａ）はプローブパケットの例、同図（Ｂ）はプローブ応答パケットの例を示す図である。
【図８】結果保存部にける処理の動作を示すフローチャートの例である。
【図９】結果保存データベースの構成例を示す図である。
【図１０】ネットワークシステムにおけるパケットの転送例を示す図である。
【図１１】ネットワークシステムにおけるパケットの転送例を示す図である。
【図１２】キャプチャ／プローブ端末の他の構成例を示す図である。
【図１３】結果比較機能を実行するための処理の動作を示すフローチャートの例である。
【図１４】キャプチャ／プローブ端末の他の構成例を示す図である。
【図１５】重複プローブ防止機能を実行するための処理の動作を示すフローチャートの例である。
【符号の説明】
【０１５４】
１  キャプチャ／プローブ端末
１０  パケット送受信部  
１１  パケット受信部
１２  振り分け部
１３  パケット送信部
２０  ユーザトラフィック抽出部
２１  アドレス抽出部
２２  ユーザトラフィックテーブル
２３  タイムアウト部
３０  プローブパケット生成部
３１  パケット生成部
３２  ターゲット定義テーブル
３３  シーケンス値カウンタ
４０  プローブ受信部
４１  結果保存部
４２  結果保存データベース（結果保存ＤＢ）
４３  結果比較部
４４  差分データベース（差分ＤＢ）
２００、２１０  端末
３００  ＩＰネットワーク
３１０〜３７０  ノード
４００  サーバ
５００  ＩＰパケット
５３０  プローブパケット
５５０  プローブ応答パケット
４２１〜４２５、４４１〜４４２、４６１  サブエントリ
４３１〜４３５、４５１  サブエントリの要素
【図１】
2007325154.tif 000003
【図２】
2007325154.tif 000004
【図３】
2007325154.tif 000005
【図４】
2007325154.tif 000006
【図５】
2007325154.tif 000007
【図６】
2007325154.tif 000008
【図７】
2007325154.tif 000009
【図８】
2007325154.tif 000010
【図９】
2007325154.tif 000011
【図１０】
2007325154.tif 000012
【図１１】
2007325154.tif 000013
【図１２】
2007325154.tif 000014
【図１３】
2007325154.tif 000015
【図１４】
2007325154.tif 000016
【図１５】
2007325154.tif 000017