JP2007194764A - 運用管理システム - Google Patents

Abstract

【課題】ネットワークプロバイダがＶＰＮパスの疎通確認を行う場合、ユーザの設備を利用することなく、ネットワークプロバイダの装置を操作してＶＰＮパスの疎通確認を行う運用管理システムを提供する。
【解決手段】ネットワークプロバイダが所有するルータに対してユーザが利用するネットワークのＩＰアドレスを仮想的に割り当てることによってＶＰＮパスの疎通確認を行う。
【選択図】図１

Description

本発明は、ＶＰＮ（Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）等の通信路の管理に関する。

物理的な共用ＩＰネットワーク上に、1つ以上の論理的な仮想の専用ＩＰネットワークを構築するＶＰＮ技術がある。本技術では、複数のユーザがネットワークを利用する際、論理的な仮想通信路（以下、ＶＰＮパスと称する）を構築するルータは、ユーザ毎にＶＰＮパスの通過可否の判断、及び複数存在するＶＰＮパスへの振り分けを行う。

一方、通常のネットワーク運用管理において、ＶＰＮパスの切断・復旧が実施される場合、正常に復旧されたか否かを確認するために、ＶＰＮパスを利用する計算機からＰｉｎｇやＴｒａｃｅｒｏｕｔｅ等のプログラムを用いて、テストパケットを送信し、ＶＰＮパスの正常性を確認する技術がある（非特許文献１参照）。本技術では、特定の計算機から送信されるＩＣＭＰ（Ｉｎｔｅｒｎｅｔ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅ Ｐｒｏｔｏｃｏｌ）パケットの送信元ＩＰアドレスをルータでチェックし、該パケットを、該計算機が利用するＶＰＮパスへ振り分け、通信先の計算機へ送信する。

柴藤政義著、"ＩＰＳｅｃで安全ネットワーク構築 −暗号化通信のススメ−",[online],HP２００２年６月２５日,発行者：毎日コミュニケーション,[検索日：２００６年１月１１日],インターネット＜URL: http://pcweb.mycom.co.jp/special/2002/ipsec/018.html＞

ネットワークサービスを提供するネットワークプロバイダが、IPネットワークにおいて、VPNパスの疎通を確認する際、通常、ユーザのネットワークの計算機からテストパケットを送信し、該パケットがVPNパスを通過するか否かに基づいて、正常性を判断する。

しかし、ユーザのネットワークからテストパケットを送信できない場合がある。即ち、ユーザのネットワークとネットワークプロバイダのネットワークが互いに独立（それぞれの管理主体が異なる）していれば、ネットワークプロバイダは、ユーザの計算機を用いることができない。このような状況下、VPNパスの疎通を確認するには、ネットワークプロバイダ管轄下のルータからテストパケットを送信する必要がある。一方、VPNパスは、ユーザのネットワークで用いられる形式の送信元アドレスを含むパケットしか通過させない。従って、ネットワークプロバイダのネットワークで用いられる形式の送信元アドレスを含むパケットはVPNパスを通過しない。

尚、ネットワークプロバイダがユーザに対してＶＰＮパスの疎通確認を依頼し、疎通を確認することも考えられる。しかし、ユーザ、計算機、及びＶＰＮパスの数が増大しているため、実際には、このような運用管理を行うことは困難である。

そこで、本発明の目的は、ユーザの設備を利用することなく、ネットワークプロバイダの装置を操作し、ＶＰＮパスの疎通確認を行う運用管理システムを提供することにある。

上記課題を解決するため、本発明の望ましい態様の一つは次の通りである。

