JP3569827B2 - Network system status diagnosis / monitoring device - Google Patents

Network system status diagnosis / monitoring device Download PDF

Info

Publication number
JP3569827B2
JP3569827B2 JP13711994A JP13711994A JP3569827B2 JP 3569827 B2 JP3569827 B2 JP 3569827B2 JP 13711994 A JP13711994 A JP 13711994A JP 13711994 A JP13711994 A JP 13711994A JP 3569827 B2 JP3569827 B2 JP 3569827B2
Authority
JP
Japan
Prior art keywords
packet
network system
monitoring
monitoring device
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.)
Expired - Fee Related
Application number
JP13711994A
Other languages
Japanese (ja)
Other versions
JPH088909A (en
Inventor
敏也 香川
啓二 大島
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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP13711994A priority Critical patent/JP3569827B2/en
Publication of JPH088909A publication Critical patent/JPH088909A/en
Application granted granted Critical
Publication of JP3569827B2 publication Critical patent/JP3569827B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Description

【産業上の利用分野】
【０００１】
本発明は、複数のコンピュータ装置が１つまたは複数のネットワークにより接続されたネットワークシステムの状態を診断・監視する装置に関する。
【従来の技術】
【０００２】
従来、ネットワークシステムを診断・監視する手段としては、システム内に設置した監視装置が、システム内の装置のそれぞれから、定周期でまたは要求することによりパケットを受信するという方式があり、正常に受信できなければ、システム内に何らかの障害が発生したと判断できる。
【０００３】
しかし、この方式の場合、障害箇所がどこにあるのかを特定できず、特定するためには別の手段が必要となる。
【０００４】
この問題を解決するために、例えば、「特表平２−５０１０１９，パケット交換ネットワークをテストする装置」「特開昭６３−１３９４４３，通信ネットワーク診断方式」「特開平４−１０３２４４，ネットワーク監視方式」においては、監視装置が経路を設定してテスト用パケットをネットワーク上に流す方法が考案されている。いずれの方法も、テスト用パケットの通信が経路上において正常になされなければ、何らかの手段により、監視装置に通知し、監視装置はそれによって障害箇所を特定できるというものである。
【発明が解決しようとする課題】
【０００５】
しかしながら、上述した従来の監視装置は、いずれも、テスト用パケットの用途を障害検知にのみ限定したものである。
【０００６】
したがって、受信装置がテスト用パケットに各種情報を書き込む手段，書き込まれた各種情報を監視装置が取得する手段，取得した情報に基づいて、ネットワークシステムの負荷状態，異常状態を検知する手段、または、検知に必要な表示をする手段，定周期のパケット送信によりシステムの状態の変化に関する診断・監視をする手段，得た結果に基づいて、操作員が臨機応変に新しいテスト用パケットを通信させる手段などについては、いずれも触れられていない。
【０００７】
本発明の目的は、テスト用パケットをより広範な情報収集に利用し、それにより、障害検知に限定されない広範囲のネットワークシステムの状態診断・監視を実現する装置を提供することである。
【課題を解決するための手段】
【０００８】
本発明は、上記目的を達成するために、複数のコンピュータ装置が１つまたは複数のネットワークにより接続されているネットワークシステムの診断・監視を目的とするテスト用パケットを前記ネットワークシステム内で通信させる通信手段と、各種の指示をする入力手段と、前記ネットワークシステムの各種状態情報および各種プログラムが格納される記憶手段と、前記ネットワークシステムの状態の診断・監視結果を示す情報を表示する表示手段と、前記通信手段によるテスト用パケットの通信結果として得られた前記ネットワークシステムの状態診断・監視に関連する情報を収集し分類して前記記憶手段に格納するとともに前記記憶手段に分類して蓄積された前記ネットワークシステムの状態診断・監視に関連する情報に基づいてネットワークの状態を診断・監視するための処理を実行しその結果を前記表示手段に出力する処理手段とを有し、前記ネットワークシステム内に少なくとも１つ設置されるネットワークシステムの状態診断・監視装置において、前記ネットワークシステム内のすべての装置，すべてのネットワークを経由するような１つの経路を示す経路情報を複数に分割し、前記分割された複数の経路を示す複数の各経路情報を対応する複数の各テスト用パケットの経路情報として設定するネットワークシステムの状態診断・監視装置を提案する。
【０００９】
前記テスト用パケットを受信した前記ネットワークシステム内の各装置は、ネットワークシステムの状態診断・監視に関連する情報を前記テスト用パケットに書き込む。
【００１０】
前記テスト用パケットに書き込む情報に、前記装置のＣＰＵ負荷，前記装置のバッファ使用率，前記装置の主従系に関する情報，テスト用パケットを前記装置が受信した時刻および送信した時刻の情報のいずれかを含むことができる。
【００１１】
前記ネットワークシステムを複数のサブシステムに分割し、前記サブシステムにはそれぞれサブ監視装置を設定し、前記サブ監視装置はそれぞれ、監視範囲内のサブシステムに関して、前記監視装置と同一のまたは縮小した機能を有することも可能である。
【００１２】
前記監視装置の表示手段には、前記ネットワークシステムの全体または一部の構成図を表示し、前記表示画面上に、前記テスト用パケットを通信させた結果得られた情報に基づいて、ネットワークシステムの負荷状態，異常状態を検知した結果の表示、または、操作員が認識するために必要な表示をする。
【作用】
【００１３】
前記手段によれば、ネットワークシステムの診断・監視を目的とする監視装置をシステム内に１つまたは複数設定し、監視装置は、システムの診断・監視を目的とするテスト用パケットをシステム内で任意の経路を設定して通信させ、その結果として得られたＣＰＵ負荷，送受信時刻などの情報を集め、それらの情報に基づいて、ネットワークシステムの負荷状態，異常状態を検知する、または、操作員が検知するために必要な表示をするようにしたので、より多くの情報に基づいてネットワークシステムを的確に診断・監視できる。
【００１４】
特に、経路をいくつかに分割して、そのそれぞれを複数のテストパケットに割り当てれば、複数のパケットで全体を診断・監視でき、要求される信頼性，冗長度，自由度に関して柔軟に対応できる。
【実施例】
【００１５】
以下、図を参照して、本発明の実施例を説明する。
【００１６】
図１は、本発明に係るネットワークシステムの状態診断・監視装置の一実施例の概要を説明した図である。
【００１７】
ここでは、対象とするネットワークシステムとして、１０１に示すネットワークＡ、１０２に示すネットワークＢ、１０３に示すネットワークＣの３つの広域ネットワークを基幹とするシステムを想定している。このようなネットワークシステムに対して、１１１で示す監視装置がシステムを診断・監視するものとする。
【００１８】
そのために、本発明では、テスト用のパケットをネットワーク上に流す。例えば、装置１１２〜１１７（装置１１２，１１４，１１６は中継装置）、およびその周辺のネットワークの生死状態，負荷状態を監視するときには、監視装置１１１から、矢印１２１〜１２７で示されるように、装置１１２〜１１７を巡回して戻ってくるパケットを送信する。
【００１９】
各装置は、パケットを受信すると、ＣＰＵ負荷など自装置に関する情報，パケットの受信，送信時刻などをパケットに書き込み、次の装置に送信すると同時に、破線矢印１３１〜１３５で示されるように、監視装置１１１にも返送する。
【００２０】
監視装置１１１は、各装置から返送されてくるパケットの情報を集め、記憶しておく。情報が集められると、監視装置では、各装置によりパケットに書き込まれたＣＰＵ負荷などの情報から、各装置の状態を検知できる。
【００２１】
また、各装置により書き込まれたパケットの受信，送信時刻から、パケットの挙動がわかり、ネットワークの負荷などの状態を推定できる。
【００２２】
さらに、パケットが正常に返送されない場合は、返送されてきた状況から、障害箇所を検知できる。テストパケットの巡回経路は任意に設定できるので、本発明によれば、ネットワークシステムの任意の箇所について、以上のように診断・監視できる。
【００２３】
監視装置１１１の具体的構成を図１５に示す。同図において、監視装置１１１は、通信装置１０と、処理装置１１と、入力装置１２と、表示装置１３と、バッファメモリ１４と、記憶装置１５とを有している。
【００２４】
通信装置１０は、ネットワークシステムの状態の診断・監視を目的とするテスト用パケットを上記ネットワークシステム内で設定された経路に送信し、また各装置と通信する。
【００２５】
入力装置１２は、表示装置１３または処理装置１１に対して各種の指示を入力する。また、バッファメモリ１４は処理措置１１により処理された各種データを一時的に蓄積し、蓄積されたデータを記憶装置１５に格納する。
【００２６】
記憶装置１５にはテスト用パケットをネットワークシステム内で設定された経路内を巡回させた結果、各装置から返送されたパケットから得られた各種状態情報および各種プログラムが格納されている。
【００２７】
処理装置１１は、通信装置１０によるテスト用パケットの通信結果として得られたネットワークシステムの状態診断・監視に関連する情報を収集し、分類してバッファメモリ１４を介して記憶装置１５に格納するとともに、記憶装置１５に分類して蓄積された上記ネットワークシステムの状態診断・監視に関連する情報に基づいてネットワークの状態を診断・監視するための処理をし、その処理結果を表示装置１３に出力する。
【００２８】
表示装置１３はネットワークシステムの状態の診断・監視結果を可視的に表示する。
【００２９】
以上の本発明のネットワークシステムの状態診断・監視装置とテスト用パケットを用いない従来の監視装置と比較してみる。
【００３０】
図２は、従来装置で、図１と同様の機能を実現しようとした場合の例である。
【００３１】
図２は、図１と同様に、監視装置１１１が装置１１２〜１１７を監視する場合を示している。ここで、監視装置１１１は、矢印２０２〜２０７で示されるように、装置１１２〜１１７のそれぞれから、定周期でまたは要求することによりパケットを受信する。パケットにはＣＰＵ負荷などの情報が書き込まれており、監視装置１１１では、図１の場合と同様に、これらの情報から各装置の状態を検知できる。
【００３２】
しかし、ネットワークの状態に関しては、パケットの通信が監視装置とその他の装置との間に限られていて、その間の経路が複数存在する場合もあるため、矢印２０２〜２０７で示されるようなパケットの挙動だけでは、ネットワークの負荷などの状態を推定することはできない。
【００３３】
また、パケットが正常に受信できなかった場合も、障害箇所がどこであるのかを特定することもできない。監視装置の下にサブの監視装置を設ければ、これらの問題点は多少改善されるが、本質的には同じ問題点が残る。
【００３４】
結局、図２の従来装置では、診断・監視のための手段が、監視装置と他装置との間の通信に限られているため、得られる情報に限界があるのに対し、本発明のネットワークシステムの状態診断・監視装置では、テストパケットを任意の経路に設定できるため、より多くの情報をシステムの診断・監視のために得られるという相違がある。
【００３５】
図３は、本発明を実施する場合の、具体的なテストパケット経路の一例を示したものである。
【００３６】
テストパケットはシステム内の装置、ネットワークを診断・監視するためのものであるから、１つのテストパケットですべてを診断・監視しようとすれば、そのパケットはシステム内のすべての装置，ネットワークを少なくとも一度は通過するような経路をとることになる。図３はそのような経路を示したものである。この経路は、パケットの書き込み領域の容量の問題やパケット消失の可能性の問題を考えれば、現実的なものとは言えないが、この経路をいくつかに分割して、そのそれぞれを複数のテストパケットに割り当てれば、複数のパケットで全体を診断・監視できるなど、応用例はいろいろ考えられる。
【００３７】
図３の例では、監視装置１１１から送信されたパケットは、まず、１０１で示すネットワークＡに接続されている各装置、ネットワークを巡回する。イーサネット３０１および装置３０２，３０３はネットワークＡに接続されていないが、ネットワークＡに接続されている装置３０４を介してのみ、システムの他の部分とつながっているので、矢印３０５，３０６，３０７に示すように、ネットワークＡの配下部分としてテストパケットは巡回する。
【００３８】
ネットワークＡに接続されている各装置，ネットワークの巡回を終了すると、テストパケットは、中継装置１１２に送信され、矢印３１１に示す経路によって、１０２に示すネットワークＢに接続されている各装置，ネットワークの巡回を開始する。装置３１２，３１３など、複数のネットワークに接続されている装置に関しては、図に示すように、接続されている各ネットワークごとにテスト用パケットの経路を設定する。装置３１４のように、ネットワークＢに２つの口を持っている装置に関しては、矢印３１５，３１６に示すように、その両方を通るようにテスト用パケットの経路を設定する。
【００３９】
ネットワークＢに接続されている各装置、ネットワークの巡回を終了すると、テストパケットは、中継装置１１４に送信され、矢印３２１に示す経路によって、１０３に示すネットワークＣに接続されている各装置，ネットワークの巡回を開始する。
【００４０】
ネットワークＡ，Ｂと同様に、ネットワークＣに接続されている各装置，ネットワークの巡回を終了すれば、テストパケットは中継装置１１６を通って監視装置１１１に戻り、システム内のすべての装置，ネットワークを少なくとも一度は通過するような経路を通った巡回を終了する。
【００４１】
以上は１つの監視装置が１つのテストパケットのみですべてを診断・監視する場合の例だが、監視装置の下に、それぞれの配下装置，ネットワークを持つサブの監視装置を設けて、それぞれのサブ監視装置が自分の配下の診断・監視をすれば、より現実的な適用に近いテスト用パケットの経路を設定できる。図４はその例を示したものである。
【００４２】
本実施例で挙げているネットワークシステムは、３つの広域ネットワークを基幹とするシステムである。そして、監視装置１１１はそのうちの１つのネットワークＡに接続されている。そこで、ネットワークＡに接続されている各装置，ネットワークは監視装置１１１の配下とし、ネットワークＢ，Ｃにそれぞれサブ監視装置を設けるものとする。ここでは、装置４０２をネットワークＢのサブ監視装置とし、装置４０３をネットワークＣのサブ監視装置とする。ネットワークＢ，Ｃに接続されている各装置，ネットワークを巡回するテストパケットの経路は、それぞれのサブ監視装置４０２、４０３が設定する。
【００４３】
このとき、監視装置１１１の持つべき機能は主に３つとなる。１つ目はネットワークＡのサブ監視装置としての機能である。２つ目はサブ監視装置がカバーできない部分、つまり、各ネットワークを接続するルートなどを診断・監視する機能である。そして、３つ目がサブ監視装置の親装置としての機能、すなわち、各サブ監視装置に指示を出して、各配下へのテストパケットを発信させ、また、その結果得られた情報を集約して、システム全体を診断・監視する機能である。１つ目の機能は、監視装置１１１がネットワークＡのサブ監視装置を兼ねているための機能なので、監視装置１１１のメイン監視装置としての機能は後者２つということになる。
【００４４】
この２つの機能を実現するために、監視装置１１１は矢印４０４〜４０９で示されるような経路を持つパケットを送信する。
【００４５】
このパケットは、１つには上記の２つ目の機能を実現するためのものである。そのために、このパケットは図１や図３で説明したものと同様のテスト用パケットであるとする。すなわち、監視装置１１１は、サブ監視装置４０２，４０３、および、中継装置１１２，１１４，１１６を経由する経路を設定して、図１や図３の実施例で使用されるテスト用パケットと同様の構造を持つテスト用パケットをネットワーク上に流し、サブ監視装置４０２，４０３、および、中継装置１１２，１１４，１１６は、パケットを受信すると、図１で説明したのと同じように、各種情報をパケットに書き込んで、次の経由装置に送信すると同時に監視装置１１１に返送する。これにより、このパケットは、サブ監視装置がカバーできない広域ネットワーク間の中継装置などを診断・監視する機能を受け持つものとなる。
【００４６】
これと同時に、このパケットに上記の３つ目の機能を持たせるために、サブ監視装置には、パケットを受信すると、自分の配下を巡回するサブのテストパケットを送信するプログラムを用意しておく。また、サブのテストパケットを送信した後、配下の各装置が返送してくるパケットを集約して、メイン監視装置１１１に送信するプログラムも用意しておく。図４で具体的に説明すれば、サブ監視装置４０２は、矢印４０５で示されるパケットを受信すると、矢印４１１〜４１８で示されるネットワークＢに接続されているすべての装置、ネットワークを巡回するテストパケットを送信する。そして、ネットワークＢに接続されている各装置がパケットを返送してくると、それらを集約してメイン監視装置１１１に送信する。サブ監視装置４０２，４０３にこのようなプログラムを追加しておけば、メイン監視装置１１１は、矢印４０４〜４０９で示される経路にパケットを送信するだけで、すべての装置、ネットワークに関する情報を集め、システム全体を診断・監視できるようになる。
【００４７】
上記の２つのプログラムを追加する点を除けば、サブ監視装置４０２，４０３が持つ機能はメイン監視装置１１１と同じである。サブ監視装置は、メイン監視装置１１１からパケットを受信したタイミングで、サブのテストパケットの送信を開始するが、予め用意しておいたパケットの経路を参照してテストパケットを作成し、１つ目の経由装置に対して送信する手順は、メインの場合と共通のものである。
【００４８】
また、各装置が返送してきたパケットを集めて記憶しておくという機能もメイン監視装置と共通であり、集まった情報をメイン監視装置に送るという点だけがメイン監視装置と異なるところである。当然、ネットワーク上に流すテストパケットも、メイン監視装置とサブ監視装置で構造として同じである。図４で言えば、矢印４０４〜４０９で示される経路で流されるパケットと、矢印４１１〜４１８で示される経路で流されるパケットとは、同じ構造を有している。
【００４９】
パケットを受信した各装置も、その送信元がメイン監視装置であるかサブ監視装置であるかにかかわりなく、同じ手順にしたがって、指定された情報をパケットに書き込み、次の装置に送信すると同時に、送信元の監視装置にパケットを返送する。
【００５０】
以上説明した方法は、サブ監視装置の下にさらにもう一層下のサブ監視装置が置かれる場合にも、適用できる。
【００５１】
また、サブ監視装置がＮ層（Ｎ：任意）の階層をなす場合にも適用できる。どの場合でも、各階層のサブ監視装置が上記の２つの機能を持ち、各階層で共通構造のテストパケットを流すという基本的な方法により、目指す機能を実現できる。
【００５２】
ここで、矢印４１１〜４１８で示される経路を巡回するテスト用パケットについて詳しく説明しておく。これは、基本的には、図３のパケットのネットワークＢに関する部分を取り出したものと考えてよいが、以後、このパケットを例として各種説明するので、ここで詳細に説明しておく。
【００５３】
サブ監視装置４０２（装置ｂ−１−１）は、矢印４０５で示される経路を介してパケットを受信したときに、予め設定してあった経路にしたがってサブテストパケットを作成し、まず、矢印４１１で示すように、１つ目の経由装置である装置４３１（装置ｂ−２−１）に送信する。
【００５４】
サブ監視装置４０２はイーサネット４２１（支線イーサｂ−１）に接続され、装置４３１はイーサネット４２２（支線イーサｂ−２）に接続されているので、矢印４１１で示されるパケットは、支線イーサｂ−１，広域ネットワークＢ，支線イーサｂ−２を経由する。
【００５５】
装置４３１（装置ｂ−２−１）は、パケットを受信すると、サブ監視装置４０２にパケットを返送すると同時に、次に、矢印４１２で示すように、２つ目の経由装置である装置４３２（装置ｂ’−１）に送信する。装置４３１はイーサネット４２３（支線イーサｂ’）にも接続され、この経路をテストパケットは通る必要があるので、パケットは支線イーサｂ’に送信される。装置４３２は支線イーサｂ’に接続されているので、矢印４１２で示されるパケットは、支線イーサｂ’のみを経由する。
【００５６】
装置４３２（装置ｂ’−１）は、パケットを受信すると、サブ監視装置４０２にパケットを返送すると同時に、次に、矢印４１３で示すように、３つ目の経由装置である装置４３３（装置ｂ’−２）に送信する。装置４３２，４３３はともにイーサネット４２３（支線イーサｂ’）に接続されているので、矢印４１３で示されるパケットは支線イーサｂ’のみを経由する。
【００５７】
装置４３３（装置ｂ’−２）は、パケットを受信すると、サブ監視装置４０２にパケットを返送すると同時に、次に、矢印４１４で示すように、四つ目の経由装置である装置４３４（装置ｂ−３−１）に送信する。装置４３３はイーサネット４２３（支線イーサｂ’）に接続され、装置４３４はイーサネット４２４（支線イーサｂ−３）に接続されているので、矢印４１４で示されるパケットは、支線イーサｂ’，広域ネットワークＢ，支線イーサｂ−３を経由する。
【００５８】
装置４３４（装置ｂ−３−１）は、パケットを受信すると、サブ監視装置４０２にパケットを返送すると同時に、次に、矢印４１５で示すように、五つ目の経由装置である装置４３５（装置ｂ−３−２）に送信する。装置４３４，４３５はともにイーサネット４２４（支線イーサｂ−３）に接続されているので、矢印４１５で示されるパケットは支線イーサｂ−３のみを経由する。
【００５９】
装置４３５（装置ｂ−３−２）は、パケットを受信すると、次に、サブ監視装置４０２にパケットを返送すると同時に、矢印４１６で示すように、六つ目の経由装置である装置４３６（装置ｂ−１−３）に送信する。装置４３５はイーサネット４２４（支線イーサｂ−３）に接続され、装置４３６はイーサネット４２１（支線イーサｂ−１）に接続されているので、矢印４１６で示されるパケットは、支線イーサｂ−３，広域ネットワークＢ，支線イーサｂ−１を経由する。
【００６０】
装置４３６（装置ｂ−１−３）は、パケットを受信すると、サブ監視装置４０２にパケットを返送すると同時に、次に、矢印４１７で示すように、７つ目の経由装置である装置４３７（装置ｂ−１−２）に送信する。装置４３６，４３７はともにイーサネット４２１（支線イーサｂ−１）に接続されているので、矢印４１７で示されるパケットは支線イーサｂ−１のみを経由する。
【００６１】
装置４３７（装置ｂ−１−２）は、パケットを受信すると、次に、矢印４１８で示すように、サブ監視装置４０２（装置ｂ−１−１）に送信する。装置４３７，４０２はともにイーサネット４２１（支線イーサｂ−１）に接続されているので、矢印４１８で示されるパケットは支線イーサｂ−１のみを経由する。
【００６２】
このようにして、テストパケットは、ネットワークＢに接続されているすべての装置、ネットワークの巡回を終了する。これにより集まった情報は、サブ監視装置４０２からメイン監視装置１１１へと送られ、システム全体の診断・監視のために用いられる。
【００６３】
図５は、図１，図３，図４で説明したテストパケットの構造の一例を示したものである。
【００６４】
パケットは、基本的には、装置番号を書き込む領域と、各装置が書き込む情報の種類を記す領域と、各装置が情報を書き込む領域とからなる。装置番号は、パケットの送信元である、メインまたはサブの監視装置が書き込むものであり、各装置がこれにしたがって、次の経由装置および送信元の監視装置の装置番号を識別し、パケットを送信する際に用いるためのものである。各装置が書き込む情報の種類は、監視装置が、各装置が書き込むべき情報の種類を指定したもので、各装置はこれにしたがってパケットに必要な情報を書き込む。各装置が情報を書き込む領域は、監視装置がパケットを送信するときには何も書き込まれておらず、パケットを受信した各装置が、指定された情報を順次書き込んでいくための領域である。
【００６５】
図５に示すパケット構造は、装置番号の領域と各装置が情報を書き込む領域とが１セットになって、固定されたバイト数分を占有し、このセットが装置数分並べられた場合の例である。パケットの先頭には、領域５０１に示すように、送信元のメインまたはサブの監視装置の装置番号を書き込み、これに続いて、領域５０２に示すように、監視装置が送信時に書き込むべき情報の種類を書き込む。そして、これに続いて、領域５０３に示すように、監視装置が送信時に指定された情報を書き込むための領域を確保する。
【００６６】
次に、同様に領域５０４，５０５に示すように、１番目の経由装置の装置番号、１番目の経由装置が書き込むべき情報の種類を書き込み、これに続いて、領域５０６に示すように、１番目の経由装置が指定された情報を書き込むための領域を確保する。以降、同様に、２番目以降の経由装置の装置番号，書き込むべき情報の種類と情報を書き込むための領域が続く。パケットの最後には、領域５０７に示すように、監視装置の装置番号を再度書き込み、領域５０８，５０９に示すように、監視装置が受信時に書き込むべき情報の種類と、監視装置が受信時に指定された情報を書き込むための領域が続く。監視装置のための領域を２つとることになるが、これは監視装置が送信時と受信時にそれぞれ情報を書き込む必要があるからである。監視装置の装置番号は、領域５０１と領域５０７で重複することになるが、各装置はこのどちらかを参照してパケットを返送するべき監視装置を識別する。
【００６７】
図５に示したテスト用パケットの構造は、先述した通り、図３の場合、図４のメイン監視装置が送信する場合、図４のサブ監視装置が送信する場合のいずれにおいても、共通のものである。図４のメイン監視装置が送信するパケットは、図３の場合と同じものであり、図４のサブ監視装置が送信するパケットも、監視装置の装置番号が異なる他は、メイン監視装置の場合と同じである。
【００６８】
次に、図４の矢印４１１〜４１８で示される経路で巡回されるテスト用パケットに図５のパケット構造を適用した場合の、具体例を説明する。まず、領域５０１，５０７には、サブ監視装置４０２（装置ｂ−１−１）の装置番号を書き込む。領域５０４には、１番目の経由装置である装置４３１（装置ｂ−２−１）の装置番号を書き込み、以下同様に、７つの経由装置の装置番号を書き込む。
【００６９】
また領域５０２には、サブ監視装置４０２がパケットを送信した時刻，そのときのＣＰＵ負荷などを変数で指定し、領域５０８には、サブ監視装置４０２がパケットを受信した時刻，そのときのＣＰＵ負荷などを指定する。
【００７０】
さらに、領域５０５には、パケットの送受信時刻，ＣＰＵ負荷のほか、バッファ使用率，多重系装置の場合の主従系に関する情報などをオプションで指定し、２番目以下の経由装置に関しても同様である。領域５０３，５０６，５０９など、９つの情報書き込み領域としては、固定されたバイト数の領域をそれぞれ割り当てる。
【００７１】
サブ監視装置４０２は、予め設定された経路，取得するべき情報の種類からこのパケットを作成し、１番目の経由装置である装置４３１に対して送信する。
【００７２】
図５で説明したのは、情報をパケットに書き込む，監視装置に返送する，次の経由装置に送信するなどの処理手順が、各装置に共通のプログラムで用意されている場合のパケットの構造である。この場合、書き込むべき情報の具体的な種類，送信する相手装置の装置番号など、監視装置が、装置別に、または、状況に応じて指定する指示情報をパケットに書き込むことになり、その場合、パケットの構造は図５のようなものとなる。
【００７３】
各装置がする処理手順そのものを、監視装置が、装置別に、または、状況に応じて指定する場合には（状況に応じて監視装置への返送をしない、通信エラー時のリトライ回数を監視装置が指定するなど）、当然、パケットにはそのための情報が追加されることになり、各装置が用意する共通のプログラムも変更したものとなる。しかし、基本的には、図５と同様の方法で実現できる。
【００７４】
図６は、各装置に共通のテストパケット受信時のアルゴリズムを説明したものである。これは、図５のパケット構造に対応したものである。サブ監視装置もメイン監視装置からテストパケットを受信するので、この共通のアルゴリズムを持つ。
【００７５】
テストパケットを受信するときには、まず、送信装置からコネクションの確立要求が来る。受信装置はこれに応じて通信をオープンする（ステップ６０１）。通信をオープンすると、次に、パケットの受信待ちに入る（ステップ６０２）。受信時にエラーが発生すると再度受信を待つ（ステップ６０３）。
【００７６】
受信が無事終了すれば、受信されたパケットより、自分が書き込むべき情報の種類を識別し、自分が情報を書き込むための領域に、まず、受信時刻を書き込む（ステップ６０４）。そして、この処理が終了してから、通信をクローズする（ステップ６０５）。ＣＰＵ負荷，バッファ使用率，多重系装置の場合の主従系情報など、そのほかの情報は、特にいつ書き込むかを限定する必要はないが、ここでは、通信をクローズした後に、パケットに書かれた指定にしたがって書き込むこととする（ステップ６０６）。
【００７７】
以上で、テストパケットの受信、および、送信時刻以外の情報書き込みは終了するので、次に、次経由装置、送信元監視装置への送信を開始する。
【００７８】
まず、次経由装置に送信する。
【００７９】
次経由装置の装置番号は、受信したパケットのなかの自装置番号の次に書かれているので、容易に識別できる。パケットが自装置を二度以上経由する場合は、パケットへの情報書き込み状況から、今回が何度目の経由であるかを判断し、それにより次経由装置の装置番号を識別する。
【００８０】
次経由装置の装置番号を識別すれば、それを送信先として設定し（ステップ６０７）、通信をオープンする（ステップ６０８）。送信の準備が整うと、パケットの指定にしたがって、最後に送信時刻をパケットに書き込んで（ステップ６０９）、送信する（ステップ６１０）。送信時にエラーが発生すれば（ステップ６１１）、送信時刻を修正して、再度送信する。送信が完了すれば、通信をクローズする（ステップ６１２）。
【００８１】
次経由装置への送信処理を完了すれば、次に送信元監視装置に送信する。
【００８２】
手順は次経由装置の場合と同様である。
【００８３】
次経由装置の場合と同様に、受信したパケットの内容から、送信元の監視装置の装置番号を識別して、これを送信先として設定し（ステップ６１３）、通信をオープンする（ステップ６１４）。送信するパケットは次経由装置に対するのと同じものとするため、パケットには何も書き込まないで、送信する（ステップ６１５）。送信時にエラーが発生すれば（ステップ６１６）、再度送信し、送信が完了すれば、通信をクローズする（ステップ６１７）。
【００８４】
一般の装置の場合は、以上で処理は終了であるが、前述したように、サブ監視装置の場合、上位の監視装置からのテストパケット受信により、配下の各装置へのテストパケット送信を開始する。そこで、自装置がサブ監視装置であるかどうか判断し（ステップ６１８）、サブ監視装置である場合は、自身の持つテストパケット送信プログラムを起動する（ステップ６１９）。
【００８５】
このようにアルゴリズムにステップ６１８、６１９を加えると、一般の装置とサブ監視装置とで、共通のアルゴリズムにより、テストパケットを受信／送信処理できる。
【００８６】
以上はテストパケットを受信する側のアルゴリズムであるが、次に、監視装置がテストパケットを送信するときのアルゴリズムを説明する。
【００８７】
図７は、メインまたはサブの監視装置がテストパケットを送信するときのアルゴリズムを説明したものである。
【００８８】
このアルゴリズムによるプログラムは、メイン監視装置の場合は、定周期でまたは監視員の要求により起動される。サブ監視装置の場合は、先述したように、メイン監視装置からテストパケットを受信したときに起動される。
【００８９】
図７においてプログラムがスタートすると、まず、予め設定された経由装置番号、装置ごとの書き込む情報の種類をファイルから読み込み（ステップ７０１）、これをもとに、図５で説明したようなテストパケットを作成する（ステップ７０２）。 パケットの送信手順は、図６で説明した一般装置の場合と同様である。まず、１番目の経由装置の装置番号を送信先として設定し（ステップ７０３）、通信をオープンする（ステップ７０４）。送信の準備が整うと、最後に、パケットの指定にしたがって、送信時刻，ＣＰＵ負荷などの情報をパケットに書き込んで（ステップ７０５）、送信する（ステップ７０６）。送信時にエラーが発生すれば（ステップ７０７）、送信時刻を修正して、再度送信する。送信が完了すれば、通信をクローズする（ステップ７０８）。
【００９０】
送信が終了すると、次に返送されてくるパケットを受信処理する。
【００９１】
返送パケットの受信処理は、テストパケットの送信後一定時間を設定して、その時間だけするものとし、その時間を超えれば、返送はされなかったものとみなして処理を終了する（ステップ７０９）。
【００９２】
設定された時間を超えない間は、各装置からのコネクションの確立要求を待つ。いずれかの装置からコネクションの確立要求が来ると、これに応じて通信をオープンし（ステップ７１０）、通信をオープンすると、次に、パケットの受信待ちに入る（ステップ７１１）。受信時にエラーが発生すると再度受信を待つ（ステップ７１２）。受信が無事終了すれば、受信されたパケットの自分が情報を書き込むための領域に、パケットの指定にしたがって、受信時刻，ＣＰＵ負荷などの情報を書き込んで、パケットを完成させ（ステップ７１３）、通信をクローズする（ステップ７１４）。
【００９３】
受信し受信時刻も書き込んだ返送パケットは、その内容をファイルに記憶しておく（ステップ７１５）。また、返送装置の装置番号は別に記憶しておく（ステップ７１６）。記憶された返送装置の装置番号一覧より、全経由装置がパケットを返送したことが判別されたときは（ステップ７１７）、受信処理は終了し、そうでない場合は、設定された一定時間を超えない間、他の装置からのコネクションの確立要求を待つ。
【００９４】
メインの監視装置の場合、一定時間を超過することにより、または、全経由装置がパケットを返送したことにより、返送パケットの受信処理が終了すれば、その時点で本アルゴリズムは終了する。しかし、サブ監視装置の場合、返送されてきたパケットの内容をメイン監視装置に送る処理が残っている。
【００９５】
この処理を実行するため、自装置がサブ監視装置の場合（ステップ７１８）、まず、返送されたパケットの内容をまとめたパケットを作成する（ステップ７１９）。返送された各パケットの内容は、最後に監視装置が受信した時刻の情報を除けば、重複したものであり、返送されてきたもののなかで最後の経由装置の返送パケットに、他のパケットが持つ情報はすべて含まれている。
【００９６】
また、テストパケットが正常に戻ってきたか、途中のどこかで通信不能となったかも、そのパケットにより判断できる。したがって、返送されてきたもののなかで最後の経由装置の返送パケットに、各装置からのパケットを監視装置が受信した時刻の情報を付加すれば、すべての情報を含んだパケットを作成できる。
【００９７】
こうして、メイン監視装置に送るためのパケットが作成できれば、後は、今までと同様に、メイン監視装置の装置番号を送信先として設定し（ステップ７２０）、通信をオープンし（ステップ７２１）、送信する（ステップ７２２）。送信時にエラーが発生すれば（ステップ７２３）、再度送信する。送信が完了すれば、通信をクローズし（ステップ７２４）、すべての処理を終了する。
【００９８】
図６と図７のアルゴリズムにより、メイン監視装置には診断・監視用の情報が集まり、ファイルに格納される。それを監視装置でどのように表示するかについて、図８以降で説明する。
【００９９】
図８は、１つのテストパケットにより得た情報を、直接的に表として表示した場合の例である。
【０１００】
この例は、図４の矢印４１１〜４１８で示されるパケットにより得た情報を表示したものであり、表の各行８０１〜８０８が、矢印４１１〜４１８で示されるパケットの各送受信に対応している。
【０１０１】
例えば、表の先頭行８０１は、図４の矢印４１１で示される経路で送信されるパケットに対応している。先述したように、矢印４１１で示されるパケットは、図４のサブ監視装置４０２（装置ｂ−１−１）が送信し、支線イーサｂ−１，広域ネットワークＢ，支線イーサｂ−２を経由して、図４の装置４３１（装置ｂ−２−１）が受信する。
【０１０２】
図７で説明したように、サブ監視装置４０２は、送信時刻，ＣＰＵ負荷をパケットに書き込み、図６で説明したように、装置４３１は、受信時刻，ＣＰＵ負荷をパケットに書き込む。サブ監視装置４０２の送信時刻と、装置４３１の受信時刻との差からは、パケットの送達時間が容易に計算できる。行８０１に表示するのは、これらの、図４の矢印４１１で示される経路で送信されるパケットに関する種々の情報である。同様に、表の各行８０２〜８０８には、矢印４１１〜４１８で示される経路で送信されるパケットの、送信装置，受信装置，それぞれのＣＰＵ負荷，通信経路，送達時間をそれぞれ表示する。監視装置の監視員は、これにより、テストパケットの挙動を直接的に見ることができる。
【０１０３】
このようにパケットの挙動の表示を見ることにより、監視員はシステムについての不審点の存在を発見できる。
【０１０４】
例えば、図８の表示の場合、まず、表の２行目８０２の送達時間がマイナスになっていることが発見できる。逆に、３行目８０３の送達時間は通常より長くなっており、この２つから、装置ｂ’−１の持っている時刻にずれがあるのではないかと推定できる。
【０１０５】
また、４行目８０４．５行目８０５，６行目８０６の送達時間も通常より長くなっているが、この３つに共通するのは支線イーサｂ−３を通過するということである。そこで、支線イーサｂ−３に負荷が高くなるなどの障害が発生し、その結果、通信に支障を来たしているのではないかと推定できる。４行目８０４，５行目８０５に示されるように、装置ｂ−３−１のＣＰＵ負荷も高くなっており、何らかの関連があるのではないかとも推定される。
【０１０６】
これらの推定が正当であるかどうかを判別するためには、過去の履歴を知ることが有効である。図９，図１０は、図８と同じパケットに関して、それぞれ、パケットの送達時間、装置のＣＰＵ負荷の過去からの変化を表として表示した場合の表示例である。ここでは、図４の矢印４１１〜４１８で示される経路で送信されるパケットを３０秒周期でネットワーク上に流し、その都度、図８のような情報を取得し、それらをファイルに格納しているものと仮定する。
【０１０７】
図９の表は、ファイルに格納している情報から、最近数分間のパケットの送達時間を取り出して作成する。各列９１１〜９１５は、それぞれ、１２０秒前，９０秒前，６０秒前，３０秒前，最新のパケット送達時間をファイルから取り出して表に表示したものであり、各行９０１〜９０８は、図８の各行８０１〜８０８に対応している。列９１５の各行の数値は、図８の表の各行の数値と同一のものである。
【０１０８】
この表より、まず、２行目９０２と３行目９０３の数値は、ほぼ一定の値のまま推移していることがわかる。２行目９０２はマイナスの値のままほぼ一定値を保っており、３行目９０３は通常より高い値のままほぼ一定値を保っている。このことから、装置ｂ’−１の持っている時刻にずれがあるのではないかという先述の推定の妥当性が裏付けられる。
【０１０９】
また、４行目９０４，５行目９０５，６行目９０６の数値は、いずれも時間とともに増加していっているのがわかる。ほぼ同一の増加率で増加していることから、３つは同じ原因で増加していると考えられ、しかも、この３行以外には、特に大きな変化は見られない。このことから、支線イーサｂ−３に発生した何らかの障害のために、通信に支障があるのではないかという先述の推定もまた、その妥当性が裏付けられ、支線イーサｂ−３の何らかの障害は、最近の１〜２分で発生したものであることもわかる。
【０１１０】
図１０は、図９と同様に、装置のＣＰＵ負荷の過去からの変化を表として表示した場合の表示例である。
【０１１１】
図１０の表は、図９と同様に、ファイルに格納している情報から、最近数分間の装置のＣＰＵ負荷を取り出して作成する。各列１０１１〜１０１５は、それぞれ、１２０秒前，９０秒前，６０秒前，３０秒前，最新の装置のＣＰＵ負荷をファイルから取り出して表に表示したものであり、各行１００１〜１００８は、図８の各行８０１〜８０８に対応している。列１０１５の各行の数値は、図８の表の各行の数値と同一のものである。
【０１１２】
図１０の表を見ると、５行目１００５の数値が時間とともに増加していっているのがわかる。この増加の仕方は、図９の４行目９０４，５行目９０５，６行目９０６とほぼ同じであり、このことから、装置ｂ−３−１の高負荷と、支線イーサｂ−３に発生した何らかの障害の間の関連性も裏付けられる。
【０１１３】
以上はテスト用パケットが正常に返送されてきた場合の例であり、この場合は、図８，図９，図１０に示すような表だけでも、システムの診断・監視をすることは困難ではない。しかし、パケットが正常に返送されなかった場合、情報が欠落するわけであるから、表だけでシステムの状態を把握することは難しい。
【０１１４】
例えば、図１１のようなケースを考える。
【０１１５】
図１１は、図９と同じ表であるが、図９とは異なる状況を想定している。ここで想定しているのは、６０秒前までは、図９の場合と同じく、正常にパケットが返送されてきているが、３０秒前と最新のパケットが、装置ｂ−３−２まで送り届けられた後、消失しているという状況である。表の６行目１１０１，７行目１１０２，８行目１１０３の情報が得られなかった部分には、図に示すように、パケットが消失したことを表示する。
【０１１６】
この表からまず推定できることは、６行目１１０１に示す経路、つまり、支線イーサｂ−３，広域ネットワークＢ，支線イーサｂ−１のどこかに障害が発生したのではないかということである。
【０１１７】
さらに、３０秒前にパケットが消失した後、支線イーサｂ−３，広域ネットワークＢ，支線イーサｂ−１の他の部分では、通信は正常であり、再び装置ｂ−１−３に送信したときにパケットが消失したという事実から、障害箇所は装置ｂ−１−３の付近ではないかと推定できる。
【０１１８】
しかし、障害が装置ｂ−１−３自身にあるのか、装置ｂ−１−３の支線イーサｂ−１側の結合部、または、支線イーサｂ−１の装置ｂ−１−３近くのどこかにあるのかは、特定できない。
【０１１９】
また、装置ｂ−１−３にはパケットが届いたが、装置ｂ−１−２と監視装置に送信したパケットの両方が消失したという可能性も、ハード構成から考えてほとんどあり得ないとは言え、否定できない。
【０１２０】
図１１と同様の別のテストパケットから得た情報を参照することにより、障害をさらに絞り込むことは可能である。装置ｂ−１−３の場合は、ネットワークＡにも接続されているので、ネットワークＡを巡回したパケットの情報を参照すればよい。その結果、もし、装置ｂ−１−３がネットワークＡ側でも異常を発生させていれば、障害は装置ｂ−１−３自身にあると判断できるし、もし、装置ｂ−１−３がネットワークＡ側では正常に通信していれば、障害は支線イーサｂ−１側のどこかにあると判断できる。
【０１２１】
しかし、図１１に示すような表を見ただけで、他にどのような情報を参照すればよいか、それらを参照した結果、どのようなことがわかるかを判断することは、実際には困難である。そこで、監視装置のディスプレイ上にシステムの構成図を表示し、その上にパケットの挙動を描くことが、機能として必要になる。
【０１２２】
図１２はその一表示例である。
【０１２３】
ここに示すのは、図４の矢印４１１〜４１８で示される経路でテストパケットを流した結果、図１１の最新時で示すような情報を得た場合の表示例である。ディスプレイ上には、図に示すように、システム全体の構成図を固定表示し、その上にテストパケットの挙動を表示する。１２０１〜１２０８の矢印が、図４の矢印４１１〜４１８で示されるテストパケットを流した結果を表示したものであり、それぞれの矢印の太さや形状がどのような結果が得られたかを表している。また、得られた結果はメッセージなどによっても表示する。
【０１２４】
図１１の１行目に示すように、図４の矢印４１１で示される経路で送信されたパケットは正常に通信されている。通信が正常であったことを表すため、矢印１２０１は細い実線で表示する。
【０１２５】
図１１の２行目に示すように、図４の矢印４１２で示される経路で送信されたパケットは送達時間がマイナス値となっており、装置ｂ’−１の持つ時刻にずれがあると考えられる。これを示すため、矢印１２０２は特殊な破線で表示し、１２１１に示すように、「時刻不一致あり？」のメッセージを表示する。また、１２１２に示すように、持っている時刻にずれがあると推定される装置ｂ’−１にそのことを示すカラーを表示する。
【０１２６】
図１１の３行目に示すように、矢印４１３で示される経路で送信されたパケットは送達時間が正常より高い値となっているが、これは装置ｂ’−１の持つ時刻のずれのためであると推定でき、通信自体は正常であると判断できる。通信が正常であったことを表すため、矢印１２０３は、矢印１２０１と同様に、細い実線で表示する。
【０１２７】
図１１の４行目，５行目に示すように、図４の矢印４１４，４１５で示される経路で送信されたパケットは送達時間が正常より高い値となっており、この原因は、支線イーサｂ−３に負荷が高くなるなどの障害が発生したためと推定できる。
【０１２８】
また、送達時間は現在増大中である。これを示すため、矢印１２０４，１２０５は太い実線またはカラー実線で表示し、１２１３に示すように、「イーサネット高負荷？ 伝送遅延発生！ 伝送遅延増大！」のメッセージを表示する。
【０１２９】
また、１２１４に示すように、負荷が高くなりつつあると推定される支線イーサｂ−３を、太線でまたはカラーで表示する。
【０１３０】
図１１の最新時で示す状況での装置の状態は、図１０の最新の場合と同じであると仮定する。図１０の５行目１００５で示すように、装置ｂ−３−１のＣＰＵ負荷は８４．４％と通常より高くなっている。また、ＣＰＵ負荷は現在増加中である。これを示すため、１２１５に示すように、装置ｂ−３−１は高負荷でしかも負荷が増加しつつあることを示す色でカラー表示する。さらに１２１６に示すように、「負荷８４．４％！ 負荷増加！」のメッセージを表示する。
【０１３１】
図１１の６行目に示すように、図４の矢印４１６で示される経路で送信されたパケットは、装置ｂ−３−２から装置ｂ−１−３への経路上で消失している可能性が高い。このことを示すため、矢印１２０６は、図に示すように、この経路上で消失したことを表すような方法で表示する。また、１２１７に示すように、「パケット未到達！」のメッセージを表示する。
【０１３２】
図１１の７行目、８行目に示すように、図４の矢印４１７，４１８で示される経路で送信されたパケットは、通信されなかった可能性が高いが、通信され消失した可能性もわずかには残っている。このため、矢印１２０７，１２０８は、細い破線で表示する。
【０１３３】
以上のように、テストパケットの結果を構成図上に表示することにより、監視員はシステムのどこにどのような異常が発生したかを容易に認識できる。
【０１３４】
また、より詳細にシステムの状態を把握するためには、次にどのような情報を参照すればよいのかも、容易に判断できる。
【０１３５】
例えば、監視員は、表示を見ながら、矢印１２０６で表示されるパケット消失の原因をより詳細に把握するにはどのようにすればよいかを判断できる。それを以下に説明する。
【０１３６】
矢印１２０６の表示で、パケットは装置ｂ−３−２から装置ｂ−１−３への経路上で消失している可能性が高いということを、監視員は知る。矢印１２０１や１２０５が正常な通信を示していることから、障害は装置ｂ−１−３の付近にあるらしいということもわかる。
【０１３７】
しかし、この表示だけでは、障害が装置ｂ−１−３自身にあるのか、装置ｂ−１−３の支線イーサｂ−１側の結合部、または、支線イーサｂ−１の装置ｂ−１−３近くのどこかにあるのかは特定できない。また、先述したように、装置ｂ−１−３にはパケットが届いたが、装置ｂ−１−２と監視装置に送信したパケットの両方が消失したという可能性も否定できない。しかし、１２１８に示すように、装置ｂ−１−３は、ネットワークＢだけでなく、ネットワークＡにも接続されていることが、ディスプレイには表示されている。この表示を見れば、監視員は、ネットワークＡのテストパケットの結果を同時にディスプレイに表示させることにより、状態をより詳細に把握できることを容易に認識できる。
【０１３８】
そこで、ネットワークＢのテストパケットの結果と同時に、ネットワークＡのテストパケットの結果も表示させた場合の表示例が、図１３に示すものである。
【０１３９】
１３０１〜１３１０の矢印が、ネットワークＡをテストパケットが巡回した結果を表示したものである。このテストパケットはすべて正常に通信されたものとし、そのことを示すため、１３０１〜１３１０の矢印はすべて細い実線で表示する。
【０１４０】
矢印１２０６および１３０７より、装置ｂ−１−３自体には異常がないことを監視員は容易に認識できる。これにより、矢印１２０６で示されるパケットは、支線イーサｂ−１側のどこかで消失したか、または、装置ｂ−１−３までは届いたが、その後に何かがあったかの、どちらかであると推定できる。
【０１４１】
しかし、このどちらであるかを判断するには、各広域ネットワークを巡回する定周期のテストパケットだけでは不十分である。このような場合、定周期のテストパケット以外に、監視員が任意のテストパケットを設定しネットワークに流す機能があれば望ましい。
【０１４２】
装置ｂ−１−３の場合、矢印１２０６で示されるパケットは装置ｂ−１−３に届いていない可能性が高いが、届いている可能性もある。もし、メイン監視装置から装置ｂ−１−３に対して直接テストパケットを送れば、この２つの可能性を１つに絞り込むことができる。なぜなら、メイン監視装置から装置ｂ−１−３にテストパケットを送ったとき、返送パケットはネットワークＡ側のイーサネットを通るので、返送パケットが消失することはないと考えられるからである。したがって、メイン監視装置から装置ｂ−１−３にテストパケットを送ってみて、返送パケットが戻ってこなければ、装置ｂ−１−３にパケットは届かなかったとほぼ断定できる。
【０１４３】
そこで、装置ｂ−１−３を経由するテストパケットをいくつか、監視員が臨時に設定して送ったとする。その場合の結果を、図８と同様に表として表示したのが図１４である。
【０１４４】
ここでは、臨時のテストパケットとして、３種類を設定している。いずれも、装置ｂ−１−３（図４の装置４３７），装置ｂ−１−２（図４の装置４３８）を経由するが、経路が異なっている。
【０１４５】
行１４０１〜１４０３に示すのが１つ目のテストパケットである。このパケットは、ネットワークＡ側のイーサネットを通って装置ｂ−１−３に行き、装置ｂ−１−３から装置ｂ−１−２へはネットワークＢ側を経由し、装置ｂ−１−２から監視装置へは再びネットワークＡ側を経由する。
【０１４６】
行１４０４〜１４０６に示すのが２つ目のテストパケットである。このパケットは、すべてネットワークＡ側を経由する。
【０１４７】
行１４０７〜１４０９に示すのが３つ目のテストパケットである。このパケットは、中継装置を通ってネットワークＢ側に入り、ネットワークＢ側のイーサネットを通って装置ｂ−１−３に行く。装置ｂ−１−３から装置ｂ−１−２へはネットワークＢ側を経由し、装置ｂ−１−２から監視装置へも再びネットワークＢ側のイーサネット、中継装置を経由する。
【０１４８】
１つ目と２つ目のテストパケットの結果は予想通りのものである。１つ目のパケットは、行１４０１に示すように、ネットワークＡ側のイーサネットを通って装置ｂ−１−３が受信するまでは正常であり、行１４０２でネットワークＢ側のイーサネットを通過したところで通信不能となっている。これは予想通りの結果である。２つ目のパケットは、ネットワークＡ側のみを経由し、通信はすべて正常である。これも予想通りの結果である。また、装置ｂ−１−３がパケットを受信すれば、正常に返送パケットが返されることも、この２つのパケットにより再確認できる。
【０１４９】
３つ目のパケットに関しても、もし装置ｂ−１−３がパケットを受信すれば、正常に返送パケットが返されるはずである。しかし、矢印１４０７に示すように、パケットは返送されていない。このことから、装置ｂ−１−３はパケットを受信しなかったことがわかる。これより、先述の２つの可能性を１つに絞ることができ、障害箇所は装置ｂ−１−３のネットワークＢ側の結合部、またはその付近のイーサネットであると判断できる。
【０１５０】
以上のように、監視員がそのとき必要とするテストパケットをその都度設定し、ネットワークに臨時に流すことにより、システムをより的確に診断・監視できる。
【０１５１】
以上、本発明を実施例に基づき具体的に説明したが、本発明は、前記実施例に限定されるものではなく、その要旨を逸脱しない範囲で種々変更し得ることは言うまでもない。
【発明の効果】
【０１５２】
本発明によれば、ネットワークシステムの診断・監視を目的とする監視装置をシステム内に１つまたは複数設定し、監視装置は、システムの診断・監視を目的とするテスト用パケットをシステム内で任意の経路を設定して通信させ、その結果として得られたＣＰＵ負荷，送受信時刻などの情報を集め、それらの情報に基づいて、ネットワークシステムの負荷状態，異常状態を検知する、または、操作員が検知するために必要な表示をするようにしたので、より多くの情報に基づきネットワークシステムをさらに的確に診断・監視できる。
【０１５３】
特に、経路をいくつかに分割して、そのそれぞれを複数のテストパケットに割り当てれば、複数のパケットで全体を診断・監視でき、要求される信頼性，冗長度，自由度に関して柔軟に対応できる。
【図面の簡単な説明】
【０１５４】
【図１】本発明に係るネットワークシステムの状態診断・監視装置の一実施例の構成を示す説明図である。
【図２】従来のネットワークシステムの状態診断・監視装置の構成を示す説明図である。
【図３】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットの経路の一設定例を示す説明図である。
【図４】本発明に係るネットワークシステムの状態診断・監視装置においてサブ監視装置を設けたときのテスト用パケットの経路の一設定例を示す説明図である。
【図５】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットのデータ構造の一例を示す説明図である。
【図６】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットを受信する装置の処理手順を示すフローチャートである。
【図７】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットを送信する監視装置の処理手順を示す説明図である。
【図８】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットを通信した結果得られた情報を表として表示した場合の表示装置の一表示例を示す説明図である。
【図９】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットを通信した結果得られた情報を表として表示した場合の表示装置の一表示例を示す説明図である。
【図１０】本発明に係るネットワークシステムの状態診断・監視装置におけるテスト用パケットを通信した結果得られた情報を表として表示した場合の表示装置の一表示例を示す説明図である。
【図１１】本発明に係るネットワークシステムの状態診断・監視装置においてネットワークシステム内に設定されたパケットの経路上でパケット未到達が発生した場合の表示装置の一表示例を示す説明図である。
【図１２】本発明に係るネットワークシステムの状態診断・監視装置においてテスト用パケットを通信した結果得られた情報を構成図上に表示した場合の表示装置の一表示例を示す説明図である。
【図１３】本発明に係るネットワークシステムの状態診断・監視装置において２つのテスト用パケットを通信した結果得られた情報を構成図上に同時に表示した場合の表示装置の一表示例を示す説明図である。
【図１４】図１３に示す表示結果に基づいて、監視員が新しいテスト用パケットの経路を設定し通信させた結果得られた情報を表として表示した場合の表示装置の一表示例を示す説明図である。
【図１５】本発明に係るネットワークシステムの状態診断・監視装置における監視装置の構成を示すブロック図である。
【符号の説明】
【０１５５】
１１１ 監視装置
１２１ テスト用パケットの経路
１２２ テスト用パケットの経路
１２３ テスト用パケットの経路
１２４ テスト用パケットの経路
１２５ テスト用パケットの経路
１２６ テスト用パケットの経路
１０１ 基幹ネットワーク
１０２ 基幹ネットワーク
１０３ 基幹ネットワーク
４０２ サブ監視装置
４０３ サブ監視装置[Industrial applications]
[0001]
The present invention relates to an apparatus for diagnosing and monitoring the status of a network system in which a plurality of computer devices are connected by one or a plurality of networks.
[Prior art]
[0002]
Conventionally, as a means for diagnosing and monitoring a network system, there is a method in which a monitoring device installed in the system receives a packet from each of the devices in the system at a fixed cycle or upon request, and a normal reception is performed. If not, it can be determined that some failure has occurred in the system.
[0003]
However, in the case of this method, it is not possible to specify where the failure point is, and another means is required to specify the failure point.
[0004]
In order to solve this problem, for example, “Tokuhyo Hei 2-501010, a device for testing a packet switching network”, “Japanese Patent Laid-Open No. 63-139443, a communication network diagnostic method”, and “Japanese Patent Application Laid-Open No. 4-103244,” In, a method has been devised in which a monitoring device sets a route and flows a test packet on a network. In either method, test packet communication is normally performed on the path.If not done,By some means to the monitoring deviceNotify,The monitoring device can thereby identify the fault location.
[Problems to be solved by the invention]
[0005]
However, in the conventional monitoring devices described above, the use of the test packet is limited only to failure detection.
[0006]
Therefore, the receiving device writes various types of information in the test packet, the monitoring device obtains the various types of written information, the load status and abnormal status of the network system are detected based on the obtained information, or Display required for detectiondoMeans, diagnosis and monitoring of changes in system status by transmitting packets at regular intervalsdoNeither means nor means for the operator to communicate a new test packet on the basis of the obtained result flexibly is mentioned.
[0007]
The object of the present invention isTo provide a device that uses a test packet to collect a wider range of information, thereby realizing a state diagnosis / monitoring of a wide range of network systems not limited to failure detection.It is.
[Means for Solving the Problems]
[0008]
In order to achieve the above object, the present invention provides a communication system in which a test packet for diagnosing and monitoring a network system in which a plurality of computer devices are connected by one or more networks is communicated in the network system. Means, input means for giving various instructions,Storage means for storing various status information and various programs of the network system; display means for displaying information indicating a result of diagnosis and monitoring of the status of the network system;Communication resultThe information related to the state diagnosis / monitoring of the network system obtained as described above is collected and classified and stored in the storage unit, and the information related to the state diagnosis / monitoring of the network system stored in the storage unit is stored. A process for diagnosing and monitoring network conditions based on informationRunProcessing means for outputting the result to the display means,SaidIn a state diagnosis / monitoring device of at least one network system installed in the network system,Path information indicating one route passing through all devices and all networks in the network system is divided into a plurality of pieces of path information, and a plurality of pieces of path information indicating the plurality of divided paths are respectively associated with a plurality of corresponding pieces of path information. Set as test packet route informationNetwork system status diagnosis / monitoring deviceSuggest.
[0009]
Each device in the network system that has received the test packet writes information related to the state diagnosis / monitoring of the network system in the test packet.
[0010]
The information to be written in the test packet may include any one of a CPU load of the device, a buffer usage rate of the device, information on a master-slave system of the device, and information on a time at which the device receives and transmits a test packet.Can be included.
[0011]
The network system is divided into a plurality of subsystems, each of which has a sub-monitoring device, wherein each of the sub-monitoring devices has the same or reduced function as the monitoring device with respect to a subsystem within a monitoring range. It is also possible to have
[0012]
The display unit of the monitoring device displays a configuration diagram of the entire network system or a part thereof, and displays the configuration of the network system on the display screen based on information obtained as a result of communicating the test packets. Displays the result of detecting the load state or abnormal state, or displays necessary for the operator to recognize.
[Action]
[0013]
According to the above means, monitoring for the purpose of diagnosing / monitoring a network systemSystem equipmentThe monitoring device sets an arbitrary route in the system to communicate a test packet for the purpose of system diagnosis / monitoring, and as a result,CPU load obtained, Collects information such as transmission / reception times, and based on the information, detects the load status and abnormal status of the network system, or displays necessary for the operator to detectdoSo that more informationOn the basis ofNetwork systemCan be accurately diagnosed and monitored.
[0014]
In particular, if the path is divided into several parts and each is assigned to a plurality of test packets, the whole can be diagnosed and monitored with a plurality of packets, and the required reliability, redundancy and flexibility can be flexibly handled. .
【Example】
[0015]
Less than,An embodiment of the present invention will be described with reference to the drawings.
[0016]
FIG. 1 is a diagram for explaining an outline of an embodiment of a state diagnosis / monitoring device for a network system according to the present invention.
[0017]
Here, as target network systems, a network A 101, a network B 102, and a network C 103ThreeA system based on a wide area network is assumed. For such a network system, a monitoring device denoted by 111Diagnose and monitorShall be.
[0018]
For this purpose, in the present invention, a test packet is sent over a network. For example, when monitoring the alive / dead state and the load state of the devices 112 to 117 (devices 112, 114, and 116 are relay devices) and the surrounding networks, the monitoring device 111 sends the devices as indicated by arrows 121 to 127. The packet which returns after circulating through 112 to 117 is transmitted.
[0019]
When each device receives a packet, it writes information about the device itself, such as the CPU load, reception and transmission times of the packet, and the like in a packet, and transmits the packet to the next device, and at the same time, as shown by the dashed arrows 131 to 135, Also returned to 111.
[0020]
The monitoring device 111 collects and stores information of packets returned from each device. When the information is collected, the monitoring device can detect the state of each device from the information such as the CPU load written in the packet by each device.
[0021]
The behavior of the packet can be known from the reception and transmission times of the packet written by each device, and the state such as the load on the network can be estimated.
[0022]
Further, if the packet is not returned normally, the location of the failure can be detected from the returned status. Since the circulating route of the test packet can be set arbitrarily, according to the present invention,Diagnosis / monitoring can be performed for any part of the network system as described above.
[0023]
FIG. 15 shows a specific configuration of the monitoring device 111. In the figure, a monitoring device 111 has a communication device 10, a processing device 11, an input device 12, a display device 13, a buffer memory 14, and a storage device 15.
[0024]
The communication device 10 transmits a test packet for diagnosing / monitoring the state of the network system to a path set in the network system, and communicates with each device.
[0025]
The input device 12 inputs various instructions to the display device 13 or the processing device 11. Further, the buffer memory 14 temporarily stores various data processed by the processing unit 11 and stores the stored data in the storage device 15.
[0026]
The storage device 15 stores various state information and various programs obtained from the packets returned from each device as a result of circulating the test packet in a route set in the network system.
[0027]
The processing device 11 transmits the test packet by the communication device 10.Communication resultThe information related to the state diagnosis / monitoring of the network system obtained as described above is collected, classified and stored in the storage device 15 via the buffer memory 14, and the network system classified and stored in the storage device 15 is stored. For diagnosing / monitoring network status based on information related to status diagnosis / monitoringDo the processing, And outputs the processing result to the display device 13.
[0028]
The display device 13 visually displays a diagnosis / monitoring result of the state of the network system.
[0029]
The network system status diagnosis / monitoring device of the present invention described above.WhenLet's compare it with a conventional monitoring device that does not use a test packet.
[0030]
FIG. 2 shows an example in which the same function as that of FIG.
[0031]
FIG.When the monitoring device 111 monitors the devices 112 to 117 as in FIG.Is shown.Here, the monitoring device 111 receives a packet from each of the devices 112 to 117 at regular intervals or upon request, as indicated by arrows 202 to 207. Information such as the CPU load is written in the packet, and the monitoring device 111 can detect the state of each device from the information as in the case of FIG.
[0032]
However, regarding the state of the network, the packet communication is limited between the monitoring device and the other devices, and there may be a plurality of routes between the monitoring device and the packet communication as shown by arrows 202 to 207. It is not possible to estimate the state such as the load of the network only by the behavior.
[0033]
Further, even when a packet cannot be received normally, it is not possible to specify the location of the failure. Providing a sub-monitoring device below the monitoring device alleviates these problems somewhat, but essentially leaves the same problems.
[0034]
After all, in the conventional device of FIG. 2, the means for diagnosis and monitoring is limited to communication between the monitoring device and another device, so that the information obtained is limited, whereas the network of the present invention is limited. The system status diagnosis / monitoring device can set a test packet to an arbitrary route, so more information can be used for system diagnosis / monitoring.ObtainedThere is a difference.
[0035]
FIG. 3 shows an example of a specific test packet path when the present invention is implemented.
[0036]
The test packet is a device in the system, a networkDiagnose and monitorAll in one test packetDiagnose and monitorIf so, the packet takes a route that passes through all devices and networks in the system at least once. FIG. 3 shows such a path. This route is not realistic given the size of the packet writing area and the possibility of packet loss. However, this route is divided into several parts, each of which is If assigned to packets, multiple packetsCan be diagnosed and monitoredVarious application examples are conceivable.
[0037]
In the example of FIG. 3, the packet transmitted from the monitoring device 111 first circulates through each device and network connected to the network A indicated by 101. The Ethernet 301 and the devices 302 and 303 are not connected to the network A, but are connected to the other parts of the system only through the device 304 connected to the network A, and thus are indicated by arrows 305, 306 and 307. Thus, the test packet circulates as a subordinate part of the network A.
[0038]
When the tour of each device and the network connected to the network A is completed, the test packet is transmitted to the relay device 112, and the test packet is transmitted to the device and the network connected to the network B indicated by 102 via the path indicated by the arrow 311. Start patrol. As shown in the figure, for a device connected to a plurality of networks, such as the devices 312 and 313, a path for a test packet is set for each connected network. For a device having two ports in the network B, such as the device 314, the path of the test packet is set so as to pass through both of them as shown by arrows 315 and 316.
[0039]
When the tour of each device and the network connected to the network B is completed, the test packet is transmitted to the relay device 114, and the test packet is transmitted to the relay device 114 via the route indicated by the arrow 321. Start patrol.
[0040]
Similarly to the networks A and B, when the tour of each device and the network connected to the network C is completed, the test packet returns to the monitoring device 111 through the relay device 116, and all the devices and the network in the system are connected. The tour through the route that passes at least once ends.
[0041]
The above is an example in which one monitoring device diagnoses and monitors all with only one test packet. However, sub monitoring devices having respective subordinate devices and networks are provided under the monitoring device, and each sub monitoring Diagnosis / monitoring of devices under their controlIf you doTest packet path closer to more realistic applicationsCan be set.FIG. 4 shows an example.
[0042]
The network system described in the present embodiment is a system based on three wide area networks. The monitoring device 111 is connected to one of the networks A. Therefore, it is assumed that the devices and networks connected to the network A are under the control of the monitoring device 111, and the sub-monitoring devices are provided in the networks B and C, respectively. Here, the device 402 is a sub monitoring device of the network B, and the device 403 is a sub monitoring device of the network C. Each of the devices connected to the networks B and C and the test packetsThe route isEach sub monitoring device 402, 403Set.
[0043]
At this time, there are mainly three functions that the monitoring apparatus 111 should have. The first is a function of the network A as a sub-monitoring device. The second is a function of diagnosing / monitoring a part that cannot be covered by the sub monitoring device, that is, a route connecting each network. The third is a function as a parent device of the sub-monitoring device, that is, an instruction is issued to each sub-monitoring device, and a test packet is transmitted to each subordinate.SendAnd the resulting information is aggregated into the entire system.Diagnose and monitorFunction. The first function is a function for the monitoring device 111 to also serve as a sub-monitoring device of the network A, and thus the monitoring device 111 has two functions as main monitoring devices.
[0044]
In order to realize these two functions, the monitoring device 111 transmits a packet having a path as indicated by arrows 404 to 409.Send
[0045]
This packet is for implementing the second function described above in part. Therefore, it is assumed that this packet is a test packet similar to that described with reference to FIGS. That is, the monitoring device 111 sets a route via the sub-monitoring devices 402 and 403 and the relay devices 112, 114 and 116, and sets the same route as the test packet used in the embodiment of FIGS. When a test packet having a structure is sent over a network, and the sub-monitoring devices 402 and 403 and the relay devices 112, 114 and 116 receive the packet, various information is transmitted to the packet in the same manner as described with reference to FIG. To the next transiting device, and at the same time, return to the monitoring device 111. This allows the sub monitoring device to cover this packet.Wide area that cannot beIt is responsible for diagnosing and monitoring relay devices between networks.
[0046]
At the same time, in order to give the third function to this packet, the sub-monitoring device prepares a program for transmitting a sub-test packet that circulates under its own control upon receiving the packet. . In addition, a program is also prepared for transmitting the sub test packet, collecting the packets returned by the respective subordinate devices, and transmitting the collected packets to the main monitoring device 111. Specifically, referring to FIG. 4, when the sub monitoring apparatus 402 receives the packet indicated by the arrow 405,Net shownAll devices connected to the work B transmit a test packet circulating through the network. Then, when each device connected to the network B returns the packets, the packets are aggregated and transmitted to the main monitoring device 111. If such a program is added to the sub-monitoring devices 402 and 403, the main monitoring device 111 collects information on all devices and networks simply by transmitting a packet to a path indicated by arrows 404 to 409. The whole systemCan be diagnosed and monitoredBecome like
[0047]
Except that the above two programs are added, the functions of the sub monitoring devices 402 and 403 are the same as those of the main monitoring device 111. The sub-monitoring device starts transmission of the sub-test packet at the timing of receiving the packet from the main monitoring device 111. The sub-monitoring device creates a test packet by referring to a previously prepared packet path, and For the transit deviceHow to sendIs the same as the main case.
[0048]
Also, the function of collecting and storing the packets returned by each device is common to the main monitoring device, and is different from the main monitoring device only in that the collected information is sent to the main monitoring device. Naturally, the structure of the test packet sent on the network is the same between the main monitoring device and the sub monitoring device. In FIG. 4, the packet transmitted on the path indicated by arrows 404 to 409 and the packet transmitted on the path indicated by arrows 411 to 418 have the same structure.
[0049]
Each device that has received the packet also writes the specified information to the packet according to the same procedure, regardless of whether the transmission source is the main monitoring device or the sub monitoring device, and transmits the packet to the next device. The packet is returned to the transmission source monitoring device.
[0050]
The method described above can be applied to a case where a sub-monitoring device is placed further below the sub-monitoring device.
[0051]
In addition, the present invention can be applied to a case where the sub-monitoring devices form an N-layer (N: arbitrary) hierarchy. In any case, the sub-monitoring device of each layer has the above two functions, and a test packet having a common structure is transmitted in each layer.ShedFunction to aim by basic methodTorealizable.
[0052]
Here, the test packet that circulates the route indicated by the arrows 411 to 418 will be described in detail. Basically, it may be considered that the portion related to the network B of the packet in FIG. 3 is extracted.To explain,Here, it will be described in detail.
[0053]
When the sub monitoring apparatus 402 (apparatus b-1-1) receives a packet via the path indicated by the arrow 405, it creates a sub test packet according to a previously set path. As shown by, the data is transmitted to the device 431 (device b-2-1) which is the first transit device.
[0054]
The sub-monitoring device 402 is connected to the Ethernet 421 (branch Ethernet b-1), and the device 431 is connected to the Ethernet 422 (branch Ethernet b-2). , The wide area network B, and the branch line ether b-2.
[0055]
Upon receiving the packet, the device 431 (device b-2-1) returns the packet to the sub monitoring device 402, and at the same time, as indicated by an arrow 412, the device 432 (device b'-1). The device 431 is also connected to the Ethernet 423 (branch ether b '), and since the test packet needs to pass through this path, the packet is transmitted to the branch ether b'. Since the device 432 is connected to the branch Ethernet b ', the packet indicated by the arrow 412 passes only through the branch Ethernet b'.
[0056]
Upon receiving the packet, the device 432 (device b′-1) returns the packet to the sub-monitoring device 402 and, at the same time, as shown by the arrow 413, the device 433 (device b Send to '-2). Since the devices 432 and 433 are both connected to the Ethernet 423 (branch Ethernet b '), the packet indicated by the arrow 413 passes only through the branch Ethernet b'.
[0057]
Upon receiving the packet, the device 433 (device b′-2) returns the packet to the sub-monitoring device 402 and, at the same time, as shown by an arrow 414, the device 434 (device b ′) -3-1). Since the device 433 is connected to the Ethernet 423 (branch Ethernet b ') and the device 434 is connected to the Ethernet 424 (branch Ethernet b-3), the packet indicated by the arrow 414 is transmitted to the branch Ethernet b' and the wide area network B. , Via branch Ethernet b-3.
[0058]
Upon receiving the packet, the device 434 (device b-3-1) returns the packet to the sub monitoring device 402, and at the same time, as indicated by an arrow 415, a device 435 (device b-3-2). Since the devices 434 and 435 are both connected to the Ethernet 424 (branch Ethernet b-3), the packet indicated by the arrow 415 passes only through the branch Ethernet b-3.
[0059]
Upon receiving the packet, the device 435 (device b-3-2) returns the packet to the sub-monitoring device 402, and at the same time, as indicated by the arrow 416, the device 436 (device b-1-3). Since the device 435 is connected to the Ethernet 424 (branch Ethernet b-3) and the device 436 is connected to the Ethernet 421 (branch Ethernet b-1), the packet indicated by the arrow 416 is transmitted to the branch Ethernet b-3 and the wide area. Via the network B and the branch ether b-1.
[0060]
Upon receiving the packet, the device 436 (device b-1-3) returns the packet to the sub-monitoring device 402 and, at the same time, as indicated by an arrow 417, the device 437 (device b-1-3) b-1-2). Since the devices 436 and 437 are both connected to the Ethernet 421 (branch Ethernet b-1), the packet indicated by the arrow 417 passes only through the branch Ethernet b-1.
[0061]
Upon receiving the packet, the device 437 (device b-1-2) transmits the packet to the sub monitoring device 402 (device b-1-1) as indicated by an arrow 418. Since the devices 437 and 402 are both connected to the Ethernet 421 (branch Ethernet b-1), the packet indicated by the arrow 418 passes only through the branch Ethernet b-1.
[0062]
In this way, the test packet ends the tour of all the devices connected to the network B and the network. The information collected by this is sent from the sub monitoring device 402 to the main monitoring device 111, and is used for diagnosis and monitoring of the entire system.
[0063]
FIG. 5 shows an example of the structure of the test packet described in FIG. 1, FIG. 3, and FIG.
[0064]
A packet basically includes an area for writing a device number, an area for writing the type of information to be written by each device, and an area for each device to write information. The device number is written by the main or sub monitoring device that is the source of the packet, and each device identifies the device number of the next transit device and the monitoring device of the transmission source according to this, and transmits the packet. It is intended to be used when performing. The type of information to be written by each device is specified by the monitoring device as to the type of information to be written by each device, and each device writes necessary information in a packet in accordance with the information. The area where each device writes information is an area in which nothing is written when the monitoring device transmits a packet, and each device that has received the packet sequentially writes the specified information.
[0065]
The packet structure shown in FIG. 5 is an example in which a device number region and a region in which each device writes information are one set, occupy a fixed number of bytes, and the set is arranged for the number of devices. It is. At the beginning of the packet, the device number of the transmission source main or sub monitoring device is written as shown in an area 501, and subsequently, as shown in an area 502, the type of information to be written by the monitoring device at the time of transmission as shown in an area 502 Write. Subsequently, as shown in an area 503, an area for the monitoring device to write the information specified at the time of transmission is secured.
[0066]
Next, similarly as shown in areas 504 and 505, the device number of the first transit device and the type of information to be written by the first transit device are written. The area for the second transit device to write the specified information is secured. Thereafter, similarly, the device numbers of the second and subsequent transit devices, the type of information to be written, and an area for writing information follow. At the end of the packet, the device number of the monitoring device is rewritten as shown in an area 507, and as shown in areas 508 and 509, the type of information to be written by the monitoring device at the time of reception and the monitoring device are specified at the time of reception Followed by an area for writing the information. The monitoring device has two areas, because the monitoring device needs to write information at the time of transmission and at the time of reception. The device number of the monitoring device overlaps in the area 501 and the area 507, and each device refers to one of them to identify the monitoring device to which the packet should be returned.
[0067]
As described above, the structure of the test packet shown in FIG. 5 is the same as that of FIG. 3 in the case of transmission by the main monitoring device of FIG. 4 and the case of transmission by the sub monitoring device of FIG. It is. The packet transmitted by the main monitoring device of FIG. 4 is the same as that of FIG. 3, and the packet transmitted by the sub-monitoring device of FIG. 4 is the same as that of the main monitoring device except that the device number of the monitoring device is different. Is the same.
[0068]
Next, a specific example in a case where the packet structure of FIG. 5 is applied to a test packet circulated on a path indicated by arrows 411 to 418 in FIG. 4 will be described. First, the device number of the sub monitoring device 402 (device b-1-1) is written in the areas 501 and 507. In the area 504, the device numbers of the device 431 (device b-2-1), which is the first transit device, are written, and similarly, the device numbers of the seven transit devices are written.
[0069]
In the area 502, the time at which the sub-monitoring device 402 transmitted the packet, the CPU load at that time, and the like are designated by variables, and in the area 508, the time at which the sub-monitoring device 402 received the packet, the CPU load at that time. Specify, for example.
[0070]
Further, in the area 505, in addition to the packet transmission / reception time and the CPU load, a buffer usage rate, information on the master-slave system in the case of a multiplex system, etc. are optionally specified, and the same applies to the second and lower transit devices. As the nine information writing areas such as the areas 503, 506, and 509, areas having a fixed number of bytes are respectively allocated.
[0071]
The sub-monitoring device 402 creates this packet from a preset route and the type of information to be acquired, and transmits the packet to the device 431 that is the first transit device.
[0072]
FIG. 5 illustrates the structure of a packet in a case where processing procedures such as writing information in a packet, returning the information to a monitoring device, and transmitting the information to a next transit device are prepared by a common program in each device. is there. In this case, the monitoring device writes instruction information, such as the specific type of information to be written and the device number of the destination device to be transmitted, for each device or according to the situation, in the packet. Is as shown in FIG.
[0073]
Each deviceDoWhen the monitoring device specifies the processing procedure for each device or according to the situation (such as not returning to the monitoring device according to the situation, or specifying the number of retries at the time of a communication error, the monitoring device). Naturally, information for that is added to the packet, and the common program prepared by each device is also changed. However, basically, it can be realized by the same method as in FIG.
[0074]
FIG. 6 shows each device.Common test packetThis explains the algorithm at the time of reception. This corresponds to the packet structure of FIG. The sub-monitoring device also receives the test packet from the main monitoring device, and thus has this common algorithm.
[0075]
When receiving a test packet, first, a request for establishing a connection comes from the transmitting device. The receiving device opens communication in response to this (step 601). When the communication is opened, the process waits for reception of a packet (step 602). If an error occurs during reception, the reception waits again (step 603).
[0076]
If the reception is successfully completed, the type of information to be written is identified from the received packet, and the reception time is first written in an area where the information is to be written (step 604). Then, after this processing is completed, the communication is closed (step 605). Other information, such as CPU load, buffer usage, master-slave information in the case of a multiplex system, does not need to be particularly limited when it is written, but here, the specification written in the packet after closing the communication (Step 606).
[0077]
As described above, the reception of the test packet and the writing of the information other than the transmission time are completed. Next, the transmission to the next transit device and the transmission source monitoring device is started.
[0078]
First, the next transit deviceSend to
[0079]
The device number of the next transit device is theLocal device number, It is easy to identify. If the packet passes through the own device more than once, it is determined from the information writing status of the packet whether this is the next pass and the device number of the next pass device is thereby identified.
[0080]
If the device number of the next transit device is identified, it is set as the transmission destination (step 607), and the communication is opened (step 608). When the preparation for transmission is completed, the transmission time is finally written in the packet according to the designation of the packet (step 609),Send(Step 610). If an error occurs during transmission (step 611), correct the transmission time,Submit again.When the transmission is completed, the communication is closed (step 612).
[0081]
If the transmission process to the next transit device is completed, then the transmission source monitoring deviceSend to
[0082]
The procedure is the same as for the next transit device.
[0083]
As in the case of the next pass-through device, the device number of the monitoring device of the transmission source is identified from the contents of the received packet, this is set as the transmission destination (step 613), and the communication is opened (step 614). Since the packet to be transmitted is the same as that for the next transit device, do not write anything in the packet,Send(Step 615). If an error occurs during transmission (step 616),Submit again,When the transmission is completed, the communication is closed (step 617).
[0084]
In the case of a general device, the process is completed as described above. However, as described above, in the case of the sub-monitoring device, transmission of a test packet to each device under the control starts by receiving a test packet from a higher-level monitoring device. . Therefore, it is determined whether or not the own device is a sub-monitoring device (step 618), and if it is a sub-monitoring device, the own test packet transmission program is started (step 619).
[0085]
Thus, steps 618 and 619 are added to the algorithm.In addition,The test packet is shared between the general device and the sub monitoring device using a common algorithm.Reception / transmission processing can be performed.
[0086]
The above is the algorithm for receiving the test packet. Next, the algorithm used when the monitoring device sends the test packetWill be described.
[0087]
FIG. 7 illustrates an algorithm when the main or sub monitoring device transmits a test packet.
[0088]
In the case of the main monitoring device, a program based on this algorithm is started at a fixed period or at the request of a monitoring person. As described above, the sub-monitoring device is activated when a test packet is received from the main monitoring device.
[0089]
When the program is started in FIG. 7, first, a preset transit device number and the type of information to be written for each device are read from a file (step 701), and a test packet as described in FIG. It is created (step 702). The packet transmission procedure is the same as that of the general device described with reference to FIG. First, the device number of the first transit device is set as the transmission destination (step 703), and communication is opened (step 704). When the preparation for transmission is completed, finally, information such as transmission time and CPU load is written in the packet according to the designation of the packet (step 705).Send(Step 706). If an error occurs during transmission (step 707), correct the transmission time,Submit again.When the transmission is completed, the communication is closed (step 708).
[0090]
When transmission is completed, the next packet returnedIs received.
[0091]
For the return packet reception processing, set a fixed time after the test packet transmission, andDoIf the time is exceeded, it is considered that no return has been made, and the process is terminated (step 709).
[0092]
As long as the time does not exceed the set time, it waits for a connection establishment request from each device. When a connection establishment request is received from any of the devices, communication is opened in response to the request (step 710). When the communication is opened, the process waits for packet reception (step 711). If an error occurs during reception, the reception waits again (step 712). If reception is completed successfully,Packet selfWrites the information such as the reception time and the CPU load according to the designation of the packet in the area for writing the information, completes the packet (step 713), and closes the communication (step 714).
[0093]
The contents of the return packet in which the reception and the reception time are also written are stored in a file (step 715). Also, the device number of the return device is stored separately (step 716). When it is determined from the stored list of device numbers of the returning devices that all the transit devices have returned the packet (step 717), the receiving process ends, otherwise, the set time is not exceeded. During this time, it waits for a connection establishment request from another device.
[0094]
In the case of the main monitoring device, if the process of receiving the returned packet is completed due to a certain period of time being exceeded or all the transit devices returning the packet, the present algorithm ends at that point. However, in the case of the sub-monitoring device, there remains processing for transmitting the contents of the returned packet to the main monitoring device.
[0095]
In order to execute this processing, if the own apparatus is a sub monitoring apparatus (step 718), first, a packet that summarizes the contents of the returned packet is created (step 719). The content of each returned packet is a duplicate except for the information on the time when the monitoring device last received the packet, and other packets are included in the returned packet of the last transit device among the returned packets. All information is included.
[0096]
Whether the test packet has returned to normal or communication has been disabled somewhere along the way can be determined from the packet. Therefore, if information on the time when the monitoring device receives the packet from each device is added to the return packet of the last transit device among the returned packets, a packet including all the information can be created.
[0097]
If a packet to be sent to the main monitoring device can be created in this way, the device number of the main monitoring device is set as a transmission destination (step 720) and communication is opened (step 721), as before.Send(Step 722). If an error occurs during transmission (step 723),Send.When the transmission is completed, the communication is closed (step 724), and all the processing ends.
[0098]
According to the algorithm of FIGS. 6 and 7, information for diagnosis and monitoring is collected in the main monitoring device and stored in a file. How it is displayed on the monitoring device will be described with reference to FIG.
[0099]
FIG. 8 shows an example in which information obtained by one test packet is directly displayed as a table.
[0100]
In this example, information obtained by the packets indicated by arrows 411 to 418 in FIG. 4 is displayed, and each row 801 to 808 of the table corresponds to each transmission and reception of the packets indicated by arrows 411 to 418. .
[0101]
For example, the first row 801 of the table corresponds to a packet transmitted along a path indicated by an arrow 411 in FIG. As described above, the packet indicated by the arrow 411 is transmitted by the sub-monitoring device 402 (device b-1-1) in FIG. 4 and passes through the branch Ethernet b-1, the wide area network B, and the branch Ethernet b-2. Then, the device 431 (device b-2-1) of FIG.
[0102]
As described in FIG. 7, the sub-monitoring device 402 writes the transmission time and the CPU load in the packet, and as described in FIG. 6, the device 431 writes the reception time and the CPU load in the packet. The packet delivery time can be easily calculated from the difference between the transmission time of the sub monitoring device 402 and the reception time of the device 431. Displayed in the row 801 are various pieces of information regarding the packet transmitted through the path indicated by the arrow 411 in FIG. Similarly, each row 802 to 808 of the table includes a transmitting device, a receiving device, respective CPU loads, a communication route, and a delivery route of a packet transmitted through a route indicated by arrows 411 to 418.Time eachindicate. The monitor of the monitoring device can thereby directly see the behavior of the test packet.
[0103]
By watching the display of the behavior of the packet in this way, the observer can discover the existence of a suspicious point in the system.
[0104]
For example, in the case of the display of FIG. 8, first, it can be found that the delivery time of the second row 802 of the table is negative. Conversely, the delivery time of the third line 803 is longer than usual, and it can be estimated from these two that the time held by the device b'-1 may be shifted.
[0105]
The delivery time of the fourth line 804.5, the second line 805, and the sixth line 806 is also longer than usual, but it is common for all three to pass through the branch line ether b-3. Therefore, it can be estimated that a failure such as an increase in the load on the branch line ether b-3 occurs, and as a result, communication is hindered. As shown in the fourth line 804 and the fifth line 805, the CPU load of the device b-3-1 is also high, and it is presumed that there is some relationship.
[0106]
In order to determine whether these estimates are valid, it is effective to know past histories. 9 and 10 show the same packet as in FIG. 8, respectively, the packet delivery time and the CPU of the device.Load pastfromTable of changeIt is a display example when it is displayed as. Here, packets transmitted on the routes indicated by arrows 411 to 418 in FIG. 4 are transmitted on the network at a cycle of 30 seconds, and each time information as shown in FIG. 8 is acquired and stored in a file. Suppose
[0107]
The table in FIG. 9 is created by extracting the packet delivery time in the last few minutes from the information stored in the file. Columns 911 to 915 are obtained by extracting the latest packet delivery time from the file 120 seconds ago, 90 seconds ago, 60 seconds ago, 30 seconds ago and the latest packet delivery time, respectively, and displaying them in a table. 8 correspond to the respective rows 801 to 808. The values in each row of column 915 are the same as the values in each row of the table in FIG.
[0108]
From this table, it can be seen that the numerical values in the second row 902 and the third row 903 have remained almost constant. The second line 902 keeps a substantially constant value with a negative value, and the third line 903 keeps a substantially constant value with a higher value than usual. From this, it may be that the time held by the device b'-1 is shifted.Said earlierThe validity of the estimation is supported.
[0109]
Also, it can be seen that the numerical values of the fourth line 904, the fifth line 905, and the sixth line 906 all increase with time. Since the increase is at almost the same rate, it is considered that the increase is due to the same cause, and no significant change is observed except for these three rows. For this reason, due to some kind of failure occurring in the branch Ethernet b-3, the communicationAs mentioned earlier, there may be a problem.The estimation is also supported by its validity, and it can be seen that any failure of the branch Ethernet b-3 has occurred in the last 1-2 minutes.
[0110]
FIG. 10 shows the CPU of the apparatus as in FIG.Table of changes in load from the pastIt is a display example when it is displayed.
[0111]
The table of FIG. 10 is created by extracting the CPU load of the device for the last few minutes from the information stored in the file, similarly to FIG. The columns 1011 to 1015 are obtained by extracting the CPU load of the latest device 120 seconds ago, 90 seconds ago, 60 seconds ago, 30 seconds ago, and the latest device from the file and displaying them in a table. This corresponds to each row 801 to 808 in FIG. The values in each row of column 1015 are the same as the values in each row of the table in FIG.
[0112]
Looking at the table of FIG. 10, it can be seen that the value of the fifth row 1005 increases with time. The way of this increase is almost the same as the fourth line 904, the fifth line 905, and the sixth line 906 in FIG. 9. From this, the high load on the device b-3-1 and the branch Ethernet b-3 can be added. The association between any failures that occur is also supported.
[0113]
The above is an example of a case where the test packet is normally returned. In this case, the diagnosis and monitoring of the system can be performed using only the tables shown in FIGS. 8, 9, and 10.doIt is not difficult. However, if the packet is not returned normally, information is lost, so it is difficult to grasp the state of the system only from the table.
[0114]
For example, consider the case shown in FIG.
[0115]
FIG. 11 is the same table as FIG. 9, but assumes a situation different from FIG. It is assumed here that the packet has been returned normally up to 60 seconds before, as in the case of FIG. 9, but the latest packet 30 seconds ago is sent to the device b-3-2. Disappeared after being killedSituationIt is. 6th row 1101, 7th row 1102, 8th rowInformation of 1103Where the packet was lost, as shown in the figure,indicate.
[0116]
The first thing that can be estimated from this table is that a failure may have occurred in the route shown in the sixth row 1101, that is, somewhere in the branch Ethernet b-3, the wide area network B, and the branch Ethernet b-1.
[0117]
Further, after the packet is lost 30 seconds ago, the communication is normal in the branch Ethernet b-3, the wide area network B, and the other parts of the branch Ethernet b-1, and the packet is transmitted to the device b-1-3 again. From the fact that the packet has been lost, it can be estimated that the failure location is near the device b-1-3.
[0118]
However, whether the failure is in the device b-1-3 itself, the coupling portion of the device b-1-3 on the branch Ethernet b-1 side, or somewhere near the device b-1-3 of the branch Ethernet b-1 Cannot be identified.
[0119]
Also, although the packet arrives at the device b-1-3, there is almost no possibility that both the device b-1-2 and the packet transmitted to the monitoring device have been lost due to the hardware configuration. I can't deny it.
[0120]
FIG. 11 andAnother similarBy referring to the information obtained from the test packet, it is possible to further narrow down the fault. In the case of the device b-1-3, since it is also connected to the network A, it is only necessary to refer to the information of the packet circulating in the network A. As a result, if the device b-1-3 has also caused an abnormality on the network A side, it can be determined that the fault exists in the device b-1-3 itself. On the A sideIf you are communicating normally,The fault can be determined to be somewhere on the branch line ether b-1 side.
[0121]
However, just by looking at the table as shown in FIG. 11, it is actually a matter of determining what information to refer to and what to find out as a result of referring to them. Have difficulty. Therefore, it is necessary as a function to display a system configuration diagram on the display of the monitoring device and draw the behavior of the packet thereon.
[0122]
FIG. 12 shows an example of the display.
[0123]
Shown here is an example of display in the case where information as shown at the latest time in FIG. 11 is obtained as a result of flowing a test packet along a path indicated by arrows 411 to 418 in FIG. As shown in the figure, the configuration of the entire system is fixedly displayed on the display, and the behavior of the test packet is displayed thereon. Arrows 1201 to 1208 indicate the results of flowing the test packets indicated by arrows 411 to 418 in FIG. 4, and the thickness and shape of each arrow indicate what result was obtained. . The obtained result is also displayed by a message or the like.
[0124]
As shown in the first row of FIG. 11, the packet transmitted through the path indicated by the arrow 411 in FIG. 4 is normally communicated. The arrow 1201 is displayed as a thin solid line to indicate that the communication was normal.
[0125]
As shown in the second row of FIG. 11, the packet transmitted through the route indicated by the arrow 412 in FIG. 4 has a negative delivery time, and the time held by the device b′-1 is considered to be shifted. Can be In order to indicate this, the arrow 1202 is displayed by a special broken line, and as shown by 1211, a message of “time mismatch” is displayed. Also, as indicated by 1212, the fact is indicated to the device b'-1 which is presumed to have a time lag.Display color.
[0126]
As shown in the third row of FIG. 11, the delivery time of the packet transmitted through the route indicated by the arrow 413 is higher than normal, but this is due to the time lag of the device b′-1. And it can be determined that the communication itself is normal. The arrow 1203 is displayed as a thin solid line like the arrow 1201 to indicate that the communication was normal.
[0127]
As shown in the fourth and fifth lines in FIG. 11, the packet transmitted through the route indicated by the arrows 414 and 415 in FIG. 4 has a delivery time higher than the normal value. It can be estimated that a failure such as an increase in load has occurred in b-3.
[0128]
Also, delivery times are currently increasing. To indicate this, arrows 1204 and 1205 are displayed as thick solid lines or colored solid lines, and as indicated by reference numeral 1213, a message “Ethernet high load? Transmission delay occurred! Transmission delay increased!” Is displayed.
[0129]
Further, as indicated by reference numeral 1214, the branch line ether b-3, which is estimated to be increasing in load, is displayed in a thick line or in color.
[0130]
It is assumed that the state of the device in the situation shown at the latest in FIG. 11 is the same as the latest case in FIG. As shown by the fifth line 1005 in FIG. 10, the CPU load of the device b-3-1 is 84.4%, which is higher than usual. Also, the CPU load is currently increasing. To indicate this, as indicated by 1215, the device b-3-1 performs color display with a color indicating that the load is high and the load is increasing. Further, as shown at 1216, a message “load 84.4%! Load increase!” Is displayed.
[0131]
As shown in the sixth row in FIG. 11, the packet transmitted on the path indicated by the arrow 416 in FIG. 4 may be lost on the path from the device b-3-2 to the device b-1-3. High. To indicate this, the arrow 1206 is displayed in such a way as to indicate that it has disappeared on this route, as shown in the figure. Also, as indicated by reference numeral 1217, a message "Packet not reached!" Is displayed.
[0132]
7 in FIG.LineAs shown in the eighth line, the packet transmitted along the path indicated by arrows 417 and 418 in FIG.Not communicatedThere is a high probability, but there is a slight possibility that it was lost due to communication. For this reason, the arrows 1207 and 1208 are indicated by thin broken lines.
[0133]
As described above, by displaying the result of the test packet on the configuration diagram, the supervisor can easily recognize where and what abnormality has occurred in the system.
[0134]
Further, in order to grasp the state of the system in more detail, it is easy to determine what information to refer to next.
[0135]
For example,The watchman, looking at the display,It is possible to determine how to understand the cause of the packet loss indicated by the arrow 1206 in more detail. It is described below.
[0136]
From the display of the arrow 1206, the observer knows that there is a high possibility that the packet has been lost on the path from the device b-3-2 to the device b-1-3. Since the arrows 1201 and 1205 indicate normal communication, it can be understood that the failure is likely to be near the device b-1-3.
[0137]
However, this display alone indicates whether the failure is in the device b-1-3 itself, the connection portion on the branch line ether b-1 side of the device b-1-3, or the device b-1- 3 It is not possible to specify whether it is somewhere near. Further, as described above, although the packet has arrived at the device b-1-3, it cannot be denied that both the device b-1-2 and the packet transmitted to the monitoring device have been lost. However, as indicated by 1218, the display indicates that the device b-1-3 is connected not only to the network B but also to the network A. By watching this display, the monitor can grasp the state in more detail by simultaneously displaying the result of the test packet of the network A on the display.It can be easily recognized.
[0138]
FIG. 13 shows a display example in which the result of the test packet of the network A is displayed at the same time as the result of the test packet of the network B.
[0139]
Arrows 1301 to 1310 indicate the results of the test packet circulating in the network A. All of the test packets are assumed to have been normally communicated, and all the arrows 1301 to 1310 are indicated by thin solid lines to indicate that.
[0140]
From the arrows 1206 and 1307, there is no abnormality in the device b-1-3 itself.The observer can easily recognize that.As a result, the packet indicated by the arrow 1206 has been lost somewhere on the branch Ethernet b-1 side, or has arrived at the device b-1-3, but there has been something after that. It can be estimated that there is.
[0141]
However, it is not enough to determine which one is the test packet having a fixed period that circulates through each wide area network. In such a case, it is desirable that the monitor has a function of setting an arbitrary test packet and sending it to the network in addition to the test packet having a fixed period.
[0142]
In the case of the device b-1-3, it is highly likely that the packet indicated by the arrow 1206 has not reached the device b-1-3, but it may have. If a test packet is sent directly from the main monitoring device to the device b-1-3, these two possibilities can be narrowed down to one. This is because, when a test packet is sent from the main monitoring device to the device b-1-3, the return packet passes through the Ethernet on the network A side, so it is considered that the return packet will not be lost. Therefore, a test packet is sent from the main monitoring device to the device b-1-3, and if the return packet does not return, it can be almost determined that the packet has not reached the device b-1-3.
[0143]
Therefore, it is assumed that the monitoring staff has set and sent some test packets passing through the device b-1-3. FIG. 14 shows the result in that case as a table similarly to FIG.
[0144]
Here, three types of temporary test packets are set. In each case, the route passes through the device b-1-3 (the device 437 in FIG. 4) and the device b-1-2 (the device 438 in FIG. 4), but the routes are different.
[0145]
Rows 1401 to 1403 show a first test packet. This packet goes to the device b-1-3 through the Ethernet on the network A side, from the device b-1-3 to the device b-1-2 via the network B side, and from the device b-1-2. The monitoring device passes through the network A again.
[0146]
Rows 1404 to 1406 show a second test packet. All of these packets pass through the network A.
[0147]
Rows 1407 to 1409 show a third test packet. This packet enters the network B side through the relay device, and goes to the device b-1-3 through the Ethernet on the network B side. The device b- 1-3 goes to the device b- 1-2 via the network B, and the device b- 1-2 goes to the monitoring device again via the Ethernet on the network B and the relay device.
[0148]
The results of the first and second test packets are as expected. The first packet is normal until it is received by the device b-1-3 through the Ethernet on the network A, as shown in the row 1401, and communicates when it passes through the Ethernet on the network B in the row 1402. It is impossible. This is the expected result. The second packet passes only through the network A, and all communications are normal. This is also the expected result. Also, if the device b-1-3 receives the packet, it can be confirmed again by these two packets that the return packet is normally returned.
[0149]
Regarding the third packet, if the device b-1-3 receives the packet, the return packet should be returned normally. However, as indicated by arrow 1407, the packet has not been returned. This indicates that the device b-1-3 did not receive the packet. As a result, the two possibilities described above can be reduced to one, and it can be determined that the failure location is the connection part on the network B side of the device b-1-3 or the Ethernet in the vicinity thereof.
[0150]
As described above, the monitor can set the test packet required at that time each time and temporarily send it to the network, so that the system can be diagnosed and monitored more accurately.
[0151]
As described above, the present invention has been specifically described based on the embodiments. However, it is needless to say that the present invention is not limited to the above-described embodiments and can be variously changed without departing from the gist of the present invention.
【The invention's effect】
[0152]
According to the present invention,For diagnosis and monitoring of network systemsMonitoring systemThe monitoring device sets an arbitrary route in the system to communicate a test packet for the purpose of system diagnosis / monitoring, and as a result,Obtained CPUCollects information such as load and transmission / reception time, and based on such information, detects the load status or abnormal status of the network system, or displays the information necessary for the operator to detect it.DoAs a result, the network system can be more accurately diagnosed and monitored based on more information.
[0153]
In particular, if the path is divided into several parts and each is assigned to a plurality of test packets, the whole can be diagnosed and monitored with a plurality of packets, and the required reliability, redundancy and flexibility can be flexibly handled. .
[Brief description of the drawings]
[0154]
FIG. 1 is an explanatory diagram showing a configuration of an embodiment of a state diagnosis / monitoring device for a network system according to the present invention.
FIG. 2 is an explanatory diagram showing a configuration of a state diagnosis / monitoring device of a conventional network system.
FIG. 3 is an explanatory diagram showing one setting example of a path of a test packet in the state diagnosis / monitoring device of the network system according to the present invention.
FIG. 4 is a diagram illustrating a state diagnosis / monitoring device of a network system according to the present invention, in which a sub monitoring device is provided;For testing whenFIG. 9 is an explanatory diagram illustrating an example of setting a packet path;
FIG. 5 is an explanatory diagram showing an example of a data structure of a test packet in the state diagnosis / monitoring device of the network system according to the present invention.
FIG. 6 is a flowchart showing a processing procedure of an apparatus for receiving a test packet in the state diagnosis / monitoring apparatus of the network system according to the present invention.
FIG. 7 is an explanatory diagram showing a processing procedure of a monitoring device that transmits a test packet in the state diagnosis / monitoring device of the network system according to the present invention.
FIG. 8 communicates a test packet in the state diagnosis / monitoring device of the network system according to the present invention.Result obtainedFIG. 10 is an explanatory diagram illustrating a display example of a display device when information is displayed as a table.
FIG. 9 communicates a test packet in the network system state diagnosis / monitoring device according to the present invention.Result obtainedFIG. 10 is an explanatory diagram illustrating a display example of a display device when information is displayed as a table.
FIG. 10 communicates a test packet in the network system state diagnosis / monitoring device according to the present invention.Result obtainedFIG. 10 is an explanatory diagram illustrating a display example of a display device when information is displayed as a table.
FIG. 11 is an explanatory diagram showing a display example of a display device when a packet has not arrived on a packet route set in the network system in the network system status diagnosis / monitoring device according to the present invention.
FIG. 12 shows a communication of a test packet in the state diagnosis / monitoring device of the network system according to the present invention.Result obtainedFIG. 9 is an explanatory diagram illustrating a display example of a display device when information is displayed on a configuration diagram.
FIG. 13 communicates two test packets in the state diagnosis / monitoring device of the network system according to the present invention.Result obtainedFIG. 11 is an explanatory diagram illustrating a display example of a display device when information is simultaneously displayed on a configuration diagram.
FIG. 14 is a diagram illustrating a display example of a display device in a case where information obtained as a result of setting and communicating a new test packet path by a supervisor based on the display result illustrated in FIG. 13 is displayed as a table; FIG.
FIG. 15 is a block diagram showing a configuration of a monitoring device in the network system status diagnosis / monitoring device according to the present invention.
[Explanation of symbols]
[0155]
111 Monitoring device
121 Route of test packet
122 Test packet path
123 Test packet path
124 Test packet path
125 Test packet path
126 Test packet path
101 Core Network
102 Backbone Network
103 Backbone Network
402 Sub monitoring device
403 Sub monitoring device

