JPH1051476A - Network management method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To obtain a network management method in which network management mainly for an agent is attained by monitoring trap reception of a manager and efficient network management in response to the network configuration is attained in the network management using a simple network management protocol(SNMP) to manage the network. SOLUTION: In the S1, in the case of transmission of a trap, whether or not the confirmation of reception of the trap is required by a manager is discriminated, in the S2, a trap monitor timer corresponding to the trap requiring reception confirmation is started, in the S3, the trap is sent to the manager, in the S4, elapse of time of the trap monitor timer is monitored, in the S5, the reply of the trap from the manager is received, in the S6, when a reply is received before expiration of the trap monitor timer, the trap reception timer is released and in the S7, when the trap monitor timer expires before the reception of reply, the trap is sent again.

Description

【発明の詳細な説明】DETAILED DESCRIPTION OF THE INVENTION

【０００１】[0001]

【発明の属する技術分野】本発明は、単純ネットワーク
管理プロトコル（Simple Network Management Protoco
l、以下ＳＮＭＰと称する）を使用してネットワークを
管理するネットワーク管理方法に関する。[0001] The present invention relates to a simple network management protocol (Simple Network Management Protocol).
l, hereinafter referred to as SNMP) for managing a network.

【０００２】情報処理についてのハードウェア、ソフト
ウェア技術の進展により、各企業にワークステーショ
ン、パーソナルコンピュータ等の情報処理装置が大量に
採用されるようになってきており、それらをＬＡＮ（Lo
cal Area Network) で接続して、相互に通信を行なうこ
とにより業務の効率化を図っている。2. Description of the Related Art With the advance of hardware and software technologies for information processing, information processing devices such as workstations and personal computers have been adopted in large numbers by companies, and these have been used for LAN (Lo
cal Area Network) and communicate with each other to improve business efficiency.

【０００３】このような、ＬＡＮに接続される機器は、
一つのメーカの製品に限定されるものではなく、複数の
メーカの製品 (所謂、マルチベンダ) が接続される環境
が一般的になってきている。このようなマルチベンダの
環境においても、ネットワーク管理を効率的に行なうこ
とが必要でであり、そのためのプロトコルの一つがＳＮ
ＭＰである。[0003] Such devices connected to the LAN are:
The environment is not limited to one manufacturer's product, but an environment in which a plurality of manufacturers' products (so-called multi-vendors) are connected is becoming common. Even in such a multi-vendor environment, it is necessary to efficiently perform network management, and one of the protocols for this is SN
MP.

【０００４】ＳＮＭＰではＰＤＵ (Protocol Data Uni
t) と称する５つのタイプのコマンドを使用する。Get R
equest 、Get Next Request、Set Request が、管理オ
ブジェクトの値の参照、次の管理オブジェクトの値の参
照、管理オブジェクトの値の変更要求としてマネージャ
からエージェントへ発行され、その応答としてGet Resp
onseが送出される。また、イベントが発生した場合のエ
ージェントからマネージャへの通知としてTrapが発行さ
れる。In SNMP, PDU (Protocol Data Uni
Use five types of commands, called t). Get R
equest, Get Next Request, and Set Request are issued from the manager to the agent as a request to reference the value of the managed object, reference to the value of the next managed object, or change the value of the managed object, and Get Resp is returned as a response.
onse is sent. A trap is issued from the agent to the manager when an event occurs.

【０００５】また、ＳＮＭＰでやりとりされる情報は管
理情報ベース (Management Information Base 、以下Ｍ
ＩＢと称する) という単位である。ＭＩＢはＲＦＣ(Req
uestFor Comments)によって、標準のＭＩＢが公開され
ているが、これらの標準のＭＩＢに対して、拡張ＭＩＢ
を定義して、メーカ独自の拡張ＭＩＢを使用することも
可能である。[0005] Information exchanged by SNMP is a management information base (hereinafter referred to as M).
IB). MIB is RFC (Req
uestFor Comments), standard MIBs are published, but extended MIBs are added to these standard MIBs.
Can be used to use a manufacturer-specific extended MIB.

【０００６】かかる、ＳＮＭＰを使用したネットワーク
において、効率的にネットワークを管理することが要求
されている。In such a network using SNMP, it is required to efficiently manage the network.

【０００７】[0007]

【従来の技術】図２３は従来例を説明する図を示す。図
はマネージャＭ１と、マネージャＭ１で管理されるエー
ジェント（以下エージェントをノードと称する）Ｎ１〜
Ｎｎからなるネットワーク１００を示す。2. Description of the Related Art FIG. 23 shows a diagram for explaining a conventional example. The figure shows a manager M1 and agents (hereinafter, agents are referred to as nodes) N1 to N1 managed by the manager M1.
1 shows a network 100 composed of Nn.

【０００８】ＳＮＭＰによるネットワーク管理では、各
ノードＮ１〜Ｎｎで発生したイベントをTrapでマネージ
ャＭ１に通知する。また、マネージャＭ１から各ノード
Ｎ１〜Ｎｎの情報を収集する場合には、情報収集のＭＩ
Ｂを送出することにより、その応答としてのＭＩＢを受
信し、情報を収集している。[0008] In the network management by SNMP, an event occurred in each of the nodes N1 to Nn is notified to the manager M1 by Trap. When collecting information on each of the nodes N1 to Nn from the manager M1, the information collection MI
By transmitting B, MIB as a response is received and information is collected.

【０００９】[0009]

【発明が解決しようとする課題】上述の従来例におい
て、任意のノードＮｉ（ｉ＝１〜ｎの中の１つ）から、
マネージャＭ１にTrapを送出した場合、マネージャＭ１
での受信確認がないので、伝送路上でTrapが紛失して
も、紛失したことがノードＮｉでは分からない。また、
マネージャＭ１からのＭＩＢによるポーリングで、ノー
ドＮ１〜Ｎｎの情報を収集することは可能であるが、ポ
ーリングによる情報収集であるので、例えば、障害発生
等の、リアルタイムでの処理が必要な状態情報をリアル
タイムで収集することができない。In the above-mentioned conventional example, from an arbitrary node Ni (one of i = 1 to n),
When a trap is sent to the manager M1, the manager M1
Therefore, even if the trap is lost on the transmission line, the node Ni cannot know that the trap has been lost. Also,
Although it is possible to collect the information of the nodes N1 to Nn by the polling by the MIB from the manager M1, since the information is collected by the polling, for example, the status information that needs to be processed in real time, such as the occurrence of a fault, is collected. Cannot be collected in real time.

【００１０】さらに、ネットワーク上のノードをノード
Ｎ１〜ＮｎからノードＮｎ＋１〜Ｎｘ（図示省略）を追
加する場合、ノード数の増加により、ポーリング周期が
長くなり、リアルタイムでの障害情報の収集が困難とな
る。Further, when adding nodes on the network from nodes N1 to Nn to nodes Nn + 1 to Nx (not shown), the polling cycle becomes longer due to an increase in the number of nodes, and it is difficult to collect fault information in real time. Become.

【００１１】また、ＩＰアドレスとＩＰ以外のアドレス
の関連がないので、拡張ＭＩＢによりＩＰアドレスとＩ
Ｐ以外のアドレスの対応を提供している。しかし、この
拡張ＭＩＢを搭載するルータはベンダが制限されるた
め、マルチベンダ環境で対応できない。Further, since there is no relation between the IP address and the address other than the IP, the IP address and the I
It provides correspondence for addresses other than P. However, routers equipped with the extended MIB cannot be used in a multi-vendor environment because the vendor is limited.

【００１２】本発明は、マネージャのTrap受信を監視す
ることによりエージェント主体のネットワーク管理が可
能となり、さらに、ネットワークの構成に応じた効率的
なネットワーク管理が可能となるネットワーク管理方法
を実現しようとする。An object of the present invention is to realize a network management method that enables agent-based network management by monitoring Trap reception of a manager and enables efficient network management according to a network configuration. .

【００１３】[0013]

【課題を解決するための手段】図１は本発明の原理を説
明する図である。図はマネージャＭ１とエージェントＮ
１〜Ｎｎからなり、ＳＮＭＰで管理されるネットワーク
１００の管理方法を示し、ＳＴＥＰ１はエージェントＮ
ｉはTrapを送信するとき、該TrapのマネージャＭ１にお
ける受信確認が必要か否かを判定し、ＳＴＥＰ２は受信
確認が必要なTrapに対応するトラップ監視タイマを起動
し、ＳＴＥＰ３は該TrapをマネージャＭ１に送信する。FIG. 1 is a diagram for explaining the principle of the present invention. The figure shows manager M1 and agent N
1 to Nn, and shows a management method of the network 100 managed by SNMP.
i, when transmitting a trap, determines whether or not the acknowledgment of the trap in the manager M1 is necessary, STEP2 starts a trap monitoring timer corresponding to the trap for which the acknowledgment is required, and STEP3 transmits the trap to the manager M1. Send to