第一のネットワークに属する第一の計算機と、第二のネットワークに属する第二の計算機と、第三のネットワークに属する第一及び第二のルータを備え、第一及び第二の計算機が、第一及び第二のルータの間に構築される論理的なパスを介して接続され、第一乃至第三のネットワークはそれぞれ接続され、第一及び第二のネットワークと、第三のネットワークが互いに独立してネットワークの運用管理を行う運用管理システムにおいて、第一のルータは、第一のネットワークで用いられるアドレスであり、かつ、第一の計算機が用いていないアドレス、又は、第二のネットワークで用いられるアドレスであり、かつ、第二の計算機が用いていないアドレスを、第一のルータの、第一のアドレスとして格納し、第一のアドレスに基づいて、第一のパケットを送信し、第一のパケットに応じた第二のパケットを受信する。

本発明によれば、ユーザの設備を利用することなく、ネットワークプロバイダの装置を操作し、ＶＰＮパスの疎通確認を行う運用管理システムを提供することができる。

以下、図面を参照して、実施形態について説明する。

図１は、運用管理システムを示す図である。

運用管理システムは、計算機を備える拠点１０１（１０１ａ〜１０１ｃ）及びVPN提供ネットワーク１０４とからなり、これらはルータ２００（２００ｇ、２００ｈ）、及びスイッチ１０６を介して接続されている。

ＶＰＮ提供ネットワーク１０４は、現用系１０５ａ及び待機系１０５ｂとからなる。通常は現用系１０５ａが用いられるが、現用系１０５ａに通信障害が発生した場合に待機系１０５ｂへ切り替える。通信障害には、ルータの障害、ルータ間の通信線路の障害、ＶＰＮパスの障害等が挙げられる。

現用系１０５ａは、ルータ２００（２００ａ〜２００ｃ）及びキャリア等が提供する共用ネットワーク１００ａとからなり、ルータ２００は他のルータ２００との間で、VPNパス１０２（１０２ａ、１０２ｂ）を構築している。待機系１０５ｂの構成も同様である。

ルータ２００ａ〜ｆはネットワークプロバイダが所有するルータであり、２００ｇとｈはユーザが所有するルータである。又、図示していないが、共用ネットワーク１００ａ（１００ｂ）内には、キャリアが所有するルータが１つ以上存在する。

ネットワーク管理装置３００ｅは、現用系１０５ａ内の共用ネットワーク１００ａと待機系１０５ｂ内の共用ネットワーク１００ｂを接続し、ＶＰＮ提供ネットワーク１０４の稼動管理、障害管理、構成管理等のネットワーク運用管理を行う。

複数の計算機３００は、ＶＰＮパス１０２を介して、接続される。尚、拠点１０１ａ、１０１ｂ、１０１ｃは同一拠点であっても、仮想的な拠点であってもよい。

拠点１０１ａに設置される業務Ａを行うサーバ３００ａは、ＶＰＮパス１０２ａ、１０２ｂを介して、拠点１０１ｃに設置される業務Ａを行うクライアント３００ｃと通信を行う。また、拠点１０１ｂに接続される業務Bを行うサーバ３００ｂは、ＶＰＮパス１０２ｅ、１０２ｆを介して拠点１０１ｃに設置される業務Bを行うクライアント３００ｄと通信を行う。そして、通信障害が発生した場合は、ＶＰＮ１０２ｃ、１０２ｄへ切り替える。１０３（１０３ａ〜１０３ｃ）は、データが流れる経路を示している。

尚、サーバが属する拠点１０１ａと１０１ｂは、ユーザの属する第一のネットワーク、クライアントが属する１０１ｃは、ユーザの属する第二のネットワークであり、ＶＰＮ提供ネットワーク１０４は、ネットワークプロバイダの第三のネットワークであり、第一のネットワーク及び第二のネットワークと、第三のネットワークは互いに独立（管理主体が別々）している。

本実施例では、ルータ２００ａ（２００ｄ）がテストパケットを生成して、ルータ２００ｂ（２００ｅ）又はルータ２００ｃ（２００ｆ）又はいずれかの計算機３００に対して送信する。テストパケットを受信したルータ又は計算機は、応答用パケットを生成して、送信元のルータに送信する。尚、ＶＰＮ提供ネットワーク１０４内のルータであれば、どのルータがテストパケットを生成、送信してもよい。