Claims (5)

複数のコンピュータ装置が１つまたは複数のネットワークにより接続されているネットワークシステムの診断・監視を目的とするテスト用パケットを前記ネットワークシステム内で通信させる通信手段と、各種の指示をする入力手段と、前記ネットワークシステムの各種状態情報および各種プログラムが格納される記憶手段と、前記ネットワークシステムの状態の診断・監視結果を示す情報を表示する表示手段と、前記通信手段によるテスト用パケットの通信結果として得られた前記ネットワークシステムの状態診断・監視に関連する情報を収集し分類して前記記憶手段に格納するとともに前記記憶手段に分類して蓄積された前記ネットワークシステムの状態診断・監視に関連する情報に基づいてネットワークの状態を診断・監視するための処理を実行しその結果を前記表示手段に出力する処理手段とを有し、前記ネットワークシステム内に少なくとも１つ設置されるネットワークシステムの状態診断・監視装置において、
前記ネットワークシステム内のすべての装置，すべてのネットワークを経由するような１つの経路を示す経路情報を複数に分割し、前記分割された複数の経路を示す複数の各経路情報を対応する複数の各テスト用パケットの経路情報として設定することを特徴とするネットワークシステムの状態診断・監視装置。 Communication means for communicating within the network system a test packet for diagnosing / monitoring a network system in which a plurality of computer devices are connected by one or more networks; input means for giving various instructions; Storage means for storing various status information and various programs of the network system; display means for displaying information indicating a diagnosis / monitoring result of the status of the network system; and communication means for obtaining communication results of test packets by the communication means. The information related to the state diagnosis / monitoring of the network system is collected and classified and stored in the storage unit, and the information related to the state diagnosis / monitoring of the network system is classified and stored in the storage unit. To diagnose and monitor network conditions based on And a processing means for outputting the running sense result to said display means, in the state diagnosis and monitoring devices of the network system that is at least one installed in the network system,
Path information indicating one route passing through all devices and all networks in the network system is divided into a plurality of pieces of path information, and a plurality of pieces of path information indicating the plurality of divided paths are respectively associated with a plurality of corresponding pieces of path information. A state diagnosis / monitoring device for a network system, which is set as path information of a test packet . 請求項１に記載のネットワークシステムの状態診断・監視装置において、
前記テスト用パケットを受信した前記ネットワークシステム内の各装置は、ネットワークシステムの状態診断・監視に関連する情報を前記テスト用パケットに書き込むことを特徴とするネットワークシステムの状態診断・監視装置。 The state diagnosis / monitoring device for a network system according to claim 1,
Each device in the network system that has received the test packet writes information related to the network system status diagnosis / monitoring into the test packet. 請求項１または２に記載のネットワークシステムの状態診断・監視装置において、
前記テスト用パケットに書き込む情報に、前記装置のＣＰＵ負荷，前記装置のバッファ使用率，前記装置の主従系に関する情報，テスト用パケットを前記装置が受信した時刻および送信した時刻の情報のいずれかを含むことを特徴とするネットワークシステムの状態診断・監視装置。 The state diagnosis / monitoring device for a network system according to claim 1 or 2,
The information to be written in the test packet may include any one of a CPU load of the device, a buffer usage rate of the device, information on a master-slave system of the device, and information on a time at which the device receives and transmits a test packet. A condition diagnosis / monitoring device for a network system, comprising: 請求項１ないし３のいずれか一項に記載のネットワークシステムの状態診断・監視装置において、
前記ネットワークシステムを複数のサブシステムに分割し、前記サブシステムにはそれぞれサブ監視装置を設定し、前記サブ監視装置はそれぞれ、監視範囲内のサブシステムに関して、前記監視装置と同一のまたは縮小した機能を有することを特徴とするネットワークシステムの状態診断・監視装置。 The state diagnosis / monitoring device for a network system according to any one of claims 1 to 3,
The network system is divided into a plurality of subsystems, each of which has a sub-monitoring device, wherein each of the sub-monitoring devices has the same or reduced function as the monitoring device with respect to a subsystem within a monitoring range. condition diagnosis and monitoring devices of the network system characterized by having. 請求項１ないし４のいずれか一項に記載のネットワークシステムの状態診断・監視装置において、
前記監視装置の表示手段には、前記ネットワークシステムの全体または一部の構成図を表示し、前記表示画面上に、前記テスト用パケットを通信させた結果得られた情報に基づいて、ネットワークシステムの負荷状態，異常状態を検知した結果の表示、または、操作員が認識するために必要な表示をすることを特徴とするネットワークシステムの状態診断・監視装置。 The state diagnosis / monitoring device for a network system according to any one of claims 1 to 4,
The display unit of the monitoring device displays a configuration diagram of the entire network system or a part thereof, and displays the configuration of the network system on the display screen based on information obtained as a result of communicating the test packets. A state diagnosis / monitoring device for a network system, which displays a result of detecting a load state or an abnormal state or a display necessary for an operator to recognize the state.
JP13711994A 1994-06-20 1994-06-20 Network system status diagnosis / monitoring device Expired - Fee Related JP3569827B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP13711994A JP3569827B2 (en) 1994-06-20 1994-06-20 Network system status diagnosis / monitoring device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP13711994A JP3569827B2 (en) 1994-06-20 1994-06-20 Network system status diagnosis / monitoring device