【００１４】そして、ＳＴＥＰ４はトラップ監視タイマ
の経過時間を監視し、ＳＴＥＰ５はマネージャＭ１から
のTrapの応答を受信し、ＳＴＥＰ６はトラップ監視タイ
マのタイムアウト前に、該Trapの応答受信したときは、
トラップ受信タイマを解除し、ＳＴＥＰ７はTrapの応答
受信前に、トラップ監視タイマがタイムアウトとなった
場合は、該Trapを再送する。Then, STEP 4 monitors the elapsed time of the trap monitoring timer, STEP 5 receives the Trap response from the manager M1, and STEP 6 receives the Trap response before the timeout of the trap monitoring timer.
The trap receiving timer is canceled, and STEP 7 retransmits the trap if the trap monitoring timer times out before receiving the response of the trap.

【００１５】このように、エージェントＮｉから送信し
たTrapを、マネージャＭ１が受信したか否かを、マネー
ジャＭ１からのTrap受信応答により確認し、トラップ受
信タイマがタイムアウトとなっても、Trap受信応答がな
い場合は、該Trapを再送することにより、エージェント
ＮｉからのTrapを迅速にマネージャＭ１に送信すること
が可能となる。As described above, whether or not the trap transmitted from the agent Ni is received by the manager M1 is confirmed based on the Trap reception response from the manager M1. If not, by retransmitting the trap, the trap from the agent Ni can be promptly transmitted to the manager M1.

【００１６】[0016]

【発明の実施の形態】図２は本発明の実施の形態（１）
を説明する図である。図はマネージャＭ１とノードＮ１
〜Ｎｎからなり、ＳＮＭＰで管理されるネットワーク１
００を示す。FIG. 2 shows an embodiment (1) of the present invention.
FIG. The figure shows the manager M1 and the node N1
To Nn and managed by SNMP
00 is shown.

【００１７】図３は本発明の実施の形態（１）の動作シ
ーケンスを示す。以下、図３の動作シーケンスにより、
図２に示す実施の形態（１）のトラップ送信管理処理を
説明する。FIG. 3 shows an operation sequence of the embodiment (1) of the present invention. Hereinafter, according to the operation sequence of FIG.
The trap transmission management processing of the embodiment (1) shown in FIG. 2 will be described.

【００１８】Ｓ１１；ノードＮｉ（図２ではノードＮ１
で動作を示しいるが、ノードＮ１〜Ｎｎの中の任意のノ
ードであっても、その動作は同じである。）でTrap送信
要因が発生した場合、そのTrapが受信確認が必要か否か
を判定する。S11: Node Ni (node N1 in FIG. 2)
, The operation is the same for any of the nodes N1 to Nn. If a trap transmission factor occurs in ()), it is determined whether or not the trap requires acknowledgment.

【００１９】Ｓ１２；受信確認が必要なTrapの場合、ト
ラップ監視タイマを起動し、送信管理テーブルＴ１に送
信先のマネージャ名とTrap名とタイマＩＤを設定する。
Ｓ１３；TrapをマネージャＭ１に送信する。S12: In the case of a trap for which reception confirmation is required, a trap monitoring timer is started, and a manager name, a trap name, and a timer ID of a transmission destination are set in the transmission management table T1.
S13: Transmit Trap to the manager M1.

【００２０】Ｓ２１；マネージャＭ１はノードＮ１から
のTrapを受信する。 Ｓ２２；受信Trapの受信確認が必要か否かを判定する。 Ｓ２３；受信確認必要の場合は、Trap確認ＭＩＢのValu
e 値にTrap名を設定する。S21: The manager M1 receives a trap from the node N1. S22: It is determined whether the reception confirmation of the reception Trap is necessary. S23: If reception confirmation is necessary, Trap confirmation MIB Valu
e Set the Trap name to the value.

【００２１】Ｓ２４；Trap確認ＭＩＢのSet Request を
ノードＮ1 へ送信する。 Ｓ２５；受信確認必要でない場合は、該Trapの受信処理
を行ない終了となる。 Ｓ１４；タイマＩＤで指定されるトラップ監視タイマの
タイムアウトを監視する。S24: Send a Set Request of Trap confirmation MIB to the node N1. S25: If it is not necessary to confirm the reception, the reception processing of the Trap is performed, and the processing ends. S14: Monitor the timeout of the trap monitoring timer specified by the timer ID.

【００２２】Ｓ１５；Trap確認ＭＩＢのSet Request を
受信する。 Ｓ１６；タイムアウトとなる前にTrap確認ＭＩＢを受信
した場合は、Trap名で送信管理テーブルＴ１を検索し、
Trap名に対応するトラップ監視タイマを解除する。S15: Receive a Trap confirmation MIB Set Request. S16: If the Trap confirmation MIB is received before the timeout, the transmission management table T1 is searched by the Trap name,
Release the trap monitoring timer corresponding to the Trap name.

【００２３】Ｓ１７；タイムアウトとなった場合は、タ
イマＩＤで送信管理テーブルＴ１を検索して、設定され
ている送信先マネージャＭ１に該Trapを再送する。 上述のシーケンスにおいて、Ｓｉｊのｉ＝１はエージェ
ントの処理ＳＴＥＰを示し、ｉ＝２はマネージャ側の処
理ＳＴＥＰを示す。S17: When the time-out occurs, the transmission management table T1 is searched by the timer ID, and the trap is retransmitted to the set destination manager M1. In the above sequence, i = 1 of Sij indicates the processing STEP of the agent, and i = 2 indicates the processing STEP of the manager.

【００２４】図４、５は本発明の実施の形態（２）を説
明する図（その１）、（その２）である。図はマネージ
ャＭ１とノードＮ１〜Ｎｎからなり、一括ＭＩＢテーブ
ルＴ２−１、Ｔ２−２を設定し、そのテーブルにしたが
って、一括ＭＩＢで情報を収集するネットワーク１００
を示す。FIGS. 4 and 5 are diagrams (part 1) and (part 2) for explaining an embodiment (2) of the present invention. The figure comprises a manager M1 and nodes N1 to Nn, sets a collective MIB table T2-1, T2-2, and collects information in a collective MIB according to the table.
Is shown.

【００２５】図６は本発明の実施の形態（２）の動作シ
ーケンスを示す。以下、図６の動作シーケンスにより、
図４の一括ＭＩＢテーブルの設定、図５の一括ＭＩＢの
収集動作を説明する。FIG. 6 shows an operation sequence according to the embodiment (2) of the present invention. Hereinafter, according to the operation sequence of FIG.
The setting of the collective MIB table of FIG. 4 and the collecting operation of the collective MIB of FIG. 5 will be described.

【００２６】Ｓ２１；マネージャＭ１は、一括ＭＩＢで
収集するＭＩＢを一括ＭＩＢテーブルＴ２−１に登録す
る。 Ｓ２２；一括ＭＩＢを設定したSet Request をノードＮ
１に送信する。S21: The manager M1 registers the MIB collected by the collective MIB in the collective MIB table T2-1. S22: Set Request with batch MIB set to node N
Send to 1.

【００２７】Ｓ１１；ノードＮ１は一括ＭＩＢのSet Re
quest を受信する。 Ｓ１２；Set Request の内容を一括ＭＩＢテーブルＴ２
−２に設定する。 Ｓ１３；一括ＭＩＢテーブルＴ２−２の設定完了をGet
Responseで送信する。S11: The node N1 performs Set Re of the collective MIB.
Receive quest. S12: The contents of the Set Request are stored in the collective MIB table T2.
Set to -2. S13: Get completion of setting of collective MIB table T2-2
Send with Response.

【００２８】Ｓ２３；マネージャＭ１は、一括ＭＩＢテ
ーブルＴ２−２の設定完了をGet Responseで受信する。 以上の処理により、一括ＭＩＢテーブルＴ２−１、Ｔ２
−２が設定される。S23: The manager M1 receives the completion of setting of the collective MIB table T2-2 by Get Response. By the above processing, the collective MIB tables T2-1, T2
-2 is set.

【００２９】Ｓ２４；一括ＭＩＢ収集のGet Request を
ノードＮ１へ送信する。 Ｓ１４；ノードＮ１は一括ＭＩＢ収集のGet Request を
受信する。 Ｓ１５；一括ＭＩＢ収集を受信し、一括ＭＩＢテーブル
Ｔ２−２を検索し、対象ＭＩＢ値をValue 値に設定す
る。S24: A Get Request for collective MIB collection is transmitted to the node N1. S14: The node N1 receives a Get Request for collective MIB collection. S15: The collective MIB collection is received, the collective MIB table T2-2 is searched, and the target MIB value is set to the Value value.

【００３０】Ｓ１６；一括ＭＩＢのGet Responseをマネ
ージャＭ１に返送する。 Ｓ２５；マネージャＭ１は一括ＭＩＢのGet Responseを
受信する。 以上の処理により、複数ＭＩＢを１つのＭＩＢで収集す
ることが可能となる。S16: The Get Response of the collective MIB is returned to the manager M1. S25: The manager M1 receives the Get Response of the collective MIB. With the above processing, a plurality of MIBs can be collected by one MIB.