図２は、ルータ２００のハードウェア構成図である。

ルータ２００は、CPU２０１、不揮発性メモリ２０２、複数のネットワークインタフェース（以下、I/Fと略す）２０３、RＡM２０４、及びROM２０５とからなり、これらは、通信線２０６により接続される。

図３は、計算機３００のハードウェア構成図である。

計算機３００は、モニタコントローラ３０１、CPU３０２、外部記憶装置コントローラ３０３、入出力コントローラ３０４、RＡM３０５、及びI/F３０６とからなり、これらは、通信線３１１により接続される。また、モニタ３０７はモニタコントローラ３０１に、外部記憶装置３０８は外部記憶装置コントローラ３０３に、キーボード３０９及びマウス３１０は入出力コントローラ３０４に接続される。

図４は、ネットワーク管理装置３００ｅの外部記憶装置３０８内に格納されるソフトウェア構成図である。

該外部記憶装置は、ハードウェアとソフトウェアの制御や管理を行うためのOS４０１、I/F３０６の制御や他の装置と通信を行うために必要な情報を管理するための通信制御プログラム４０２、VPN提供ネットワーク１０４上に構築される物理パスやＶＰＮパスの探索を行うための探索プログラム４０３、及びデータベース（以下、DBと略す）４０５に格納される情報を利用して、パスの疎通を確認するための疎通確認プログラム４０４が格納される。CPU３０２は、これらのプログラムをRAM３０５にロードして実行することにより、処理を行う。

尚、疎通確認プログラム４０４の例として、Ｐｉｎｇ及びＴｒａｃｅｒｏｕｔｅがある。

Ｐｉｎｇは、ＩＰネットワークに接続する計算機間の疎通を診断するためのプログラムである。疎通を確認する場合、調査対象となる通信区間の計算機の一方から通信先の計算機のＩＰアドレスを指定し、ＩＣＭＰを利用してデータを送信し、通信先の計算機から返信があるか否かを確認する。返信がある場合は、計算機間の伝送時間も取得できる。

Ｔｒａｃｅｒｏｕｔｅは、計算機間に設置されるルータを通過する経路を調査するためのプログラムである。これにより、経路上にどのようなルータが設置されているかを確認できる。例えば、Ｐｉｎｇを用いて計算機間の疎通が確認できない場合に、ルータの経路情報から計算機自身やルータの設定が正しいか否かを確認できる。更に、各ルータまでの通信応答時間等の統計値も取得できるため、経路上のボトルネックも探索できる。

図５は、DB４０５に格納される情報を示す図である。

業種IDテーブル５０１には、サーバが行う業務の名称、該サーバのＩＰアドレス、及び業務を一意に識別するための業務IDがそれぞれ対応付けて格納される。業務としては、例えば、金融機関のネットワークであれば、情報系業務、勘定系業務、管理系業務等が挙げられる。

集線・拠点ルータIDテーブル５０２には、ルータが設置されるエリアのエリア名、拠点名、及びルータを一意に識別するためのルータIDがそれぞれ対応付けて格納される。二行で一組となっており、例えば、エントリ４１５が集線ルータ、エントリ４１６が該集線ルータに集約されている拠点ルータを示している。本実施例では、計算機３００ｃ、３００ｄを収容するルータを拠点ルータ（２００ｃ、２００ｆ）と、複数の拠点ルータを集約するルータを集線ルータ（２００ｂ、２００ｅ）と称する。例えば、拠点ルータは、全国の営業所（横浜営業所、川崎営業所等）に設置されるルータであり、集線ルータは、ある県内に存在する拠点ルータを集約するルータである。集線ルータには、拠点が存在しないため、図では、「＊」と記している。