Publications (2)

Publication Number Publication Date
JPH088909A JPH088909A (en) 1996-01-12
JP3569827B2 true JP3569827B2 (en) 2004-09-29

Family

ID=15191274

Family Applications (1)

Application Number Title Priority Date Filing Date
JP13711994A Expired - Fee Related JP3569827B2 (en) 1994-06-20 1994-06-20 Network system status diagnosis / monitoring device

Country Status (1)

Country Link
JP (1) JP3569827B2 (en)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60041732D1 (en) 1999-01-27 2009-04-23 Hitachi Ltd Method, device and storage medium for use in a hierarchical system
JP2003140737A (en) * 2001-10-30 2003-05-16 Fujitsu Ten Ltd Support system
WO2003103220A1 (en) * 2002-05-31 2003-12-11 富士通株式会社 Monitoring system of monitoring network
FR2847406B1 (en) * 2002-11-20 2005-01-14 Cegetel METHOD AND MODULAR DEVICE FOR TRACING A MULTIMEDIA MESSAGE THROUGH A TELECOMMUNICATIONS NETWORK
DE102004001323B3 (en) * 2004-01-08 2005-07-07 Conxpert Holding Gmbh Method and device for monitoring the data exchange between application systems
US20060133387A1 (en) * 2004-12-16 2006-06-22 Georgiy Pekhteryev Route tracing in wireless networks
JP2006332787A (en) * 2005-05-23 2006-12-07 Sogo Keibi Hosho Co Ltd Monitoring system, monitoring terminal, terminal to be monitored, life-and-death monitoring program, and life-and-death monitoring response program
JP4773978B2 (en) * 2007-01-05 2011-09-14 富士通株式会社 Route search device, route search program, route search method, and route search system
JP4758372B2 (en) 2007-03-01 2011-08-24 富士通株式会社 Network load detection system, method, apparatus and program
JP5343863B2 (en) * 2008-02-13 2013-11-13 日本電気株式会社 Monitoring manager, general manager and node monitoring system
JP5494646B2 (en) 2009-02-25 2014-05-21 日本電気株式会社 Communication network management system, method, and management computer
JP5380687B2 (en) * 2009-10-20 2014-01-08 株式会社日立製作所 Network management apparatus and network management method
JP5645990B2 (en) * 2013-03-15 2014-12-24 三菱電機株式会社 Communication system and communication method
JP6890737B1 (en) * 2020-08-03 2021-06-18 三菱電機株式会社 Controls, methods, and programs