【００３１】図７は本発明の実施の形態（３）を説明す
る図である。図はマネージャＭ１がノードＮ１〜Ｎｎを
監視している状態で、マネージャＭ２が稼働し、一部の
ノードＮ１〜Ｎｉを追加されたマネージャＭ２が監視す
るネットワークである。FIG. 7 is a diagram for explaining the embodiment (3) of the present invention. The figure shows a network in which the manager M2 operates while the manager M1 monitors the nodes N1 to Nn, and the manager M2 to which some nodes N1 to Ni are added is monitored.

【００３２】図において、ノードＮ１〜Ｎｉがサブネッ
ト１を構成し、ノードＮｊ〜Ｎｎがサブネット２を構成
し、サブネット１とサブネット２はルータＲを経由して
接続されている例である。In the figure, nodes N1 to Ni constitute a subnet 1, nodes Nj to Nn constitute a subnet 2, and subnet 1 and subnet 2 are connected via a router R.

【００３３】図８は本発明の実施の形態（３）の動作シ
ーケンスを示す。 Ｓ３１；マネージャＭ１がノード管理テーブルＴ３に登
録されているノードＮ１〜Ｎｎを監視しているネットワ
ーク１００で、マネージャＭ２がマネージャとして新た
に起動したとき、マネージャＭ１にInform Requestで、
マネージャとして起動したことを通知する。FIG. 8 shows an operation sequence according to the embodiment (3) of the present invention. S31: When the manager M2 newly starts as a manager in the network 100 in which the manager M1 monitors the nodes N1 to Nn registered in the node management table T3, an Inform Request is sent to the manager M1.
Notify that you have started as a manager.

【００３４】Ｓ２１、Ｓ２２；マネージャ追加のInform
Requestを受信し、追加マネージャＭ２のＩＰアドレス
を確認する。 Ｓ２３；追加マネージャＭ２のＩＰアドレスからサブネ
ットを識別し、サブネットまでのHop 数で、追加マネー
ジャＭ２に移管するノードを決定する。S21, S22: Inform for adding manager
Request is received, and the IP address of the additional manager M2 is confirmed. S23: A subnet is identified from the IP address of the additional manager M2, and a node to be transferred to the additional manager M2 is determined based on the number of Hops up to the subnet.

【００３５】Ｓ２４、Ｓ２５；移管ノードがある場合に
は、そのノード、ＭＩＢをInform Requestでマネージャ
Ｍ２に通知し、マネージャＭ１は対象ノードのＭＩＢ収
集を停止する。S24, S25: If there is a transfer node, the node and MIB are notified to the manager M2 by an Inform Request, and the manager M1 stops MIB collection of the target node.

【００３６】Ｓ３２、Ｓ３３；移管ノードと移管元マネ
ージャを移管ノードテーブルＴ４に設定し、監視のため
のＭＩＢ収集を開始する。 Ｓ３４、Ｓ３５；監視中に障害ノードＮｊが発生したか
否かを判定し、障害が発生した場合は、移管ノードテー
ブルＴ４から障害が発生したノードＮｊの元のマネージ
ャＭ１を検出して、障害情報をInform Requestで元マネ
ージャＭ１に通知する。S32, S33: The transfer node and the transfer source manager are set in the transfer node table T4, and MIB collection for monitoring is started. S34, S35: It is determined whether or not a faulty node Nj has occurred during monitoring. If a fault has occurred, the original manager M1 of the faulty node Nj is detected from the transfer node table T4, and fault information is detected. Is notified to the former manager M1 by an Inform Request.

【００３７】シーケンス図中Ｓｉｊのｉ＝３は追加され
たマネージャの処理ＳＴＥＰを示す。また、図中、稼働
中のマネージャＭ１と追加されたマネージャＭ２との間
の通信はInform Requestで行なうものとして説明した
が、Trapを使用することも可能である。In the sequence diagram, i = 3 of Sij indicates the processing STEP of the added manager. In the figure, the communication between the operating manager M1 and the added manager M2 has been described as being performed by the Inform Request, but Trap can also be used.

【００３８】かかる処理により、マネージャを追加した
場合、追加マネージャの設定処理のみで、稼働中のマネ
ージャとのノード管理の分散を効率的に行なうことが可
能となる。According to this processing, when a manager is added, it is possible to efficiently distribute the node management with the operating manager only by setting the added manager.

【００３９】図９は本発明の実施の形態（４）を説明す
る図である。図はマネージャＭ１がノードＮ１〜Ｎｉを
監視している状態で、ノードＮｊ〜Ｎｎが追加され、ノ
ードＮｊ〜Ｎｎが追加されたことにより、マネージャＭ
１の最大監視ノード数を超過したので、他のマネージャ
Ｍ２を起動するネットワークを示す。FIG. 9 is a view for explaining an embodiment (4) of the present invention. The figure shows a state in which the manager M1 is monitoring the nodes N1 to Ni, the nodes Nj to Nn are added, and the nodes Nj to Nn are added.
1 shows a network that activates another manager M2 because the maximum monitoring node number of 1 has been exceeded.

【００４０】図１０は本発明の実施の形態（４）の動作
シーケンスを示す。 Ｓ２１、Ｓ２２；マネージャＭ１は定期的にブロードキ
ャストでＰＩＮＧ（ＴＣＰ／ＩＰによる通信において、
指定の端末からのエコーを要求するコマンドである。）
を送出し、その応答から追加ノードの有無を判定する。FIG. 10 shows an operation sequence according to the embodiment (4) of the present invention. S21, S22: The manager M1 periodically broadcasts PING (in the communication by TCP / IP,
This command requests an echo from the specified terminal. )
Is sent, and the presence or absence of an additional node is determined from the response.

【００４１】Ｓ２３〜Ｓ２５；追加ノードがある場合
は、ノード管理テーブルＴ３を参照し、監視最大ノード
数以下か否かを判定し、監視最大ノード数を超えたノー
ドは管理対象外ノードテーブルＴ５に設定し、マネージ
ャ管理テーブルＴ６からネットワーク上の非稼働中のマ
ネージャＭ２を検索し（ここではマネージャＭ２が検出
できる。）ｒｓｈにより起動する。S23 to S25: If there is an additional node, it is determined whether or not the number of nodes is equal to or less than the maximum number of monitored nodes by referring to the node management table T3. After setting, the manager M2 on the network that is not operating is searched from the manager management table T6 (here, the manager M2 can be detected).

【００４２】Ｓ３１、Ｓ３２；マネージャＭ２が起動
し、起動したことをInform RequestでマネージャＭ１に
通知する。 Ｓ２６〜Ｓ２８；マネージャＭ１は、マネージャＭ２が
起動したことを確認すると、管理対象外ノードテーブル
Ｔ５のＩＰアドレスをInform Requestで通知する。S31, S32: The manager M2 is started, and the start is notified to the manager M1 by an Inform Request. S26 to S28: When confirming that the manager M2 has started, the manager M1 notifies the IP address of the unmanaged node table T5 by an Inform Request.

【００４３】Ｓ３３、Ｓ３４；Inform Requestを受信し
たマネージャＭ２はノードＮｊ〜Ｎｎの監視を開始す
る。 Ｓ２５のｒｓｈは、Remote Shell UNIX を示し、自分の
端末から相手端末に入って、相手のプログラムを動作さ
せるプログラムであり、Ｓ２８、Ｓ３２で使用したInfo
rm RequestはTrapを使用することも可能である。S33, S34: The manager M2 receiving the Inform Request starts monitoring the nodes Nj to Nn. Rsh in S25 indicates Remote Shell UNIX, which is a program for entering the partner terminal from the own terminal and operating the partner program, and the Info used in S28 and S32
rm Request can also use Trap.

【００４４】かかる処理により、ネットワーク環境が変
化し、ノード数が変化した場合でも、起動可能なマネー
ジャが存在する場合には、これを稼働中のマネージャか
ら起動し、最適な監視環境を実現することができる。With this processing, even if the network environment changes and the number of nodes changes, if there is a bootable manager, it is started from the running manager to realize an optimum monitoring environment. Can be.

【００４５】図１１は本発明の実施の形態（５）を説明
する図である。図はマネージャＭ１がルータとして稼働
しているノードＮ１〜Ｎ４を監視している状態で、ノー
ドＮ４の機能が追加され、ノードＮ４がルータおよびブ
リッジとして機能するようになった例である。FIG. 11 is a view for explaining an embodiment (5) of the present invention. The figure shows an example in which the function of the node N4 is added while the manager M1 monitors the nodes N1 to N4 operating as routers, and the node N4 functions as a router and a bridge.

【００４６】図１２は本発明の実施の形態（５）の動作
シーケンスを示す。 Ｓ２１、Ｓ２２；マネージャＭ１は定期的にプロセス管
理テーブルＴ７に設定されている機能別確認ＭＩＢを収
集し、ノードＮ１〜Ｎｎに追加機能があるか否かを判定
する。FIG. 12 shows an operation sequence of the embodiment (5) of the present invention. S21, S22: The manager M1 periodically collects function-specific confirmation MIBs set in the process management table T7, and determines whether or not the nodes N1 to Nn have additional functions.