サーバルータ管理テーブル５０３には、サーバに隣接するルータ（以下、サーバルータと称する）２００ａや２００ｄが利用する業務を識別するために、業務IDテーブル５０１に格納される業務IDが格納され、業務IDに対応して、系ID（現用系１０５ａである場合は０、待機系１０５ｂである場合は１）、該サーバルータの管理用ＩＰアドレス、サーバ側I/Fの物理ポートのＩＰアドレス、及び第一のネットワークで利用されていないＩＰアドレスのうち一つであるＩＰアドレス（以下、仮想ＩＰアドレスと称する）が格納される。

端末管理テーブル５０４は、拠点ルータを一意に識別するための拠点ルータID、隣接するクライアントの業務ID、及び同クライアントのＩＰアドレスが格納される。

集線・拠点ルータ管理テーブル５０５は、ルータID、系ID、管理アドレス、サーバルータが経路上に位置するネットワークに接続するI/FのＩＰアドレスと該I/Fに割り当てるサーバが属する第一のネットワークの仮想ＩＰアドレス、拠点ルータが経路上に位置するネットワークに接続するI/FのＩＰアドレス、及び該I/Fに割り当てる拠点のクライアントが属する第二のネットワークの仮想ＩＰアドレスが格納される。尚、拠点ルータがある場合は、該拠点ルータに接続されるクライアントが属するネットワークの仮想ＩＰアドレスを格納する必要はない。以上のテーブルは、ネットワークを構築する際に、DB４０５に格納される。

仮想アドレスとしては、OSI（Open Systems Interconnection）階層モデルにおける、第３層（レイヤ３）のアドレスを用いる。

図６は、パスの探索を行う際のフロー図である。CPU３０２は、ネットワーク管理装置３００ｅの起動（ネットワーク管理者の手動による起動でもよい）を契機に、処理を開始する。

CPU３０２は、まず、DB４０５への接続処理を行う（ステップ６０１）。

次に、接続したDB４０５から、情報を取得する（ステップ６０２）。ここで取得された情報は、ネットワーク管理装置３００ｅのモニタ３０７に表示される。

図７は、DBより取得された情報を表示する画面例である。

画面７０１の業務種別指定部７０２には業種IDテーブル５０１に格納される業種を、エリア指定部７０３には集線・拠点ルータIDテーブル５０２に格納されるエリア名を、拠点指定部７０４には集線・拠点ルータIDテーブル５０２に格納される拠点名を、全て表示する。

次に、設定されたパラメータに基づいて、経路の探索を行う（ステップ６０３）。尚、パラメータは、ネットワーク管理者が画面７０１を操作することにより、設定される。具体的には、業務種別指定部７０２に表示される業務から任意の業務を選択し、エリア指定部７０３に表示されるエリア名から任意のエリアを選択し、拠点指定部７０４に表示される拠点名から任意の拠点を選択し、系種別指定部７０５で現用系又は待機系のいずれかを選択する。その後、検索開始ボタンを押して、次のステップに進む。ここでは、業種種別指定部で７０２では業務Ａ７０８、エリア指定部７０３では神奈川７０９、拠点指定部７０４では川崎７１０、系種別指定部７０５では現用系を選択している。

経路の探索において、まず、業務Ａ７０８をキーとして、業種IDテーブル５０１から該当するエントリを探索し（エントリ４１３）、該エントリ４１３をキーとして、サーバルータ管理テーブル５０３から該当するエントリを検索し（エントリ４１７）、神奈川７０９と川崎７１０を検索キーとして、集線・拠点ルータIDデーブル５０２を検索し（エントリ４１５、４１６）、該エントリ４１６をキーとして端末管理テーブル５０４を検索し（エントリ４１８）、該エントリ４１５、４１６をキーとして集線・拠点ルータ管理テーブル５０５を検索（それぞれエントリ４１９、４２０）する。

そして、検索結果を画面７０７に表示する（ステップ６０４）。