Also Published As

Publication number Publication date
JPH088909A (en) 1996-01-12

Similar Documents

Publication Publication Date Title
JP3569827B2 (en) Network system status diagnosis / monitoring device
US6363384B1 (en) Expert system process flow
US6526044B1 (en) Real-time analysis through capture buffer with real-time historical data correlation
US6529954B1 (en) Knowledge based expert analysis system
US5568471A (en) System and method for a workstation monitoring and control of multiple networks having different protocols
US4872165A (en) Fault diagnostic distributed processing method and system
CN102740112B (en) Method for controlling equipment polling based on video monitoring system
KR101057047B1 (en) System for monitoring and diagnosing remote devices
JPH1084357A (en) Loopback cell control system
CN107659423A (en) Method for processing business and device
US20150312123A1 (en) Method and apparatus for isolating a fault in a controller area network
CN106656617A (en) Master-slave switching method and device
CN108646697A (en) A kind of equipment fault remote diagnosis cloud platform
US20090259890A1 (en) Method & apparatus for hardware fault management
CN104950832B (en) Steel plant's control system
CN108173756A (en) A kind of dual redundant ethernet mac state health control method
CN103885441B (en) A kind of adaptive failure diagnostic method of controller local area network
CN107566219B (en) Fault diagnosis method applied to cluster system, node equipment and computer equipment
JP2008005118A (en) Network monitor system
CN108322315A (en) A kind of large-scale communication network network route exchange device software fault diagnosis method, system and equipment
JP3301383B2 (en) Network system test method and network test system
EP0431635A2 (en) Ring type LAN having fault processing system
JPH04264863A (en) Fault specifying system
JPH0260338A (en) Bus type lan
KR20100076836A (en) Method and system for detecting error based policy in process control network

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20040127

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20040329

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: 20040518

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20040609

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: 20080702

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20090702

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100702

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100702

Year of fee payment: 6

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110702

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110702

Year of fee payment: 7

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120702

Year of fee payment: 8

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130702

Year of fee payment: 9

LAPS Cancellation because of no payment of annual fees