【００４７】Ｓ２３；追加機能がある場合は、マネージ
ャ管理テーブルＴ６を参照し、マネージャ管理テーブル
Ｔ６を検索して起動可能なマネージャを検出し、プロセ
ス指定でマネージャＭ２をｒｓｈにより起動する。S23: If there is an additional function, the manager management table T6 is referred to, the manager management table T6 is searched to detect a startable manager, and the manager M2 is started by rsh by specifying a process.

【００４８】Ｓ３１、Ｓ３２；マネージャＭ２が起動
し、起動したことをInform Request(or Trap) でマネー
ジャＭ１に通知する。 Ｓ２５、Ｓ２６；マネージャＭ１は、マネージャＭ２が
起動したことを確認すると、機能が追加されたノードＮ
４をInform Request(or Trap) で通知する。S31, S32: The manager M2 is started, and the start is notified to the manager M1 by an Inform Request (or Trap). S25, S26: When the manager M1 confirms that the manager M2 has been started, the node N to which the function has been added is
4 is notified by Inform Request (or Trap).

【００４９】Ｓ３３、Ｓ３４；Inform Requestを受信し
たマネージャＭ２はノードＮ４のブリッジ機能の監視を
開始する。 かかる処理により、監視中のノードで新たな機能が稼働
開始した場合、その機能の監視を他のマネージャで行な
うことにより、稼働中のマネージャに負荷が集中するこ
とを防ぐことができる。S33, S34: Upon receiving the Inform Request, the manager M2 starts monitoring the bridge function of the node N4. With this processing, when a new function starts operating on the node being monitored, the monitoring of that function is performed by another manager, thereby preventing the load from being concentrated on the running manager.

【００５０】図１３は本発明の実施の形態（６）を説明
する図である。図はマネージャＭ１がノードＮ１〜Ｎｎ
を監視している状態で、マネージャＭ２がバックアップ
マネージャとして追加された例を示す。FIG. 13 is a view for explaining the embodiment (6) of the present invention. The figure shows that the manager M1 has nodes N1 to Nn.
An example in which the manager M2 has been added as a backup manager while monitoring is being monitored.

【００５１】図１４は本発明の実施の形態（６）の動作
シーケンスを示す。 Ｓ３１；バックアップマネージャＭ２はバックアップと
しての起動をバックアップ対象のマネージャＭ１にInfo
rm Request(or Trap) で通知する。FIG. 14 shows an operation sequence according to the embodiment (6) of the present invention. S31: The backup manager M2 informs the manager M1 to be backed up that it has started up as a backup
Notify by rm Request (or Trap).

【００５２】Ｓ２１、Ｓ２２；マネージャＭ１はバック
アップマネージャテーブルＴ８にバックアップマネージ
ャＭ２を登録し、登録後は、増減したノードがあれば、
それをバックアップマネージャＭ２にInform Request(o
r Trap) で通知する。S21, S22: The manager M1 registers the backup manager M2 in the backup manager table T8.
Inform Request (o) to backup manager M2
r Trap).

【００５３】Ｓ３２；マネージャＭ２は監視ノードの増
減を登録する。 Ｓ３３、Ｓ３４；バックアップマネージャＭ２はマネー
ジャＭ１の監視を行ない、マネージャＭ１に障害が発生
した場合、監視対象ノードＮ１〜Ｎｎの監視を開始す
る。S32: The manager M2 registers the increase / decrease of the monitoring node. S33, S34: The backup manager M2 monitors the manager M1, and when a failure occurs in the manager M1, starts monitoring the monitored nodes N1 to Nn.

【００５４】Ｓ２３、Ｓ２４；一方、マネージャＭ１が
何らかの理由で、マネージャ機能を停止する場合は、バ
ックアップマネージャテーブルＴ８を参照して、登録さ
れているバックアップマネージャＭ２に対して、機能停
止をInform Request(or Trap) で通知し、機能停止を受
信したバックアップマネージャＭ２はバックアップとし
て稼働を開始する。S23, S24: On the other hand, if the manager M1 stops the manager function for some reason, the backup manager M2 is referred to the backup manager table T8 to inform the registered backup manager M2 of the function stop by an Inform Request ( or Trap), and the backup manager M2 that has received the function suspension starts operating as a backup.

【００５５】かかる処理により、バックアップマネージ
ャの登録を行なうのみで、稼働中のマネージャが障害と
なった場合、自動的にバックアップマネージャを起動
し、ネットワーク監視を継続することができる。According to this processing, when the backup manager is only registered and the operating manager fails, the backup manager can be automatically started and the network monitoring can be continued.

【００５６】図１５、１６は本発明の実施の形態（７）
を説明する図（その１）、（その２）である。実施の形
態（７）の（その１）はＩＰプロトコル、ＩＰ以外のプ
ロトコルのネットワークのイメージを説明する図であ
る。FIGS. 15 and 16 show an embodiment (7) of the present invention.
FIGS. 7A and 7B are diagrams (No. 1) and (No. 2) for explaining. (Part 1) of the embodiment (7) is a diagram for explaining an image of a network of an IP protocol and a protocol other than the IP.

【００５７】（Ａ）はネットワークイメージを示し、
（Ｂ）はＩＰネットワーク構成を示し、ネットワークは
ノードＮ１とブルータＢＲ１がサブネット１を、ブルー
タＢＲ１とノードＮ２とブルータＢＲ２がサブネット２
を、ブルータＢＲ２とノードＮ３とブルータＢＲ３がサ
ブネット３を、ブルータＢＲ３とノードＮ４がサブネッ
ト４を構成している図である。(A) shows a network image,
(B) shows the IP network configuration. In the network, the node N1 and the brouter BR1 are on the subnet 1, and the brouter BR1, the node N2 and the brouter BR2 are on the subnet 2.
FIG. 2 is a diagram in which a brouter BR2, a node N3, and a brouter BR3 configure a subnet 3, and a brouter BR3 and a node N4 configure a subnet 4.

【００５８】また、（Ｃ）はＩＰＸネットワークを示
し、ブルータＢＲ２はＩＰＸネットワークにおいては、
ブリッジ機能のみを備えているので、ブルータＢＲ１〜
ブルータＢＲ３までが１つのネットアドレス（2222.333
3)をもつ構成となる。(C) shows an IPX network, and Brouter BR2 shows an IPX network.
Since it has only a bridge function, Bruta BR1
One net address up to Bruta BR3 (2222.333
3).

【００５９】図１７は実施の形態（７）のフローチャー
トであり、図１５の（その１）のＩＰ以外のプロトコル
についてのルート表示を行なう場合の処理フローチャー
トを示す。FIG. 17 is a flowchart of the embodiment (7), and shows a processing flowchart in the case of displaying a route for a protocol other than the IP shown in FIG. 15 (part 1).

【００６０】Ｓ１；ルート検索テーブルＴ１０に指定さ
れた開始ノードと最終ノード、ここでは、ノード１とノ
ード４を設定し、検索ノードテーブルＴ９には開始ノー
ドＮ１を設定する。S1: The start node and the last node designated in the route search table T10, here, the node 1 and the node 4, are set, and the start node N1 is set in the search node table T9.

【００６１】Ｓ２；最終ノードＮ４と検索ノードテーブ
ルＴ９に設定されたノードＮ１のネットアドレスを比較
し、一致すれば、ルータを経由しない同一ネットに接続
されていることになるので、ルート検索は終了する。S2: The net address of the last node N4 is compared with the net address of the node N1 set in the search node table T9, and if they match, it means that they are connected to the same net that does not pass through a router, and the route search ends. I do.

【００６２】Ｓ３；ここでは、ネットアドレスは一致し
ないので、検索ノードテーブルＴ９に設定したノードＮ
１にＩＰＸの拡張ＭＩＢを送出して、ＩＰＸのルーティ
ングテーブルを収集し、最終ノードＮ４までに経由する
最初のルータ、ここではブルータＢＲ１のプロトコルア
ドレス1111.2222.0.e00.11、さらにブルータＢＲ1 のＭ
ＡＣアドレス0:0:e:0:0:11が得られる。収集したプロト
コルアドレスをルート検索テーブルＴ１０の経由ルータ
の欄に設定する。S3: Here, since the net addresses do not match, the node N set in the search node table T9
1 sends an extended MIB of IPX, collects an IPX routing table, and routes the first router to the last node N4, here, the protocol address 1111.2222.0.e00.11 of the brouter BR1, and furthermore, the M of the brouter BR1.
AC addresses 0: 0: e: 0: 0: 11 are obtained. The collected protocol address is set in the column of the route router in the route search table T10.