図８は、図６のフローの検索結果を表示する画面例である。

画面７０７は、本例で指定して情報を満たす業務のサーバのＩＰアドレス、サーバルータの管理用ＩＰアドレス８００、サーバルータのサーバ側I/FのＩＰアドレス８０１と仮想ＩＰアドレス８０２、集線ルータの管理用ＩＰアドレス８０３とサーバルータ側I/FのＩＰアドレス８０４、仮想ＩＰアドレス８０６と拠点ルータ側I/FのＩＰアドレス８０５と仮想ＩＰアドレス８０７、拠点ルータの管理用ＩＰアドレス８０８と集線ルータ側I/FのＩＰアドレス８０９と仮想ＩＰアドレス８１１、クライアント側I/FのＩＰアドレス８１０と（格納されていれば）仮想ＩＰアドレスとからなる。

以上のように、ネットワーク管理者は、業務の種別、ルータが配置される拠点やエリアを指定することで、該サーバが利用するＶＰＮパスが構築されるルートに存在するルータを制御するために必要なネットワークに、ネットワーク管理装置３００ｅを接続できる。

次に、ネットワーク管理者は、画面７０７で表示された情報を元に、疎通確認プログラム４０４を使用して、ＩＰ通信パス、ＶＰＮパスの疎通を確認する作業に移る。

本例では、画面７０７に示すように業務Ａを行うサーバ〜クライアント間のＩＰ通信パス、及びＶＰＮパスの疎通を確認する場合を想定する。ここでは、集線ルータ２００ｂ〜拠点ルータ２００ｃ間のＶＰＮパス１０２ｂが切断されているものとする。

図９は、パスの疎通確認を行う際のフロー図である。

CPU３０２は、プログラムの起動（ネットワーク管理装置がＬｉｎｕｘ（登録商標）をベースとする計算機であれば、ターミナルプログラムｘｔｅｒｍなどの起動、Ｗｉｎｄｏｗｓ（登録商標）やＭＳ−DOＳ（Ｍｉｃｒｏｓｏｆｔ Ｄｉｓｋ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）（登録商標）であればコマンドプロンプトの実行）を契機に、処理を開始する。

CPU３０２は、まず、疎通を確認するＩＰ通信パス、又は、ＶＰＮパスの通信データをルーティングするルータへログインする（ステップ９０１）。本例では、サーバルータ２００ａの管理アドレス１０．２０．３０．２５４を指定してログインする。

次に、ログインしたルータの、サーバ側の物理ポートに割り当てられた仮想IPアドレスに基づいて、疎通確認プログラム４０４を実行する（ステップ９０２）。ここで、仮想IPアドレスの割り当ては、ネットワーク管理者が手動で行ってもよいし、仮想IPアドレス割り当て用のプログラムを別途設け、該プログラムを実行することにより行ってもよい。また、該仮想IPアドレスを送信元アドレスとして指定することは、ネットワーク管理者が手動で行ってもよいし、指定用のプログラムを別途設け、該プログラムを実行することにより行ってもよい。尚、送信元アドレスを指定せずに、疎通確認プログラム４０４を実行することもありうる。

次に、疎通確認の結果を表示する（ステップ９０３）。

図１０は、サーバルータがテストパケットを送信した場合の、疎通確認結果を表示する画面例である。（A）は、IP通信パスの疎通確認結果を示し、（B）は、VPNパスの疎通確認結果を示す。