【００６３】Ｓ４；検索ノードテーブルＴ９に設定され
ているノードＮ１のサブネット133.161.59.0に対してブ
ロードキャストでＰＩＮＧを送出する。その応答により
ノードＮ１とブルータＢＲ１のＩＰアドレス133.161.5
9.11 および133.161.59.12 を得て、ブルータＢＲ１に
対してＭＩＢ２（標準ＭＩＢ）を収集し、ＭＡＣアドレ
ス0:0:e:0:0:11が得られる。これと、先に得たＭＡＣア
ドレスとの比較により、ブルータＢＲ１のＩＰアドレス
に認識し、ルート検索テーブルＴ１０の経由ルータのＩ
Ｐアドレス欄に設定する。S4: PING is transmitted by broadcast to the subnet 133.161.59.0 of the node N1 set in the search node table T9. According to the response, the IP addresses of the node N1 and the brouter BR1 are 133.161.5.
After obtaining 9.11 and 133.161.59.12, MIB2 (standard MIB) is collected for the brouter BR1, and the MAC address 0: 0: e: 0: 0: 11 is obtained. By comparing this with the MAC address obtained earlier, it is recognized as the IP address of the brouter BR1, and the IP address of the transit router in the route search table T10 is recognized.
Set in the P address column.

【００６４】Ｓ５；Ｓ４で収集したサブネット内にルー
タのプロトコルアドレスの有無を判定する。 Ｓ６；ルータのプロトコルアドレスが無い、例えば、サ
ブネット２内にはブルータＢＲ３のプロトコルアドレス
は存在しない、場合は、処理中のサブネットの端末（開
始ノード、終了ノード）のＩＰルーティングテーブルの
アドレスからＮｅｘｔルータのアドレスを収集し、隣接
サブネットを認識し、そのサブネットに対してＰＩＮＧ
を送出し、返送されたＩＰアドレスをもとにプロトコル
アドレスＭＩＢを収集する。S5: It is determined whether there is a protocol address of the router in the subnet collected in S4. S6: If there is no protocol address of the router, for example, if there is no protocol address of the router BR3 in the subnet 2, in the case of the next router, the address of the terminal (start node, end node) of the subnet being processed is determined from the address of the IP routing table. Address, recognize neighboring subnets, and PING
And collects the protocol address MIB based on the returned IP address.

【００６５】この場合はブルータＢＲ１にＩＰＸの拡張
ＭＩＢを送出して、ＩＰＸのルーティングテーブルを取
得し、ノードＮ４への経由ルータとしてブルータＢＲ２
のＩＰＸアドレス2222.3333.0.e00.15が返送され、ブル
ータＢＲ２のＭＡＣアドレス0:0:e:0:0:15が得られる。In this case, the extended MIB of IPX is sent to the brouter BR1, the routing table of IPX is acquired, and the router BR2 is transmitted as a transit router to the node N4.
The IPX address 2222.3333.0.e00.15 is returned, and the MAC address 0: 0: e: 0: 0: 15 of the brouter BR2 is obtained.

【００６６】次いで、ブルータＢＲ1 から接続されてい
るＩＰネットワークのサブネットを認識するため、ＩＰ
ルーティング関連ＭＩＢを収集してサブネット１〜３を
認識する。Next, in order to recognize the subnet of the IP network connected from the router BR1,
It collects routing-related MIBs and recognizes subnets 1 to 3.

【００６７】そして、133.161.60.0のサブネット２に対
してブロードキャストでＰＩＮＧを送出し、ブルータＢ
Ｒ１、ノードＮ２、ブルータＢＲ２が応答し、ＩＰアド
レス133.161.60.11,133.161.60.12,133.161.60.13 が認
識し、ＭＩＢ２関連ＭＩＢの収集により、ノードＮ２、
ブルータＢＲ２のＭＡＣアドレス0:0:e:0:0:12および0:
0:e:0:0:13を認識でき、ブルータＢＲ３のＩＰアドレス
は133.161.60.0のサブネット２には存在しないことが分
かる。Then, PING is transmitted by broadcast to the subnet 2 of 133.161.60.0,
R1, the node N2, and the brouter BR2 respond, and the IP addresses 133.161.60.11, 133.161.60.12, and 133.161.60.13 are recognized.
MAC address of Bruta BR2 0: 0: e: 0: 0: 12 and 0:
0: e: 0: 0: 13 can be recognized, indicating that the IP address of the brouter BR3 does not exist in the subnet 2 of 133.161.60.0.

【００６８】次いで、133.161.60.0のサブネット２に対
してブロードキャストでＰＩＮＧを送出したと同様に、
133.161.61.0のサブネット３に対してブロードキャスト
でＰＩＮＧを送出しブルータＢＲ２、ノードＮ３、ブル
ータＢＲ３が応答し、それぞれのＩＰアドレスを収集
し、ＭＩＢ２関連ＭＩＢの収集により、ノードＮ３、ブ
ルータＢＲ３のＭＡＣアドレス0:0:e:0:0:14，0:0:e:0:
0:15を認識でき、先に取得したＭＡＣアドレスと比較す
ることにより、ブルータＢＲ３のＩＰアドレスを認識す
ることができる。Next, similarly to the case where the PING is transmitted by broadcast to the subnet 2 of 133.161.60.0,
A broadcast PING is sent to the subnet 3 of 133.161.61.0, and the brouter BR2, the node N3, and the brouter BR3 respond, and collect their respective IP addresses. 0: 0: e: 0: 0: 14, 0: 0: e: 0:
0:15 can be recognized, and the IP address of the brouter BR3 can be recognized by comparing with the MAC address acquired earlier.

【００６９】Ｓ７、Ｓ８；サブネット内にルータを確認
した場合、検索ノードテーブルＴ９にルータのＩＰアド
レスを設定し、検索ルートテーブルＴ１０（図中検索テ
ーブルと示す）にＩＰアドレスを設定し、検索ノードテ
ーブルＴ９に設定したノードからプロトコルアドレスＭ
ＩＢを収集して、ネットアドレスを算出し、Ｓ２へ戻
る。S7, S8: When a router is found in the subnet, the router IP address is set in the search node table T9, and the IP address is set in the search route table T10 (shown as a search table in the figure). From the node set in Table T9 to the protocol address M
IB is collected, a net address is calculated, and the process returns to S2.

【００７０】このような処理を最終ノードと検索ノード
テーブルＴ９のネットアドレスが一致するまで行なう。
ここでは、ブルータＢＲ３に対して、同様な処理を行な
うことにより、ブルータＢＲ３から、ノードＮ４が直接
接続されていることが認識でき終了となる。This process is repeated until the last node matches the net address in the search node table T9.
Here, by performing the same processing on the brouter BR3, the brouter BR3 can recognize that the node N4 is directly connected, and the process ends.

【００７１】図１６は以上の処理により作成したＩＰＸ
プロトコルのルート図であり、ノードＮ１からノードＮ
４の間のルータはブルータＢＲ１とブルータＢＲ３であ
る。上述の実施の形態（７）では、ＩＰ以外のプロトコ
ルはＩＰＸやＡｐｐｌｅＴａｌｋ等があるが、表現を簡
略化するため、ＩＰ以外のプロトコルをＩＰＸで代表し
て記している。FIG. 16 shows the IPX created by the above processing.
It is a route diagram of a protocol.
The routers between 4 are Brouter BR1 and BR3. In the above-described embodiment (7), protocols other than IP include IPX and AppleTalk, but for simplicity, protocols other than IP are represented by IPX.

【００７２】かかる処理により、ＳＮＭＰプロトコルに
より、ＩＰ以外のプロトコルのルート検索を可能とす
る。図１８は本発明のルート検索に使用するテーブルを
示す。With this processing, a route search of a protocol other than the IP is enabled by the SNMP protocol. FIG. 18 shows a table used for the route search of the present invention.

【００７３】Ｔ９は検索ノードテーブルを示し、検索を
開始するノード、或いは、検索を行なう経由ノードを設
定するテーブルである。Ｔ１０はルート検索テーブルで
あり、開始ノード、最終ノード、および、経由ルートを
設定するテーブルであり、プロトコルアドレスとＩＰア
ドレスで設定する。T9 indicates a search node table, which is a table for setting a node to start a search or a transit node to perform a search. T10 is a route search table, which is a table for setting a start node, a last node, and a route via which is set by a protocol address and an IP address.

【００７４】Ｔ１２は後述の実施の形態（９）で使用す
るルート検索テーブルであり、開始ノード、最終ノー
ド、および、経由ルートを設定するテーブルであり、プ
ロトコルアドレスとＩＰアドレスに加えてＭＡＣアドレ
スで設定する。T12 is a route search table used in the later-described embodiment (9), and is a table for setting a start node, an end node, and a route to be routed. Set.

【００７５】図１９は本発明の実施の形態（８）のフロ
ーチャートである。図はＩＰ以外のプロトコルについて
のルート表示を行なう場合の処理フローチャートであ
り、図１７で説明した実施の形態（７）との差はＡＲＰ
(Adress Resolution Protocol) テーブルＴ１１を使用
することにある。以下、実施の形態（７）との差を説明
する。FIG. 19 is a flowchart of the embodiment (8) of the present invention. FIG. 17 is a processing flowchart when a route is displayed for a protocol other than IP, and the difference from the embodiment (7) described in FIG.
(Adress Resolution Protocol) is to use the table T11. Hereinafter, differences from the embodiment (7) will be described.

【００７６】Ｓ１〜Ｓ３；検索ノードテーブルＴ９、ル
ート検索テーブルＴ１０に開始ノード、経由ルータ、最
終ノードを設定し、ルーティングテーブルによりＮｅｘ
ｔルータのアドレスを収集し、ルート検索テーブルＴ１
０に設定する処理は実施の形態（７）と同じである。S1 to S3: The start node, the transit router, and the last node are set in the search node table T9 and the route search table T10, and Nex is set by the routing table.
t router addresses are collected, and a route search table T1 is collected.
The process of setting to 0 is the same as that of the embodiment (7).

【００７７】Ｓ４；検索ノードテーブルＴ９に設定され
ているノードＮ１からＡＲＰテーブル関連ＭＩＢを収集
し、ＩＰアドレスをもとにプロトコルアドレスを収集す
る。ＡＲＰテーブルＴ１１は各ノード、ブルータに設け
られているものであり、それぞれのノードに接続されて
いるノードのＩＰアドレスとＭＡＣアドレスの対応を示
すものである。ここでは、ノードＮ１にＡＲＰテーブル
関連ＭＩＢを送出し、ノードＮ１に設定されているＡＲ
ＰテーブルＴ１１を取得し、そこから、ノードＮ１とブ
ルータＢＲ１のＩＰアドレス133.161.59.10 、133.161.
59.11 が認識できる。そしてブルータＢＲ１に対してＩ
ＰＸの拡張ＭＩＢを送出し、ブルータＢＲ1 のＩＰＸア
ドレス1111.2222.0.e00.11が得られる。S4: The ARP table related MIB is collected from the node N1 set in the search node table T9, and the protocol address is collected based on the IP address. The ARP table T11 is provided in each node and brouter, and indicates the correspondence between the IP address and the MAC address of the node connected to each node. Here, the ARP table-related MIB is transmitted to the node N1, and the AR set in the node N1 is set.
The P table T11 is obtained, and the IP addresses 133.161.59.10 and 133.161. Of the node N1 and the brouter BR1 are obtained from the P table T11.
59.11 can be recognized. And I against Bruta BR1
The extended MIB of the PX is transmitted, and the IPX address 1111.2222.0.e00.11 of the brouter BR1 is obtained.

【００７８】Ｓ５；Ｓ４で収集したサブネット内にルー
タのプロトコルアドレスの有無を判定する。 Ｓ６；ルータのプロトコルアドレスが無い場合は、処理
中のサブネットの端末（開始ノード、終了ノード）のＩ
ＰルーティングテーブルのアドレスからＮｅｘｔルータ
のアドレスを収集し、そのルータからＡＲＰテーブル関
連ＭＩＢを収集し、ＩＰアドレスをもとにプロトコルア
ドレスを収集する。隣接サブネットを認識し、そのサブ
ネットに対してＰＩＮＧを送出し、返送され Ｓ７、Ｓ８；図１７と同じである。S5: It is determined whether there is a protocol address of the router in the subnet collected in S4. S6: If there is no protocol address of the router, the I (I) of the terminal (start node, end node) of the subnet being processed
The address of the Next router is collected from the address in the P routing table, the MIB related to the ARP table is collected from the router, and the protocol address is collected based on the IP address. Recognizes the adjacent subnet, sends a PING to the subnet, and returns S7, S8; the same as FIG.

【００７９】このように最終ノードと検索ノードテーブ
ルＴ９のネットアドレスが一致するまでルート検索を行
なう。ここでは、ブルータＢＲ３に対して、同様な処理
を行なうことにより、ブルータＢＲ３から、ノードＮ４
が直接接続されていることが認識でき終了となる。Thus, the route search is performed until the last node matches the net address of the search node table T9. Here, the same processing is performed on the brouter BR3, so that the brouter BR3 is
Is recognized as being directly connected, and the process ends.

【００８０】図１９の実施の形態（８）のルート検索に
おいても、最終的に得られるルート図は図１７のフロー
チャートによって得た図１６のルート構成図と同じ構成
である。Also in the route search according to the embodiment (8) in FIG. 19, the finally obtained route diagram has the same configuration as the route configuration diagram in FIG. 16 obtained by the flowchart in FIG.

【００８１】かかる処理により、ＳＮＭＰプロトコルに
より、ＩＰ以外のプロトコルのルート検索を可能とす
る。図２０は本発明の実施の形態（９）のフローチャー
トである。図はＩＰＸのプロトコルについてのルート表
示を行なう場合の処理フローチャートであり、図１９で
説明した実施の形態（８）との差を説明する。According to this processing, the route search of a protocol other than the IP can be performed by the SNMP protocol. FIG. 20 is a flowchart of the embodiment (9) of the present invention. FIG. 20 is a processing flowchart when a route is displayed for the IPX protocol, and a difference from the embodiment (8) described with reference to FIG. 19 will be described.

【００８２】Ｓ１〜Ｓ２；検索ノードテーブルＴ９、ル
ート検索テーブルＴ１０に開始ノードを設定し、開始ノ
ードと最終ノードのネットアドレスが一致するか否かを
判定する処理は実施の形態（８）と同じである。S1 to S2: The process of setting a start node in the search node table T9 and the route search table T10 and determining whether or not the net addresses of the start node and the last node match are the same as those in the embodiment (8). It is.

【００８３】Ｓ３；検索ノードテーブルＴ９に設定され
ているのＩＰ以外の対象プロトコルのルーティングテー
ブルからＮｅｘｔルータのプロトコルアドレス、ＭＡＣ
アドレスを取得し、ルート検索テーブルＴ１２に設定す
る。S3: From the routing table of the target protocol other than the IP set in the search node table T9, the protocol address and MAC of the Next router
An address is obtained and set in the route search table T12.

【００８４】この場合、ノードＮ１のルーティングテー
ブルから、経由ルータとして、ブルータＢＲ１のＩＰＸ
アドレス1111.2222.0.e00.11が得られ、さらにブルータ
ＢＲ１のＭＡＣアドレスとして0:0:e:0:0:11が認識でき
る。In this case, based on the routing table of the node N1, the IPX of the brouter BR1
The address 1111.2222.0.e00.11 is obtained, and 0: 0: e: 0: 0: 11 can be recognized as the MAC address of the brouter BR1.

【００８５】Ｓ４；検索ノードテーブルＴ９に設定され
ているノードＮ１からＡＲＰテーブル関連ＭＩＢを収集
し、ＩＰアドレスとＭＡＣアドレスの対応を認識する。
ここでは、ノードＡのＡＲＰテーブルＴ１１からノード
Ｎ１、ブルータＢＲ１のＩＰアドレス、ＭＡＣアドレス
133.161.59.10 、0:0:e:0:0:10および133.161.59.11 、
0:0:e:0:0:11が認識できる。S4: The ARP table related MIB is collected from the node N1 set in the search node table T9, and the correspondence between the IP address and the MAC address is recognized.
Here, the IP address and MAC address of the node N1 and the brouter BR1 are obtained from the ARP table T11 of the node A.
133.161.59.10, 0: 0: e: 0: 0: 10 and 133.161.59.11,
0: 0: e: 0: 0: 11 can be recognized.

【００８６】Ｓ５；Ｓ４で収集したサブネット内にルー
タのＭＡＣアドレスの有無を判定する。 Ｓ６；ルータのＭＡＣアドレスが無い場合は、処理中の
サブネットの端末（開始ノード、終了ノード）のＩＰル
ーティングテーブルのアドレスからＮｅｘｔルータのア
ドレスを収集し、そのルータからＡＲＰテーブル関連Ｍ
ＩＢを収集し、ＩＰアドレスとＭＡＣアドレスの対応を
認識する。S5: It is determined whether there is a MAC address of the router in the subnet collected in S4. S6: If there is no MAC address of the router, the address of the Next router is collected from the IP routing table address of the terminal (start node, end node) of the subnet being processed, and the ARP table related M is collected from the router.
IB is collected, and the correspondence between the IP address and the MAC address is recognized.

【００８７】Ｓ７、Ｓ８；図１９と同じである。 このように最終ノードと検索ノードテーブルＴ９のネッ
トアドレスが一致するまでルート検索を行なう。ここで
は、ブルータＢＲ３に対して、同様な処理を行なうこと
により、ブルータＢＲ３から、ノードＮ４が直接接続さ
れていることが認識でき終了となる。S7, S8: The same as FIG. In this way, the route search is performed until the last node matches the net address of the search node table T9. Here, by performing the same processing on the brouter BR3, the brouter BR3 can recognize that the node N4 is directly connected, and the process ends.