（A）では、テストパケットの送信元ＩＰアドレスは指定されていないため、該テストパケットは、業務Ａサーバが利用するＶＰＮパスを通過することなく、サーバルータ２００ａに隣接するキャリアのルータへ転送され、更に集線ルータ、拠点ルータを経て、業務Ａクライアントへ送信されている。一方、（B）では、テストパケットの送信元ＩＰアドレスを第一のネットワークのＩＰアドレス（仮想ＩＰアドレス）としているため、送信先のＩＰアドレスを業務Ａクライアントとすれば、サーバルータは、該テストパケットが第一のネットワーク（１９２．１６８．１００．０）から送信されたものと判定し、ＶＰＮパスを通過させる。サーバルータと集線ルータは、物理的にはそれらの間に１つ以上のキャリアのルータが存在しているが、ＶＰＮパス上は隣接しており、キャリアのルータは、ＶＰＮパスが存在していることを認識していない。本例では、集線ルータ２００ｂ〜拠点ルータ２００ｃ間のＶＰＮパスが切断しているため、テストパケットは集線ルータ以降のルータへは転送されない。

（Ａ）と（Ｂ）を比較すると、（Ａ）ではテストパケットが業務Ａクライアントに到達しているのに対し、（Ｂ）ではテストパケットは集線ルータで止まっているので、ＶＰＮパスの集線ルータ〜拠点ルータ間に障害が起きていることを特定できる（障害切り分け作業）。

以上のようにルータに対してユーザが利用するネットワークのＩＰアドレスを仮想的に割り当てることによって、ＶＰＮパスの疎通を確認することができる。

運用管理システムの構成図。 ルータのハードウェア構成図。 計算機のハードウェア構成図。 ネットワーク管理装置３００ｅのソフトウェア構成図。 DB４０５の情報を示す図。 パスの探索を行う際のフロー図。 DBより取得された情報を表示する画面例。 図６のフローの検索結果を表示する画面例。 パスの疎通確認を行う際のフロー図。 疎通確認結果を表示する画面例。

符号の説明

１００・・・共用ネットワーク、１０１・・・拠点、１０２・・・VPNパス、１０３・・・データの通信路、２００・・・ルータ、３００・・・計算機

Claims (6)

1. 第一のネットワークに属する第一の計算機と、第二のネットワークに属する第二の計算機と、第三のネットワークに属する第一及び第二のルータを備え、前記第一及び第二の計算機が、前記第一及び第二のルータの間に構築される論理的なパスを介して接続され、前記第一乃至第三のネットワークはそれぞれ接続され、前記第一及び第二のネットワークと、前記第三のネットワークが互いに独立してネットワークの運用管理を行う運用管理システムにおいて、
   前記第一のルータは、前記第一のネットワークで用いられるアドレスであり、かつ、前記第一の計算機が用いていないアドレス、又は、前記第二のネットワークで用いられるアドレスであり、かつ、前記第二の計算機が用いていないアドレスを、前記第一のルータの、第一のアドレスとして格納し、
   前記第一のアドレスに基づいて、第一のパケットを送信し、
   前記第一のパケットに応じた第二のパケットを受信する、運用管理システム。
2. 前記第一のルータは、前記第一の計算機に前記第一のパケットを送信し、
   前記第一の計算機は、前記第一のパケットに応じて、前記第二のパケットを前記第一のルータに送信する、請求項１記載の運用管理システム。
3. 前記第一のルータは、前記第二のルータに前記第一のパケットを送信し、
   前記第二のルータは、前記第一のパケットに応じて、前記第二のパケットを前記第一のルータに送信する、請求項１記載の運用管理システム。
4. 前記第一のパケットは、前記論理的なパスの疎通確認用パケットであり、前記第二のパケットは、前記第一のパケットに対応した応答用パケットである、請求項１記載の運用管理システム。
5. 前記第一のルータは、更に、前記第三のネットワークで用いられるアドレスを、前記第一のルータの、第二のアドレスとして格納し、
   前記第二のアドレスに基づいて、第三のパケットを送信し、
   前記第三のパケットに応じた第四のパケットを受信する、請求項１乃至４記載の運用管理システム。
6. 前記第一のルータは、前記第二及び第四のパケットを比較し、前記論理的なパスの障害箇所を特定する、請求項５記載の運用管理システム。
   
   

Images