【００８８】図２０の実施の形態（９）ルート検索にお
いても、最終的に得られるルート構成図は図１７のフロ
ーチャートによって得た図１６と同じ構成である。かか
る処理により、ＳＮＭＰプロトコルにより、ＩＰＸのプ
ロトコルのルート検索を可能とする。In the route search of the embodiment (9) of FIG. 20, the finally obtained route configuration is the same as that of FIG. 16 obtained by the flowchart of FIG. With this processing, the route search of the IPX protocol can be performed by the SNMP protocol.

【００８９】図２１は本発明の実施の形態（１０）を説
明する図である。図のネットワーク構成、およびＩＰネ
ットワーク、ＩＰアドレスは図１５の実施の形態（７）
で説明したと同じ構成である。FIG. 21 is a view for explaining an embodiment (10) of the present invention. The network configuration, the IP network, and the IP address shown in FIG.
This is the same configuration as described in the above.

【００９０】図中のＴ１１−Ｎ１はノードＮ１のＡＲＰ
テーブル、Ｔ１１−ＢＲ１〜ＢＲ３は、それぞれブルー
タＢＲ１〜ＢＲ３のＡＲＰテーブルである。実施の形態
（８）、（９）においては、ＡＲＰテーブルＴ１１を使
用してＩＰ以外のプロトコルアドレスとＩＰプロトコル
アドレスの対応を確認しているので、この処理を行なう
間ＡＲＰテーブルＴ１１が必要となる。そこで、ノー
ド、ブルータを定期的にアクセスすることによりＡＲＰ
テーブルのクリアを防止するものである。T11-N1 in the figure is the ARP of the node N1.
The tables, T11-BR1 to BR3, are ARP tables of the brouters BR1 to BR3, respectively. In the embodiments (8) and (9), since the correspondence between the protocol address other than IP and the IP protocol address is confirmed using the ARP table T11, the ARP table T11 is required during this process. . Therefore, ARP is regularly accessed by nodes and brouters.
This is to prevent clearing of the table.

【００９１】図２２は本発明の実施の形態（１０）のフ
ローチャートである。（Ａ）は定期的なＰＩＮＧ送出に
よるＡＲＰテーブルのクリアを防止である。 Ｓ１；ブルータＢＲ１に対して、ＩＰルーティング関連
ＭＩＢを送出し、接続ネットワークを確認する。ここで
は、サブネット１〜４が接続されていることが確認で
き、接続ネットワークテーブルＴ１３を作成する。FIG. 22 is a flowchart of the embodiment (10) of the present invention. (A) is to prevent clearing of the ARP table due to periodic PING transmission. S1: Send an IP routing-related MIB to the brouter BR1 and check the connection network. Here, it can be confirmed that the subnets 1 to 4 are connected, and the connection network table T13 is created.

【００９２】Ｓ２；接続ネットワークテーブルＴ１３を
もとに、ＰＩＮＧ送出テーブルＴ１４を作成する。 Ｓ３；設定されているサブネットにブロードキャストで
ＰＩＮＧを送出し、タイマを設定し、Ｓ２へ戻る。S2: A PING transmission table T14 is created based on the connection network table T13. S3: PING is transmitted by broadcast to the set subnet, a timer is set, and the process returns to S2.

【００９３】このようにタイマがタイムアウトとなる都
度、ブロードキャストでＰＩＮＧを送出し、ＡＲＰテー
ブルＴ１１−Ｎｉ、Ｔ１１−ＢＲｉのクリアを防止す
る。（Ｂ）はルート検索実施時のＡＲＰテーブルＴ１１
−Ｎｉ、Ｔ１１−ＢＲｉの作成フローチャートである。As described above, each time the timer times out, a PING is transmitted by broadcast to prevent the ARP tables T11-Ni and T11-BRi from being cleared. (B) is an ARP table T11 at the time of executing a route search.
It is a flowchart for creating -Ni, T11-BRi.

【００９４】Ｓ１、Ｓ２；は（Ａ）と同じ処理である。 Ｓ３；；ＰＩＮＧ送出テーブルＴ１４に設定された全て
のサブネットに対してブロードキャストでＰＩＮＧを送
出する。S1 and S2; are the same processing as in (A). S3; Broadcast PING to all subnets set in the PING transmission table T14.

【００９５】かかる処理により、各ルータにネットワー
クに収容されたノードのＡＲＰテーブルＴ１１−Ｎｉ、
Ｔ１１−ＢＲｉが作成される。With this processing, the ARP table T11-Ni of the node accommodated in the network in each router,
T11-BRi is created.

【００９６】[0096]

【発明の効果】本発明によれば、ＳＮＭＰプロトコルに
よるネットワーク管理において、エージェントから送出
したトラップの受信確認をエージェントが行なうことに
より、精度良くネットワーク管理を行なうことができ
る。According to the present invention, in the network management based on the SNMP protocol, the agent can confirm the reception of the trap sent from the agent, thereby performing the network management with high accuracy.

【００９７】また、ＭＩＢを収集するとき、一括ＭＩＢ
テーブルを設定することにより、１ＭＩＢで複数ＭＩＢ
を収集したり、ノードの追加、機能の追加等に対して、
追加マネージャを起動し、負荷分散を行ない効率的なネ
ットワーク管理を行なうことができる。When collecting MIBs, collective MIBs are used.
By setting a table, multiple MIBs can be set for one MIB
To collect information, add nodes, add functions, etc.
By starting the additional manager, load distribution can be performed and efficient network management can be performed.

【００９８】さらに、バックアップマネージャを設定す
ることにより、ネットワーク管理の信頼度を高めること
ができる。そして、ＩＰアドレスとＩＰ以外のアドレス
の対応をとることにより、ベンダを意識しないネットワ
ークサービスを提供することが可能となる。Further, by setting a backup manager, the reliability of network management can be increased. Then, by associating IP addresses with addresses other than IP, it becomes possible to provide network services that are not aware of vendors.

【図面の簡単な説明】[Brief description of the drawings]

【図１】 本発明の原理を説明する図FIG. 1 illustrates the principle of the present invention.

【図２】 本発明の実施の形態（１）を説明する図FIG. 2 illustrates an embodiment (1) of the present invention.

【図３】 本発明の実施の形態（１）の動作シーケンスFIG. 3 is an operation sequence according to the embodiment (1) of the present invention.

【図４】 本発明の実施の形態（２）を説明する図（そ
の１）FIG. 4 is a view for explaining an embodiment (2) of the present invention (part 1);

【図５】 本発明の実施の形態（２）を説明する図（そ
の１）FIG. 5 is a view for explaining an embodiment (2) of the present invention (part 1)

【図６】 本発明の実施の形態（２）の動作シーケンスFIG. 6 shows an operation sequence according to the embodiment (2) of the present invention.

【図７】 本発明の実施の形態（３）を説明する図FIG. 7 illustrates an embodiment (3) of the present invention.

【図８】 本発明の実施の形態（３）を動作シーケンスFIG. 8 shows an operation sequence according to the embodiment (3) of the present invention.

【図９】 本発明の実施の形態（４）を説明する図FIG. 9 illustrates an embodiment (4) of the present invention.

【図１０】 本発明の実施の形態（４）の動作シーケン
スFIG. 10 shows an operation sequence according to the embodiment (4) of the present invention.

【図１１】 本発明の実施の形態（５）を説明する図FIG. 11 illustrates an embodiment (5) of the present invention.

【図１２】 本発明の実施の形態（５）の動作シーケン
スFIG. 12 shows an operation sequence according to the embodiment (5) of the present invention.

【図１３】 本発明の実施の形態（６）を説明する図FIG. 13 is a diagram illustrating Embodiment (6) of the present invention.

【図１４】 本発明の実施の形態（６）の動作シーケン
スFIG. 14 is an operation sequence according to the embodiment (6) of the present invention.

【図１５】 本発明の実施の形態（７）を説明する図
（その１）FIG. 15 is a view for explaining an embodiment (7) of the present invention (part 1)

【図１６】 本発明の実施の形態（７）を説明する図
（その２）FIG. 16 is a view for explaining an embodiment (7) of the present invention (part 2)

【図１７】 本発明の実施の形態（７）のフローチャー
トFIG. 17 is a flowchart of the embodiment (7) of the present invention.

【図１８】 本発明のルート検索に使用するテーブルFIG. 18 is a table used for a route search according to the present invention.

【図１９】 本発明の実施の形態（８）のフローチャー
トFIG. 19 is a flowchart of the embodiment (8) of the present invention.

【図２０】 本発明の実施の形態（９）のフローチャー
トFIG. 20 is a flowchart of the embodiment (9) of the present invention.

【図２１】 本発明の実施の形態（１０）を説明する図FIG. 21 illustrates an embodiment (10) of the present invention.

【図２２】 本発明の実施の形態（１０）のフローチャ
ートFIG. 22 is a flowchart of the embodiment (10) of the present invention.

【図２３】 従来例を説明する図FIG. 23 illustrates a conventional example.

【符号の説明】[Explanation of symbols]

１００ ネットワーク Ｍ１、Ｍ２ マネージャ Ｎ１〜Ｎｘ ノード Ｒ ルータ ＢＲ ブルータ Ｔ１ 送信管理テーブル Ｔ２−１、Ｔ２−２ 一括ＭＩＢテーブル Ｔ３ ノード管理テーブル Ｔ４ 移管ノードテーブル Ｔ５ 管理対象外ノードテーブル Ｔ６ マネージャ管理テーブル Ｔ７ プロセス管理テーブル Ｔ８ バックアップマネージャテーブル Ｔ９ 検索ノードテーブル Ｔ１０、Ｔ１２ ルート検索テーブル Ｔ１１−Ｎｉ、Ｔ１１−ＢＲｉ ＡＲＰテーブル Ｔ１３ 接続ネットワークテーブル Ｔ１４ ＰＩＮＧ送出テーブル 100 Network M1, M2 Manager N1 to Nx Node R Router BR Brouter T1 Transmission Management Table T2-1, T2-2 Batch MIB Table T3 Node Management Table T4 Transfer Node Table T5 Unmanaged Node Table T6 Manager Management Table T7 Process Management Table T8 Backup manager table T9 Search node table T10, T12 Route search table T11-Ni, T11-BRi ARP table T13 Connection network table T14 PING transmission table

Claims (10)

【特許請求の範囲】[Claims] 【請求項１】 マネージャとエージェントからなり、単
純ネットワーク管理プロトコル（ＳＮＭＰ）で管理され
るネットワークにおいて、 前記エージェントはトラップを送信するとき、該トラッ
プのマネージャにおける受信確認が必要か否かを判定
し、 受信確認が必要なトラップに対応するトラップ監視タイ
マを起動し、 該トラップをマネージャに送信し、 前記トラップ監視タイマの経過時間を監視し、 前記マネージャからの該トラップの応答を受信し、 前記トラップ監視タイマのタイムアウト前に、該トラッ
プの応答受信したときは、前記トラップ受信タイマを解
除し、 該トラップの応答受信前に、前記トラップ監視タイマが
タイムアウトとなった場合は、該トラップを再送するこ
とを特徴とするネットワーク管理方法。1. In a network comprising a manager and an agent and managed by a simple network management protocol (SNMP), when transmitting a trap, the agent determines whether or not acknowledgment of the trap by the manager is necessary, Activate a trap monitoring timer corresponding to a trap requiring acknowledgment, transmit the trap to a manager, monitor the elapsed time of the trap monitoring timer, receive a response to the trap from the manager, If the response to the trap is received before the timer times out, the trap reception timer is canceled.If the trap monitoring timer times out before the response to the trap is received, the trap is retransmitted. Characteristic network management method. 【請求項２】 請求項１に記載のネットワーク管理方法
において、 前記マネージャは、一括管理情報ベースで収集する複数
の管理情報ベースを管理情報ベース群として編集して、
前記エージェントに通知し、 前記エージェントは受信した一括管理情報ベースを一括
管理情報ベーステーブルに登録し、 前記エージェントは前記マネージャからの一括管理情報
ベース要求を受信したとき、前記一括管理情報ベーステ
ーブルを参照して、管理情報ベースを一括して送信する
ことを特徴とするネットワーク管理方法。2. The network management method according to claim 1, wherein the manager edits a plurality of management information bases collected in a collective management information base as a management information base group,
Notifying the agent, the agent registers the received collective management information base in a collective management information base table, and the agent refers to the collective management information base table when receiving the collective management information base request from the manager. And transmitting the management information base collectively. 【請求項３】 請求項１に記載のネットワーク管理方法
において、 追加マネージャは、稼働中の前記マネージャにマネージ
ャ追加情報を送信し、 マネージャ追加情報を受信した稼働中の前記マネージャ
は、前記追加マネージャのサブネットを識別し、該サブ
ネットに属する管理対象のノードの情報を前記追加マネ
ージャに送信し、 稼働中の前記マネージャは前記追加マネージャの管理対
象のノードの管理情報の収集を停止し、前記追加マネー
ジャは管理対象のノードの管理情報の収集を開始し、 前記追加マネージャがノードの異常を検出した場合は、
該情報を元の管理マネージャに通知することを特徴とす
るネットワーク管理方法。3. The network management method according to claim 1, wherein the additional manager transmits manager additional information to the operating manager, and the operating manager that has received the manager additional information is a manager of the additional manager. Identifying the subnet, transmitting information of the managed node belonging to the subnet to the additional manager, the operating manager stops collecting management information of the managed node of the additional manager, and the additional manager Start collecting the management information of the managed node, and if the additional manager detects a node error,
A network management method, wherein said information is notified to an original management manager. 【請求項４】 請求項１に記載のネットワーク管理方法
において、 稼働中の前記マネージャは追加ノードが有るか否かを判
定し、 追加ノードがあり、且つ、稼働中の前記マネージャの監
視対象ノード数が所定の値を超過した場合は、稼働中の
前記マネージャから追加マネージャを起動し、 追加された監視対象ノードは前記追加マネージャで監視
することを特徴とするネットワーク管理方法。4. The network management method according to claim 1, wherein the operating manager determines whether or not there is an additional node, and the number of monitored nodes of the manager that has an additional node and is operating. The network management method characterized in that, when the value exceeds a predetermined value, an additional manager is started from the operating manager, and the added monitoring target node is monitored by the additional manager. 【請求項５】 請求項１に記載のネットワーク管理方法
において、 稼働中の前記マネージャは監視機能の追加が有るか否か
を判定し、 追加監視機能がある場合には、追加マネージャを起動
し、 追加された監視機能を持つノードを前記追加マネージャ
で監視することを特徴とするネットワーク管理方法。5. The network management method according to claim 1, wherein the operating manager determines whether or not a monitoring function is added, and activates the additional manager if the monitoring function is provided, A network management method, wherein a node having an added monitoring function is monitored by the additional manager. 【請求項６】 請求項１に記載のネットワーク管理方法
において、 バックアップマネージャは、バックアップ対象マネージ
ャにバックアップとしての稼働開始を通知し、 前記バックアップ対象マネージャは監視対象ノードを前
記バックアップマネージャに通知し、 前記バックアップ対象マネージャに異常が発生した場
合、前記バックアップマネージャで監視を行なうことを
特徴とするネットワーク管理方法。6. The network management method according to claim 1, wherein the backup manager notifies the backup target manager of the start of operation as a backup, wherein the backup target manager notifies the backup manager of a monitored node. A network management method characterized in that when an error occurs in a backup target manager, monitoring is performed by the backup manager. 【請求項７】 請求項１に記載のネットワーク管理方法
において、 ＩＰプロトコル以外のプロトコルのルート確認を行なう
とき、次ルータのＩＰ以外のプロトコルを管理情報ベー
スにより収集し、 エコー要求コマンドにより得たＩＰアドレスのノードか
ら得た、ＩＰ以外のプロトコルアドレスを比較し、 ＩＰ以外のプロトコルルートを確認することを特徴とす
るネットワーク管理方法。7. The network management method according to claim 1, wherein when confirming a route of a protocol other than the IP protocol, a protocol other than the IP of the next router is collected by a management information base, and the IP obtained by the echo request command is obtained. A network management method comprising comparing protocol addresses other than IP obtained from an address node and confirming a protocol route other than IP. 【請求項８】 請求項１に記載のネットワーク管理方法
において、 ＩＰプロトコル以外のプロトコルのルート確認を行なう
とき、次ルータのＩＰ以外のプロトコルを管理情報ベー
スにより収集し、 ＡＲＰ(Address Resolution Protocol) 機能関連管理情
報ベースより得たＩＰアドレスのノードに要求して得た
ＩＰ以外のプロルアドレスを比較し、 ＩＰ以外のプロトコルルートを確認することを特徴とす
るネットワーク管理方法。8. The network management method according to claim 1, wherein when a route other than the IP protocol is confirmed, a protocol other than the IP of the next router is collected by a management information base, and an ARP (Address Resolution Protocol) function is provided. A network management method comprising comparing a non-IP protocol address obtained by requesting a node of an IP address obtained from a related management information base to confirm a protocol route other than the IP. 【請求項９】 請求項１に記載のネットワーク管理方法
において、 ＩＰＸプロトコルのルート確認を行なうとき、ＩＰＸ関
連管理情報ベースからＩＰＸアドレスとＭＡＣ(Media A
ccess Control)アドレス情報を収集し、 ＡＲＰ機能関連情報管理ベースより得たＩＰアドレスと
ＭＡＣアドレスを比較し、 ＩＰＸプロトコルルートを確認することを特徴とするネ
ットワーク管理方法。9. The network management method according to claim 1, wherein when confirming a route of the IPX protocol, an IPX address and a MAC (Media A
ccess Control) A network management method comprising collecting address information, comparing an IP address obtained from an ARP function related information management base with a MAC address, and confirming an IPX protocol route. 【請求項１０】 請求項８、９に記載のネットワーク管
理方法において、 ポーリングを送信し、ＡＲＰ情報を保持することを特徴
とするネットワーク管理方法。10. The network management method according to claim 8, wherein polling is transmitted and ARP information is held.