JP2000066978A - Network management information collection system, network management device to be used for the system and node to be managed - Google Patents
Network management information collection system, network management device to be used for the system and node to be managedInfo
- Publication number
- JP2000066978A JP2000066978A JP10238640A JP23864098A JP2000066978A JP 2000066978 A JP2000066978 A JP 2000066978A JP 10238640 A JP10238640 A JP 10238640A JP 23864098 A JP23864098 A JP 23864098A JP 2000066978 A JP2000066978 A JP 2000066978A
- Authority
- JP
- Japan
- Prior art keywords
- mib
- difference
- agent
- manager
- network management
- 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.)
- Granted
Links
Landscapes
- Maintenance And Management Of Digital Transmission (AREA)
- Telephonic Communication Services (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Communication Control (AREA)
Abstract
Description
【０００１】本発明は、複数の管理対象ノード（以下、
エージェントともいう）と少なくとも一つのネットワー
ク管理装置（以下、マネージャともいう）からなるネッ
トワークのネットワーク管理方式に関し、特にネットワ
ーク管理プロトコル（SimpleNetwork Management Proto
col：以下、ＳＮＭＰという）を用いて管理情報ベース
（Management Information Base：以下、ＭＩＢとい
う）の収集を行うネットワーク管理情報収集方式および
それに用いるネットワーク管理装置ならびに管理対象ノ
ードに関する。[0001] The present invention provides a plurality of managed nodes
The present invention relates to a network management method for a network comprising an agent) and at least one network management device (hereinafter, also referred to as a manager), and particularly to a network management protocol (Simple Network Management Protocol).
The present invention relates to a network management information collection method for collecting a management information base (hereinafter, referred to as MIB) using a col (hereinafter, referred to as SNMP), a network management apparatus used for the method, and a managed node.
【０００２】[0002]
【従来の技術】従来、複数のエージェントと少なくとも
一つのマネージャからなるネットワークにおいて、ＳＮ
ＭＰを用いてマネージャからエージェントで保持してい
るＭＩＢを収集する場合のＭＩＢ収集方法としては、 「Get-Request」 「Get-Next-Request」 「Get-Bulk-Request」（ＳＮＭＰｖ２の仕様）を用い
てマネージャからエージェントにＭＩＢの値を問い合わ
せるコネクション形式の方法と、 「Trap」を用いてエージェントからマネージャに対し
て自立的に通知するコネクションレス形式の方法があっ
た。2. Description of the Related Art Conventionally, in a network including a plurality of agents and at least one manager, SN
As the MIB collection method when the MIB held by the agent is collected from the manager using MP, “Get-Request”, “Get-Next-Request”, and “Get-Bulk-Request” (specification of SNMPv2) are used. There is a connection type method in which the manager inquires the value of the MIB from the agent to the agent, and a connectionless type method in which the agent notifies the manager independently using "Trap".
【０００３】「Get-Request」は、マネージャで収集
したいＭＩＢを指定してエージェントに問い合わせる方
法であり、たとえば１０００個のＭＩＢをエージェント
が実装していたとすると、マネージャはＭＩＢを収集す
る度にエージェントに対して１０００回の問い合わせを
行う必要があり、以下の問題が発生した。・マネージャ
とエージェント間の通信量が多くなり、それと同じ通信
路を共有している他の通信を妨げることや、しいては長
時間通信帯域を占有してしまうことがある。 ・管理対象ノード数が多いと、全体のＭＩＢを収集する
のに多大な時間がかかる。 ・管理項目数をさらに増やそうとしたとき、ＭＩＢの収
集時間もさらに増えてしまうので安易に増やすことがで
きない。 ・マネージャとエージェント間で１０００回の問い合わ
せを行わなければならないので、その間マネージャのエ
ージェントに対する他のオペレーションが困難になりオ
ペレータの負担になる。 ・マネージャおよびエージェントは、１０００回の問い
合わせに対する処理を行う必要があるので、それぞれそ
の分の処理負荷がかかってしまう。またそれの是正とし
て高性能な機器を求めようとするとその分、高価な機器
を購入する必要が発生しユーザの負担がかかる。 ・マネージャがエージェントの状態をリアルタイムにオ
ペレータに伝えるためにエージェントに対してポーリン
グ的にＭＩＢを収集すると、その間通信帯域の占有およ
び処理負荷がかかってしまいネットワーク管理のために
ネットワークヘ悪影響を与えてしまう。[0003] "Get-Request" is a method of inquiring an agent by specifying an MIB to be collected by a manager. For example, if an agent has implemented 1000 MIBs, the manager sends a request to the agent every time the MIB is collected. Inquiry must be performed 1000 times, and the following problem occurs. The communication volume between the manager and the agent increases, which may hinder other communication sharing the same communication path, and may occupy the communication band for a long time. If the number of managed nodes is large, it takes a lot of time to collect the entire MIB. If the number of management items is to be further increased, the MIB collection time is further increased, so that the number of management items cannot be easily increased. Since 1000 inquiries must be made between the manager and the agent, other operations on the agent of the manager become difficult during that time, and the burden on the operator is increased. Since the manager and the agent need to perform processing for 1000 inquiries, the processing load increases accordingly. In order to correct this, if a high-performance device is to be sought, it is necessary to purchase an expensive device, and the burden on the user is increased. If the manager collects MIBs by polling the agent in order to inform the operator in real time of the state of the agent, the communication band is occupied and the processing load is applied during that period, which adversely affects the network for network management. .
【０００４】「Get-Next-Request」は、マネージャで
ＭＩＢを指定してエージェントに対して問い合わせ、エ
ージェントはそのＭＩＢから名前が辞書順で次に実装さ
れているＭＩＢを探し出してそれ毎に答える方法であ
り、マネージャがエージェントのＭＩＢ実装状態を認識
していないときなどに用いる方法である。この方法も同
様の例として１０００個のＭＩＢをマネージャに個々に
収集する必要があり「Get-Request」同様の問題が発生
する。[0004] "Get-Next-Request" is a method in which a manager specifies an MIB and inquires an agent, and the agent finds the next implemented MIB in dictionary order from the MIB and answers each time. This method is used when the manager does not recognize the MIB implementation state of the agent. In this method, as a similar example, 1000 MIBs need to be individually collected by the manager, and a problem similar to “Get-Request” occurs.
【０００５】「Get-Burk-Request」は、マネージャで
収集したいＭＩＢを複数個まとめてエージェントから収
集できる方法であるが、収集するデータ量は結局同様の
例として１０００個になるため、この方法でも通信帯域
の占有および処理負荷の増加を招くことが問題となる。[0005] "Get-Burk-Request" is a method in which a manager can collect a plurality of MIBs to be collected and collect them from an agent. However, the amount of data to be collected becomes 1000 as a similar example. The problem is that the communication band is occupied and the processing load is increased.
【０００６】「Trap」は、エージェントからマネージ
ャに自立的な状態変化（ＭＩＢの状態変化も含まれる）
を通知する方法であるが以下の問題が発生した。 ・コネクションレス方式であるので、エージェントから
マネージャヘの到達確認が行われず通信経路上で紛失す
る可能性がある。またその紛失があったときの救済方式
も実現方式は存在するがその機能のインプリメントを行
う必要が発生し、マネージャおよびエージェントの開発
ベンダーに負担がかかってしまう。 ・単位時間に状態変化が多発するとその分エージェント
からマネージャに対する「Trap」通知の件数が増加して
しまい通信帯域の圧迫および、マネージャおよびエージ
ェントの処理負荷の増加が発生してしまう。また「しき
い値」による抑止または通知をマネージャおよびエージ
ェントにインプリメントしようとすると、それぞれの開
発ベンダーに負担がかかってしまう。 ・「Trap」をＭＩＢの項目数分マネージャおよびエージ
ェントでインプリメントする必要があるので（たとえば
ＭＩＢが１０００個だとTrapも１０００個必要）それぞ
れの開発ベンダーにそれを開発する負担が発生する。"Trap" is a state change that is independent from the agent to the manager (including a state change of the MIB).
The following problem has occurred. -Since the connectionless method is used, the arrival from the agent to the manager is not performed, and there is a possibility that the agent is lost on the communication path. Although there is a realization method for a remedy method in the event of the loss, it is necessary to implement the function, and a burden is placed on the manager and the agent development vendor. If the state change occurs frequently in the unit time, the number of “Trap” notifications from the agent to the manager increases by that much, and the communication band becomes tight and the processing load on the manager and the agent increases. Further, if the manager and the agent try to implement the suppression or the notification by the "threshold", the burden is placed on each development vendor. Since “Trap” needs to be implemented by the manager and the agent for the number of items of the MIB (for example, if the number of MIBs is 1,000, the number of traps also needs to be 1000), so that each development vendor has a burden of developing it.
【０００７】[0007]
【発明が解決しようとする課題】本発明は、マネージャ
とエージェント間でＭＩＢの収集量および収集時間がか
かってしまっていた従来のＭＩＢ収集方式に対して、収
集量および収集時間の短縮化がはかれるＭＩＢ収集方式
を提供することを課題とする。さらに、本発明は、ＳＮ
ＭＰｖ１およびＳＮＭＰｖ２双方に実装できるＭＩＢ収
集方式を提供することを課題とする。本発明は、以上に
述べた課題を達成するためのネットワーク管理情報収集
方式を提供することを目的とする。SUMMARY OF THE INVENTION According to the present invention, the collection amount and the collection time are shortened in comparison with the conventional MIB collection method which requires the collection amount and the collection time of the MIB between the manager and the agent. It is an object to provide an MIB collection method. Furthermore, the present invention
An object of the present invention is to provide an MIB collection method that can be implemented in both MPv1 and SNMPv2. An object of the present invention is to provide a network management information collection method for achieving the above-mentioned object.
【０００８】[0008]
【課題を解決するための手段】本発明は、上記課題を解
決するために、ＳＮＭＰでのネットワーク管理情報収集
方式において、ネットワーク管理装置および管理対象ノ
ードとその間の通信回線を備えており、インタフェース
として用いるＭＩＢが定義される。ネットワーク管理装
置は、通信回線と、下位プロトコルスタックと、ＳＮＭ
Ｐ処理部と、本発明のネットワーク管理情報を差分で収
集できるＳＮＭＰマネージャ制御部と、ＭＩＢテーブル
記憶部と、ＭＩＢテーブルと、それを表示するネットワ
ーク管理情報表示画面を備えている。管理対象ノード
は、通信回線と、下位プロトコルスタックと、ＳＮＭＰ
処理部と、本発明のネットワーク管理情報を差分で収集
応答できるＳＮＭＰエージェント制御部と、ＭＩＢテー
ブル記憶部と、ＭＩＢテーブルを備えている。さらに、
ＭＩＢは、ネットワーク管理情報をマネージャがエージ
ェントから差分で収集できる「GetNext」収集モードの
定義と、ＭＩＢの差分状態をマネージャがエージェント
から参照できるＭＩＢ差分状態の定義を備えている。SUMMARY OF THE INVENTION In order to solve the above-mentioned problems, the present invention provides a network management information collection method using SNMP, which comprises a network management device, a managed node, and a communication line between them. The MIB to be used is defined. The network management device includes a communication line, a lower protocol stack, an SNM,
A P processing unit, an SNMP manager control unit capable of collecting network management information of the present invention by a difference, an MIB table storage unit, an MIB table, and a network management information display screen for displaying the same are provided. The managed node includes a communication line, a lower protocol stack, an SNMP
The system includes a processing unit, an SNMP agent control unit that can collect and respond to network management information of the present invention with a difference, an MIB table storage unit, and an MIB table. further,
The MIB includes a definition of a “GetNext” collection mode in which the manager can collect network management information from the agent by a difference, and a definition of an MIB difference state in which the manager can refer to the difference state of the MIB from the agent.
【０００９】[0009]
【作用】本発明では、マネージャがエージェントからＭ
ＩＢを収集するとき、ＭＩＢの差分のみを収集ればよい
ので、ＭＩＢの収集量および収集時間を短縮化できる。
また、ＭＩＢ定義のインタフェースを用いることで、Ｓ
ＮＭＰｖ１およびＳＮＭＰｖ２を用いたそれぞれのネッ
トワーク管理システムに実装が可能となる。According to the present invention, the manager sends M
When collecting IBs, only the difference between MIBs needs to be collected, so that the collection amount and collection time of MIBs can be reduced.
In addition, by using the interface of the MIB definition, S
It can be implemented in respective network management systems using NMPv1 and SNMPv2.
【００１０】[0010]
【発明の実施の形態】以下、図面を用いて本発明にかか
るネットワーク管理システムの実施の形態を説明する。
図１を用いて、本発明にかかるネットワーク管理システ
ムのシステム構成例を説明する。図１は、本発明のネッ
トワーク管理システムのシステム構成例を示すブロック
図である。ネットワーク管理システムは、少なくとも一
つのネットワーク管理装置（マネージャ）１０と、複数
の管理対象ノード（エージェント）２０を通信回線３０
で接続して構成される。ここではネットワークの構成
は、スター型のネットワークトポロジーで示してある
が、本発明におけるネットワークは必ずしもスター型に
限定されるべきものではなく、メッシュ型や、バス型、
リング型をも含むものである。また、エージェントは管
理対象ノードに内蔵されるものを示してあるが、外付け
の機器をＳＮＭＰで管理するための代理エージェント方
式も含むものである。DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of a network management system according to the present invention will be described below with reference to the drawings.
An example of a system configuration of a network management system according to the present invention will be described with reference to FIG. FIG. 1 is a block diagram showing a system configuration example of the network management system of the present invention. The network management system connects at least one network management device (manager) 10 and a plurality of managed nodes (agents) 20 to a communication line 30.
It is configured by connecting with. Here, the configuration of the network is shown by a star type network topology, but the network in the present invention is not necessarily limited to the star type, and may be a mesh type, a bus type,
This includes a ring type. Although the agent is shown as being built in the managed node, it also includes a proxy agent system for managing external devices by SNMP.
【００１１】マネージャ（ネットワーク管理装置）１０
は、図３に示す構成例を備えており、エージェント２０
に対して図２に示すシーケンスおよび図５に示すＭＩＢ
を通信回線３０を用いて本発明の実施を行う手段を備え
ている。A manager (network management device) 10
Has the configuration example shown in FIG.
The sequence shown in FIG. 2 and the MIB shown in FIG.
Means for implementing the present invention using the communication line 30.
【００１２】エージェント２０は図４に示す構成例を備
えており、マネージャ１０に対して図２に示すシーケン
スおよび図５に示すＭＩＢを通信回線３０を用いて本発
明の実施を行う手穎を備えている。The agent 20 has a configuration example shown in FIG. 4, and has a method for executing the present invention by using the communication line 30 for the sequence shown in FIG. 2 and the MIB shown in FIG. ing.
【００１３】図２を用いて、マネージャ１０とエージェ
ント２０間でＭＩＢの設定／参照を実現するＳＮＭＰの
プロトコル方式を説明する。図２は、ＳＮＭＰのプロト
コル方式図である。本発明では、マネージャ１０とエー
ジェント２０間で本シーケンスを用いてネットワーク管
理情報収集方式を実現する。Referring to FIG. 2, a description will be given of an SNMP protocol for realizing MIB setting / reference between the manager 10 and the agent 20. FIG. 2 is a diagram showing a protocol scheme of SNMP. In the present invention, a network management information collection method is realized between the manager 10 and the agent 20 using this sequence.
【００１４】第一のシーケンスＰ１は、マネージャから
エージェントに対して所定のＭＩＢの取出要求「Get-Req
uest」を送出し、エージェントがこれに応えて対応する
ＭＩＢの取出応答「Get-Responce」を送出するプロトコル
である。In the first sequence P1, a request for extracting a predetermined MIB from the manager to the agent "Get-Req
uest ", and the agent responds with a corresponding MIB retrieval response" Get-Responce ".
【００１５】第２のシーケンスＰ２は、マネージャから
エージェントに対して所定のＭＩＢの次のＭＩＢの取出
要求「Get-Next-Request」を送出し、エージェントがこれ
に応えて順次ＭＩＢの取出応答「Get-Responce」を送出す
るプロトコルである。In the second sequence P2, the manager sends a request to retrieve the next MIB after the predetermined MIB "Get-Next-Request" to the agent, and the agent responds to the request to retrieve the MIB "Get-Next-Request" sequentially. -Responce ".
【００１６】第３のシーケンスＰ３は、複数のＭＩＢを
取得する場合のプロトコルで、マネージャからエージェ
ントに対して複数のＭＩＢの取出要求「Get-Bulk-Reques
t」を送出し、エージェントがこれに応えて複数のＭＩＢ
の取出応答「Responce」を送出するプロトコルである。The third sequence P3 is a protocol for acquiring a plurality of MIBs, and the manager requests the agent to retrieve a plurality of MIBs “Get-Bulk-Reques”.
t ", and the agent responds with multiple MIBs
This is a protocol for sending out response "Responce".
【００１７】第４のシーケンスＰ４は、エージェントに
対してマネージャの要求する値の設定を要求する場合の
プロトコルで、マネージャからエージェントに対して「S
et-Request」を送出し、エージェントがこれに応えて要
求「Get-Responce」を送出するプロトコルであり、具体例
としてアラームランプの滅火、回線スピードの改定など
を行う。The fourth sequence P4 is a protocol for requesting the agent to set a value requested by the manager.
et-Request ", and the agent responds to the request" Get-Responce ". Specific examples include extinguishing an alarm lamp and revising a line speed.
【００１８】第５のシーケンスＰ５は、エージェントか
らマネージャに対して自立的に報告する場合のプロトコ
ルで、エージェントから「Trap」を送出するプロトコルで
あり、障害発生情報などを送出する。The fifth sequence P5 is a protocol for the agent to independently report to the manager, and is a protocol for transmitting "Trap" from the agent, and transmits failure occurrence information and the like.
【００１９】この実施の形態では、マネージャからの
「Get-Next-Request」Ｐ２に対してエージェントがＭＩ
Ｂの差分収集に応答する方式を説明するが、必ずしもそ
れに限ったことではなく、「Get-Bulk-Request」Ｐ３に
対してエージェントがＭＩＢの差分収集に応答する方式
も含むものである。In this embodiment, the agent responds to the "Get-Next-Request" P2 from the manager by the MI.
A method of responding to the difference collection of B will be described. However, the method is not necessarily limited thereto, and includes a method of the agent responding to the difference collection of MIB in response to “Get-Bulk-Request” P3.
【００２０】図３を用いて、本発明に使用するネットワ
ーク管理装置１０の構成を説明する。図３は、ネットワ
ーク管理装置（マネージャ）１０の構成例を示すブロッ
ク図である。ネットワーク管理装置１０は、下位プロト
コルスタック１１と、ＳＮＭＰ処理部１２と、ＳＮＭＰ
マネージャ制御部１３と、画面制御部１４と、ネットワ
ーク管理情報表示画面１５と、ＭＩＢテーブル記憶部１
６とを有して構成される。The configuration of the network management device 10 used in the present invention will be described with reference to FIG. FIG. 3 is a block diagram illustrating a configuration example of the network management device (manager) 10. The network management apparatus 10 includes a lower protocol stack 11, an SNMP processing unit 12, an SNMP
Manager control unit 13, screen control unit 14, network management information display screen 15, MIB table storage unit 1
6.
【００２１】下位プロトコルスタック１１は、ハードウ
エアとソフトウエアから構成されて下位インタフェース
を司り、エージェントとの通信を行う通信回線３０に接
続される。ＳＮＭＰ処理部１２は、ソフトウエアによっ
て構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰマネ
ージャ制御部１３は、本発明のネットワーク管理情報収
集方式を制御する。画面制御部１４は、ネットワーク管
理装置１０の画面を制御する。ネットワーク管理情報表
示画面１５は、管理対象ノードの状態を表示する。ＭＩ
Ｂテーブル記憶部１６は、管理対象ノードのＭＩＢの記
憶制御を行い、ＭＩＢ情報の記憶媒体として用いるＭＩ
Ｂテーブル１６１が設けられる。The lower protocol stack 11 is composed of hardware and software, controls a lower interface, and is connected to a communication line 30 for communicating with an agent. The SNMP processing unit 12 is configured by software and performs an SNMP transmission / reception process. The SNMP manager control unit 13 controls the network management information collection method of the present invention. The screen control unit 14 controls the screen of the network management device 10. The network management information display screen 15 displays the status of the managed node. MI
The B table storage unit 16 controls the storage of the MIB of the management target node, and uses the MIB used as a storage medium of the MIB information.
A B table 161 is provided.
【００２２】図４を用いて、エージェント２０の構成を
説明する。図４は、管理対象ノード（エージェント）２
０の構成例を示すブロック図である。管理対象ノード２
０は、下位プロトコルスタック２１と、ＳＮＭＰ処理部
２２と、ＳＮＭＰエージェント制御部２３と、ＭＩＢテ
ーブル記憶部２４とを有して構成される。The configuration of the agent 20 will be described with reference to FIG. FIG. 4 shows a managed node (agent) 2
FIG. 4 is a block diagram showing an example of the configuration of 0. Managed node 2
0 includes a lower-order protocol stack 21, an SNMP processing unit 22, an SNMP agent control unit 23, and an MIB table storage unit 24.
【００２３】下位プロトコルスタック２１は、ハードウ
エアとソフトウエアから構成されて下位インタフェース
を司り、マネージャとの通信を行う通信回線３０に接続
される。ＳＮＭＰ処理部２２は、ソフトウエアによって
構成され、ＳＮＭＰ送受信処理を行う。ＳＮＭＰエージ
ェント制御部２３は、本発明のネットワーク管理情報収
集方式を制御する。ＭＩＢテーブル記憶部２４は、ＭＩ
Ｂの記憶制御を行い、ＭＩＢ情報の記憶媒体として用い
るＭＩＢテーブル２４１を備えている。The lower protocol stack 21 is composed of hardware and software, controls a lower interface, and is connected to a communication line 30 for communicating with a manager. The SNMP processing unit 22 is configured by software and performs an SNMP transmission / reception process. The SNMP agent control unit 23 controls the network management information collection method of the present invention. The MIB table storage unit 24 stores
A MIB table 241 is provided for performing storage control of B and used as a storage medium for MIB information.
【００２４】ここでは、ＭＩＢテーブル記憶部２４およ
びＭＩＢテーブル２４１として示してあるが必ずしもＭ
ＩＢのデータベースとして制御および記憶しているもの
ではなく、メモリデータとして装置固有の制御および記
憶する方式をも含むものである。Although shown here as the MIB table storage unit 24 and the MIB table 241, M
It does not control and store it as an IB database, but also includes a method of controlling and storing it as memory data unique to the device.
【００２５】図５を用いて、本発明で用いるＭＩＢの定
義の例（ＳＮＭＰｖ１）を説明する。ＭＩＢ定義とし
て、エージェントがマネージャにネットワーク管理情報
として見せるべき既存のＭＩＢ情報ＭＩＢ１〜ＭＩＢ４
と、特に本発明で用いる差分収集モード実現用ＭＩＢで
あるＭＩＢ５とＭＩＢ６を備えている。ＭＩＢ５はマネ
ージャからエージェントに対して差分収集モードまたは
標準収集モードの指定または参照を可能とする。ＭＩＢ
６はマネージャからエージェントに対してＭＩＢの差分
状態を参照可能とする。An example of the definition of the MIB used in the present invention (SNMPv1) will be described with reference to FIG. Existing MIB information MIB1 to MIB4 that the agent should show to the manager as network management information as MIB definition
And MIBs 5 and 6, which are MIBs for realizing the difference collection mode used in the present invention. The MIB 5 allows the manager to specify or refer to the difference collection mode or the standard collection mode for the agent. MIB
Reference numeral 6 allows the manager to refer to the difference state of the MIB from the agent.
【００２６】ここではＭＩＢ５とＭＩＢ６は１つのＭＩ
Ｂグループ（ここではＭＩＢ１〜ＭＩＢ４）に対して１
組、差分収集モード実現用にマネージャとエージェント
間の取り決めとして定義した例を示したが、必ずしもそ
れに限ったことではなく、管理対象ノード毎に１組定義
する方式や、差分収集したいＭＩＢのエントリ毎に１組
定義する方式や、さらには管理する側となるマネージャ
毎（マネージャｎ重化用）に１組定義する方式も含むも
のである。また、ここではＳＮＭＰｖ１での定義例を示
しているが必ずしもそれに限ったことではなくＳＮＭＰ
ｖ２での定義方法をも含むものである。Here, MIB5 and MIB6 are one MI
1 for group B (here, MIB1 to MIB4)
In the above, an example is described in which an agreement between a manager and an agent is defined for realizing the difference collection mode. However, the present invention is not limited to this. And a method of defining one set for each manager (for manager n duplication) to be managed. In addition, although the definition example in SNMPv1 is shown here, it is not necessarily limited to that, and the SNMP
The definition method in v2 is also included.
【００２７】図６を用いて、差分収集モードの実行シー
ケンス例を説明する。まず、マネージャは管理対象ノー
ドのＭＩＢを全収集するために、エージェントに対して
シーケンスＳ１に示す「標準収集モード」の指定を行
う。エージェントはそれをトリガにマネージャがそれ以
降の「Get-Next-Request」に対する応答を標準プロトコ
ル仕様での「Get-Responce」で応答してほしいと要求し
ていることが認識できる。ＭＩＢの実装数分繰り返され
るシーケンスＳ２と、ＭＩＢが終了したことを示すシー
ケンスＳ３が終わると、それ以降はＭＩＢの差分のみを
マネージャが収集すれば良いためマネージャはエージェ
ントに対してシーケンスＳ４に示す「差分収集モード」
の指示を行う。エージェントはそれ以降の「Get-Next-R
equest」に対する応答を差分があるＭＩＢだけに限定す
ればよいことを認識できる。定期的な差分収集ではマネ
ージャはまずエージェント側に自立的なＭＩＢの削除が
あったかどうかシーケンスＳ５にて確認を行う。これは
ＭＩＢの削除があったとき「Get-Next」では削除ＭＩＢ
がスキップされるためマネージャがその差分を認識でき
なくなりマネージャのＭＩＢテーフルに削除ＭＩＢが残
ってしまうのを防ぐために行う。その手段は図７，図８
で別途説明する。An example of the execution sequence of the difference collection mode will be described with reference to FIG. First, the manager specifies the "standard collection mode" shown in sequence S1 to the agent in order to collect all MIBs of the managed node. The agent can recognize that, in response to this, the manager requests that a subsequent response to "Get-Next-Request" be responded to by "Get-Responce" in the standard protocol specification. When the sequence S2 repeated for the number of mounted MIBs and the sequence S3 indicating that the MIB has been completed are completed, the manager only needs to collect the MIB differences thereafter. Difference collection mode "
Instructions. The agent will then use Get-Next-R
It can be recognized that the response to "equest" may be limited to only the MIB having a difference. In the periodical difference collection, the manager first checks in sequence S5 whether the agent has independently deleted the MIB. This is when the MIB is deleted, "Get-Next" deletes the MIB.
Is skipped to prevent the manager from recognizing the difference and leaving the deleted MIB in the MIB tail of the manager. The means are shown in FIGS.
Will be described separately.
【００２８】差分のあるＭＩＢ収集はシーケンスＳ６で
の「Get-Next」の繰り返しで実現し、差分ＭＩＢの全収
集終了のマネージャ側認識手段はシーケンスＳ７の「No
-Such-Name」応答があつたことで実現する。これにより
たとえば全くＭＩＢの差分がないときは１回目のシーケ
ンスＳ６ですぐ「No-Such-Name」となり、少ない通信で
マネージャはエージェントの全ＭＩＢ状態を把握するこ
とが可能となり、収集量および収集時間の短縮化をはか
ることができる。MIB collection with a difference is realized by repeating "Get-Next" in sequence S6, and the manager-side recognizing means of completion of collection of all the difference MIBs is "No" in sequence S7.
-Such-Name ”response. Thus, for example, when there is no MIB difference, “No-Such-Name” is immediately obtained in the first sequence S6, and the manager can grasp the state of all MIBs of the agent with a small amount of communication. Can be shortened.
【００２９】ここでは差分があるＭＩＢを応答する方式
を示したが、これに限ったことではなく、ＭＩＢの状態
変化の装置特性に合わせ、変わる可能性のあるＭＩＢだ
けを差分ありとして扱う簡易的な方式や、マネージャか
ら見て差分はないが状態変化によりもとの状態に戻った
ＭＩＢも差分ありとして扱う方式や、例外的に差分が管
理できなくなる状態が発生し、全ＭＩＢを差分ありとし
て扱う方式も含むものである。Here, the method of responding to the MIB having a difference has been described. However, the present invention is not limited to this method, and only the MIB that may change according to the device characteristics of the state change of the MIB is treated as having a difference. There is a method that treats an MIB that has no difference from the manager but returns to the original state due to a state change as having a difference, or a state in which the difference cannot be managed exceptionally. It also includes the method of handling.
【００３０】図７を用いて、マネージャから差分収集す
る周期タイミングの間にＭＩＢの削除があったときの実
行シーケンス例を説明する。ＭＩＢ削除が発生したトリ
ガＳ１１の後にマネージャの定期的な差分収集が発生す
るとマネージャからシーケンスＳ１２のＭＩＢ差分状態
確認要求がありエージェントはＭＩＢの削除があったこ
とをその応答として返答する。マネージャはそれをトリ
ガにマネージャ内ＭＩＢの全削除を行う。これはＭＩＢ
の削除をマネージャが認識する方式の１つの手段であ
り、最初から全収集することでマネージャ内ＭＩＢとエ
ージェント内ＭＩＢの同期をとることができるために行
う。マネージャはＭＩＢの全収集をするため、エージェ
ントに対してシーケンスＳ１４に示す「標準収集モー
ド」の指示を行う。これがないとエージェントは「差分
収集モード」のままの応答形態をとってしまう可能性が
あるため、これを行う。この後マネージャはシーケンス
Ｓ１５、Ｓ１６に示すＭＩＢの全収集を行うことで、エ
ージェントとのＭＩＢ状態の同期をとる。With reference to FIG. 7, an example of an execution sequence when an MIB is deleted during a cycle of collecting the difference from the manager will be described. When periodic difference collection of the manager occurs after the trigger S11 at which MIB deletion has occurred, the manager issues a MIB difference state confirmation request in sequence S12, and the agent replies that MIB has been deleted as a response. The manager uses this as a trigger to delete all MIBs in the manager. This is MIB
This is one of the methods by which the manager recognizes the deletion of the MIB. This is because the MIB in the manager and the MIB in the agent can be synchronized by collecting all of them from the beginning. In order to collect all MIBs, the manager instructs the agent in the "standard collection mode" shown in sequence S14. Without this, the agent may take a response form in the “difference collection mode”, so this is done. Thereafter, the manager synchronizes the MIB state with the agent by collecting all the MIBs shown in the sequences S15 and S16.
【００３１】ここではエージェント側のＭＩＢの削除に
よりマネージャのＭＩＢを全削除しているが、これに限
ったことではなく、削除したＭＩＢをリスト形式でマネ
ージャに見せる方式を採用することで、削除ＭＩＢの同
期をとる方法をも含むものである。また、ここでは、マ
ネージャ内ＭＩＢの全削除をＭＩＢの全収集の前に行っ
ているが、ネットワーク管理仕様として全収集の前の状
態を保持しておきたいときはその順序が逆になる方式を
も含むものである。また、ここではＭＩＢ差分状態のＭ
ＩＢをマネージャから指定して確認する方式を説明して
いるが、本ＭＩＢを差分管理対象となるＭＩＢグループ
の先頭のみまた、は、先頭および最後に定義すること
で、「Get-Next-Request」だけによるＭＩＢ削除のマネ
ージャ側認識を可能とできる方式をも含むものである。Here, the MIB of the manager is entirely deleted by deleting the MIB on the agent side. However, the present invention is not limited to this. By adopting a method of displaying the deleted MIB to the manager in the form of a list, the deleted MIB is deleted. It also includes a method of synchronizing. Further, here, all the MIBs in the manager are deleted before all the MIBs are collected. However, if it is desired to keep the state before the all the MIBs are collected as the network management specification, a method in which the order is reversed is adopted. Is also included. In this case, M in the MIB difference state
The method of confirming by specifying the IB from the manager is described. However, this MIB is defined only at the head of the MIB group to be subjected to difference management, or by defining it at the head and the end, so that "Get-Next-Request" This also includes a method that enables the manager side to recognize the MIB deletion only by using the method.
【００３２】図８はマネージャから差分収集していると
きにＭＩＢの削除があったときの実行シーケンス例を示
す図である。ＭＩＢの削除が発生したトリガＳ２３があ
るとエージェントは差分収集シーケンスＳ２４に対する
応答を「Gen-Error」で応答し、マネージャに差分収集
モードでの応答ができなくなったことをマネージャに認
識させる。以降の処理は図７でのシーケンスＳ１２以降
と同様である。FIG. 8 is a diagram showing an example of an execution sequence when the MIB is deleted while the difference is collected from the manager. When there is a trigger S23 in which the MIB has been deleted, the agent responds with a “Gen-Error” response to the difference collection sequence S24, and causes the manager to recognize that the manager cannot respond in the difference collection mode. Subsequent processing is the same as that of sequence S12 and subsequent steps in FIG.
【００３３】マネージャのＭＩＢ収集フローの例を示す
図９を用いて、マネージャのＭＩＢ収集処理を説明す
る。図９は、図６〜図８に示した実行シーケンスのマネ
ージャ側処理をまとめたフローチャートであり、マネー
ジャとエージェント間の差分収集によるＭＩＢ同期あわ
せを実現するために特にＳＮＭＰマネージャ制御部に有
するものである。マネージャ処理が起動される（Ｓ３
１）と、管理対象エージェントを発見する（Ｓ３２）。
ついでマネージャ内に当該エージェントのＭＩＢがあれ
ばそれを全て削除する（Ｓ３３）。その後当該エージェ
ントに対して図６に示す「xxxGetNextMode=1」をセット
して標準収集モードを指示する（Ｓ３４）。図６に示す
シーケンスＳ２，Ｓ３を繰り返してエージェントからＭ
ＩＢの全てを収集する（Ｓ３５）。当該エージェントの
全てのＭＩＢの収集が終了すると、当該エージェントに
対して図６の「XXXGetNextMode=2」をセットして差分収
集モードを指示する（Ｓ３６）。ついで、当該エージェ
ントに対して図６の「XXXMIBStatus」のGetを送信して
ＭＩＢ差分状態（「XXXMIBStatus」（ＭＩＢ６））を取
得する（Ｓ３７）。取得した「XXXMIBStatus」にＭＩＢ
の削除があるか否かを判断する（Ｓ３８）。The MIB collection process of the manager will be described with reference to FIG. 9 which shows an example of the MIB collection flow of the manager. FIG. 9 is a flowchart summarizing the manager-side processing of the execution sequence shown in FIGS. 6 to 8, and is provided especially in the SNMP manager control unit to realize MIB synchronization by collecting differences between the manager and the agent. is there. Manager processing is started (S3
1), the agent to be managed is found (S32).
Next, if there is the MIB of the agent in the manager, the MIB is deleted (S33). Thereafter, "xxxGetNextMode = 1" shown in FIG. 6 is set for the agent to instruct the standard collection mode (S34). The sequence S2 and S3 shown in FIG.
All IBs are collected (S35). When the collection of all MIBs of the agent is completed, "XXXGetNextMode = 2" in FIG. 6 is set to the agent to instruct the difference collection mode (S36). Next, Get of “XXXMIBStatus” in FIG. 6 is transmitted to the agent to obtain the MIB difference status (“XXXMIBStatus” (MIB6)) (S37). MIB in the acquired "XXXMIBStatus"
It is determined whether or not there is a deletion (S38).
【００３４】ステップＳ３８において、ＭＩＢの削除が
ない場合には、当該エージェントからＭＩＢの差分を収
集し（Ｓ３９）、エラー状態の有無を判断する（Ｓ４
０）。ステップＳ４０においてエラーがないときには、
ステップＳ３７に戻って次のＭＩＢの差分状態を収集す
る。If the MIB is not deleted in step S38, the MIB difference is collected from the agent (S39), and it is determined whether or not there is an error state (S4).
0). If there is no error in step S40,
Returning to step S37, the difference state of the next MIB is collected.
【００３５】ステップＳ４０において、エラーが検出さ
れたときには、当該エージェントに対して再度当該ＭＩ
Ｂの差分状態の取得を働きかけ（Ｓ４１）、取得した取
得した「XXXMIBStatus」にＭＩＢの削除があるか否かを
判断する（Ｓ４２）。この判断で、ＭＩＢの削除がない
場合には、エラー処理に移行する（Ｓ４３）。If an error is detected in step S40, the agent is re-issued to the agent.
The acquisition of the difference status of B is encouraged (S41), and it is determined whether or not the acquired “XXXMIBStatus” has a MIB deleted (S42). If it is determined that the MIB is not deleted, the process proceeds to error processing (S43).
【００３６】ステップＳ３８、Ｓ４２における判断でＭ
ＩＢ削除がある場合には、ステップＳ３３に戻ってマネ
ージャ内ＭＩＢの全削除から実行しなおす。In the determination in steps S38 and S42, M
If there is IB deletion, the process returns to step S33, and the process is executed again from all deletion of MIB in the manager.
【００３７】図１０を用いて、エージェントのＭＩＢ応
答フローを説明する。図１０は、図６〜図８のエージェ
ント側の処理をまとめたフローチャートである。この処
理は、マネージャとエージェント間のＭＩＢ同期あわせ
を実現するために、特にＳＮＭＰエージェント制御部に
有する。内容はエージェントの初期設定処理Ｓ５２と、
標準収集モードでの処理フローＳ５３〜Ｓ５７と、差分
収集モードでの処理フローＳ６０〜Ｓ６６を有してい
る。The MIB response flow of the agent will be described with reference to FIG. FIG. 10 is a flowchart summarizing the processing on the agent side in FIGS. 6 to 8. This processing is particularly provided in the SNMP agent control unit in order to realize MIB synchronization between the manager and the agent. The contents are agent initial setting processing S52,
It has processing flows S53 to S57 in the standard collection mode and processing flows S60 to S66 in the difference collection mode.
【００３８】エージェント処理が起動されると、エージ
ェント２０は、図１０のＭＩＢ応答処理を開始し（Ｓ５
１）、全ＭＩＢの差分フラグを未収集に、ＭＩＢ差分状
態をＭＩＢ削除ありに設定する初期設定処理を実行する
（Ｓ５２）。When the agent process is started, the agent 20 starts the MIB response process of FIG. 10 (S5).
1) An initial setting process for setting the difference flags of all MIBs to uncollected and setting the MIB difference status to "MIB deleted" is executed (S52).
【００３９】「xxxGetNextMode=1」を受けて標準収集モ
ードを設定し、このＭＩＢの差分フラグを収集済みに
し、ＭＩＢ差分状態を編集する（Ｓ５３）。次いで、Ｓ
ＮＭＰの受信を監視し（Ｓ５４）、ＳＮＭＰを受信した
ときには、差分収集モード指示であるか否かを判定する
（Ｓ５５）。ステップＳ５５で差分収集モード指示でな
いと判断したときには、Get-Rquest/Get-Next-Request/
Set-Requestに対して応答する（Ｓ５６）。このときGet
-Next-Requestに対しては標準収集モードで対応する。
次いで、ＭＩＢ毎の差分フラグを収集済みに設定しＭＩ
Ｂ差分状態の編集処理を行った（Ｓ５７）後、ステップ
Ｓ５４に戻りＳＮＭＰの受信を監視する。In response to "xxxGetNextMode = 1", the standard collection mode is set, the MIB difference flag is set to "collected", and the MIB difference state is edited (S53). Then, S
The reception of the NMP is monitored (S54), and when the SNMP is received, it is determined whether or not the instruction is a difference collection mode instruction (S55). If it is determined in step S55 that the instruction is not a difference collection mode instruction, the Get-Rquest / Get-Next-Request /
Respond to Set-Request (S56). At this time Get
-Next-Request is handled in the standard collection mode.
Next, the difference flag for each MIB is set to collected and the
After performing the editing process of the B difference state (S57), the process returns to step S54 to monitor the reception of SNMP.
【００４０】ステップＳ５５で受信したＳＮＭＰが差分
収集モードを指示していた場合には、差分収集モードを
設定し、このＭＩＢの差分フラグを収集済みに設定し、
ＭＩＢの差分状態を編集する（Ｓ６０）。次いで、ＳＮ
ＭＰの受信を監視し（Ｓ６１）、ＳＮＭＰを受信したと
きには、標準収集モード指示であるか否かを判定する
（Ｓ６２）。ステップＳ６２で標準収集モード指示でな
いと判断したときには、ＭＩＢ削除あり時のGet-Next-R
equestであるか否かを判断する（Ｓ６３）。ＭＩＢ削除
あり時のGet-Next-Requestでないときには、Get-Rquest
/Get-Next-Request/Set-Requestに対して応答する（Ｓ
６４）。このときGet-Next-Requestに対しては差分収集
モードで対応する。次いで、ＭＩＢ毎の差分フラグを収
集済みに設定しＭＩＢ差分状態の編集処理を行った（Ｓ
６５）後、ステップＳ６１に戻りＳＮＭＰの受信を監視
する。If the SNMP received in step S55 indicates the difference collection mode, the difference collection mode is set, and the difference flag of this MIB is set to collected, and
The difference status of the MIB is edited (S60). Then, SN
The reception of the MP is monitored (S61), and when the SNMP is received, it is determined whether or not the instruction is the standard collection mode instruction (S62). If it is determined in step S62 that the instruction is not the standard collection mode instruction, the Get-Next-R when MIB is deleted is determined.
An equest is determined (S63). If it is not Get-Next-Request when there is MIB deletion, Get-Rquest
Responds to / Get-Next-Request / Set-Request (S
64). At this time, Get-Next-Request is handled in the difference collection mode. Next, the difference flag for each MIB is set to collected and the MIB difference state is edited (S
65) Thereafter, the flow returns to step S61 to monitor the reception of SNMP.
【００４１】ステップＳ６２の判断で、ＳＮＭＰが標準
収集モードを指示しているときには、ステップＳ５３の
標準収集モードに戻る。ステップＳ６３の判断で、ＭＩ
Ｂ削除あり時のGet-Next-Requestであるときには、「Ge
n-Error」応答して（Ｓ６６）、ステップＳ６１に戻り
ＳＮＭＰの受信を監視する。If it is determined in step S62 that the SNMP indicates the standard collection mode, the process returns to the standard collection mode in step S53. In the judgment of step S63, MI
If the request is Get-Next-Request with B deletion, "Ge
In response to "n-Error" (S66), the process returns to step S61 to monitor the reception of SNMP.
【００４２】図１１を用いて、エージェント２０のＭＩ
Ｂ応答時のステップＳ５３，Ｓ５７，Ｓ６０，Ｓ６５に
おける、ＭＩＢ差分状態の編集処理を説明する。エージ
ェント２０は、ＭＩＢ差分状態をマネージャ１０に見せ
るため、処理フローＳ７１〜Ｓ７５を有している。この
処理は、ＳＮＭＰエージェント制御部２３に有してい
る。ＭＩＢ差分状態の編集処理に入ると（Ｓ７１）、全
ての差分フラグが収集済みとなっているか否かを判断す
る（Ｓ７２）。全ての差分フラグが収集済みとされてい
るときには、ＭＩＢ差分状態を判断し、差分があるか否
かを判断する（Ｓ７３）。差分があるときには、図５の
ＭＩＢ６の「INTEGER」の内容を差分なし（none）とす
るとともに、このＭＩＢの差分フラグを未収集とし（Ｓ
７４）、ＭＩＢ差分状態の編集処理を終了する（Ｓ７
５）。ステップＳ７２の差分フラグが収集済み以外であ
るとき、ステップＳ７３のＭＩＢ差分状態が差分なしで
あるときには、ＭＩＢ差分状態の編集処理を終了する
（Ｓ７５）。Referring to FIG. 11, the MI of the agent 20
The process of editing the MIB difference state in steps S53, S57, S60, and S65 at the time of response B will be described. The agent 20 has processing flows S71 to S75 in order to show the MIB difference state to the manager 10. This process is included in the SNMP agent control unit 23. When the process for editing the MIB difference state is started (S71), it is determined whether or not all difference flags have been collected (S72). If all the difference flags have been collected, the MIB difference state is determined, and it is determined whether or not there is a difference (S73). When there is a difference, the content of “INTEGER” of MIB 6 in FIG. 5 is set to no difference (none), and the difference flag of this MIB is set to uncollected (S
74), end the MIB difference state editing process (S7).
5). When the difference flag in step S72 is other than collected, and when the MIB difference state in step S73 is no difference, the editing process of the MIB difference state ends (S75).
【００４３】図１２を用いて、エージェント２０のＭＩ
Ｂが変化したときの処理を説明する。この処理は、マネ
ージャ１０からのＳＮＭＰ制御によるＭＩＢの変化では
なく、管理対象ノードの自立的な運用状態の変化による
ＭＩＢの変化があった場合の処理である。この処理は、
ＳＮＭＰエージェント制御部２３に有している。エージ
ェント１０は、ＭＩＢに変化が生じると（Ｓ８１）、そ
の変化がＭＩＢの削除であるか否かを判断する（Ｓ８
２）。変化がＭＩＢの削除でない場合には、ＭＩＢ差分
状態がＭＩＢの削除ありであるか否かを判断する（Ｓ８
３）。ＭＩＢの削除ありでない場合には、変化したＭＩ
Ｂの差分フラグを未収集に設定するとともにＭＩＢ差分
状態をＭＩＢ変更ありまたは追加ありに設定し（Ｓ８
５）、この処理を終了する（Ｓ８５）。Referring to FIG.
Processing when B changes will be described. This processing is not the MIB change due to the SNMP control from the manager 10, but the MIB change due to the autonomous operation state change of the managed node. This process
It is provided in the SNMP agent control unit 23. When a change occurs in the MIB (S81), the agent 10 determines whether or not the change is a deletion of the MIB (S8).
2). If the change is not the deletion of the MIB, it is determined whether or not the MIB difference state is the deletion of the MIB (S8).
3). If there is no MIB deletion, the changed MI
The difference flag of B is set to “uncollected” and the MIB difference state is set to “with or without MIB change” (S8).
5), this process ends (S85).
【００４４】ステップＳ８２の判断で、ＭＩＢの削除で
あったとき、全てのＭＩＢの差分フラグを未収集に設定
するとともにＭＩＢ差分状態をＭＩＢ削除ありに設定し
て（Ｓ８６）、この処理を終了する（Ｓ８５）。ステッ
プＳ８３の判断で、ＭＩＢの差分状態がＭＩＢの削除あ
りであったときには、この処理を終了する（Ｓ８５）。If it is determined in step S82 that the MIB has been deleted, the difference flags of all the MIBs are set to “uncollected” and the MIB difference state is set to “MIB deleted” (S86), and this process is terminated. (S85). If it is determined in step S83 that the MIB difference state indicates that the MIB has been deleted, the process ends (S85).
【００４５】図１３を用いて、エージェントの標準収集
モードでのGet-Next応答処理を説明する。この処理は、
ＳＮＭＰでの方式そのものであり参考である。特にＳＮ
ＭＰエージェント制御部２３に有している。エージェン
ト２０は、「Get-Next-Request」を受信すると（Ｓ９
１）、ＭＩＢの辞書の順の次に来るＭＩＢを検索する
（Ｓ９２）。ステップＳ９３の判断で全てのＭＩＢの検
索が終了しておらず、次に来るＭＩＢが検索できた場合
には、そのＭＩＢで正常な応答処理を実行した（Ｓ９
４）後、この処理を終了する（Ｓ９６）。ステップＳ９
３の判断で全てのＭＩＢの検索が終了した場合には、
「No-Such-Name」の応答を処理を実行し（Ｓ９５）、こ
の処理を終了する（Ｓ９６）。The Get-Next response processing in the standard collection mode of the agent will be described with reference to FIG. This process
It is a method itself in SNMP and is a reference. Especially SN
It is provided in the MP agent control unit 23. When the agent 20 receives “Get-Next-Request” (S9
1) Search for the next MIB in the MIB dictionary order (S92). If it is determined in step S93 that all the MIBs have not been searched, and that the next MIB can be searched, a normal response process is executed using the MIB (S9).
4) After that, this processing ends (S96). Step S9
If the search of all MIBs is completed by the judgment of 3,
A response of “No-Such-Name” is executed (S95), and the process ends (S96).
【００４６】図１４を用いて、エージェントの差分収集
モードでのGet-Next応答処理を説明する。この処理は、
図１３に示した標準収集モードでの「Get-Next-Reques
t」応答処理とほとんとどじであるが、処理フローＳ１
０４に示す差分フラグが収集済みか未収集であるかの判
断処理を有する点に特徴がある。エージェント２０は、
差分収集モードで「Get-Next-Request」を受信すると
（Ｓ１０１）、ＭＩＢの辞書の順の次に来るＭＩＢを検
索する（Ｓ１０２）。全てのＭＩＢの差分の収集が終了
したか否かを判断し（Ｓ１０３）、終了していないとき
には、差分フラグを参照して差分を収集済みであるか否
かを判断し（Ｓ１０４）、収集していないときには、正
常な応答処理を実行した（Ｓ１０５）後、この処理を終
了する（Ｓ１０７）。The Get-Next response process in the agent difference collection mode will be described with reference to FIG. This process
“Get-Next-Reques” in the standard collection mode shown in FIG.
t ”is almost the same as the response processing, but the processing flow S1
It is characterized in that it has a process of determining whether the difference flag shown in FIG. 04 has been collected or not collected. Agent 20
When "Get-Next-Request" is received in the difference collection mode (S101), the next MIB in the MIB dictionary order is searched (S102). It is determined whether or not the collection of the differences of all MIBs has been completed (S103). If not completed, it is determined whether or not the differences have been collected by referring to the difference flag (S104). If not, a normal response process is executed (S105), and this process is terminated (S107).
【００４７】ステップＳ１０３の判断で全てのＭＩＢの
検索が終了した場合には、「No-Such-Name」の応答を処
理を実行し（Ｓ１０６）、この処理を終了する（Ｓ１０
７）。ステップＳ１０４の判断で、差分フラグが収集済
みとなっているときには、ステップＳ１０２の戻り次の
ＭＩＢの差分を検索する。If all MIBs have been searched in step S103, a response of "No-Such-Name" is executed (S106), and the process ends (S10).
7). If it is determined in step S104 that the difference flag has been collected, the process returns to step S102 to search for the next MIB difference.
【００４８】これによってマネージャ１０に対する差分
収集モードの応答が可能となる。この処理は、エージェ
ント２０のＳＮＭＰエージェント制御部２３に有してい
る。ここでは、差分のあるＭＩＢの検索を単純検索方式
により実現しているが、差分のあるＭＩＢのみを集めた
辞書順ソートファイルを別途用意すれば、応答時間を短
縮することができる方式をも含むものである。As a result, it is possible to respond to the manager 10 in the difference collection mode. This process is included in the SNMP agent control unit 23 of the agent 20. Here, the retrieval of the MIB with the difference is realized by the simple search method. However, if the dictionary order sort file which collects only the MIB with the difference is separately prepared, the method for shortening the response time is included. It is a thing.
【００４９】図１５以下を用いてマネージャ１０内のＭ
ＩＢテーブル１６１の内容を説明する。図１５はＭＩＢ
を全て削除したときのマネージャ１０内のＭＩＢテーブ
ル１６１の内容を示している。ＭＩＢテーブル１６１に
は、ＭＩＢ毎のオブジェクトＩＤを意味する項欄と、値
欄とが関係付けられて設けられている。ＭＩＢ名欄は、
本発明の説明を分かり易くするために設けてある。ＭＩ
Ｂを全て削除した場合には、ＭＩＢテーブル１６１の内
容の全てが空きになっている。ＭＩＢ削除あり時も本テ
ーブルの内容となる。The M in the manager 10 will be described with reference to FIG.
The contents of the IB table 161 will be described. FIG. 15 shows the MIB.
8 shows the contents of the MIB table 161 in the manager 10 when all of the. The MIB table 161 is provided with an item column indicating an object ID for each MIB and a value column in association with each other. The MIB name field is
It is provided for clarity of the description of the present invention. MI
When all B are deleted, all the contents of the MIB table 161 are empty. The contents of this table are also used when MIB is deleted.
【００５０】図１６を用いて、ＭＩＢの全収集を行った
ときのマネージャ１０内のＭＩＢテーブル１６１の内容
を説明する。例えば、項欄には、１〜９９９，１００
１，１００２が記載される。値欄には項，ＭＩＢ名に対
応して値が記載される。例えば、システム情報１〜９９
９に対応してそのときの装置状態がそれぞれ最初の値と
して記憶され、GetNext収集モードに対応して「標準収
集モード」、ＭＩＢ差分状態に対応して「ＭＩＢ削除あ
り」が記載されている。The contents of the MIB table 161 in the manager 10 when all MIBs are collected will be described with reference to FIG. For example, in the item column, 1-999,100
1,1002 are described. In the value column, a value is described corresponding to the item and MIB name. For example, system information 1 to 99
9, the device state at that time is stored as the first value, and “Standard collection mode” corresponding to the GetNext collection mode and “MIB deleted” corresponding to the MIB difference state are described.
【００５１】図１７を用いて、定期的な差分収集を行っ
たときのマネージャ１０内のＭＩＢテーブル１６１の内
容を説明する。この例では、「システム情報１〜９９
９」に変化がないときを示している。マネージャ１０か
らエージェント２０に対する「Get-Next-Request」で
は、１周期目に「ＭＩＢ差分状態＝差分なし」のみの応
答となり、２周期目以降は全て「No-Such-Name」とな
り、それだけでマネージャ１０とエージェント２０間の
ＭＩＢ同期をとることが可能となる。Referring to FIG. 17, the contents of the MIB table 161 in the manager 10 at the time of performing periodic difference collection will be described. In this example, “system information 1 to 99
9 "shows no change. In the case of “Get-Next-Request” from the manager 10 to the agent 20, only the “MIB difference state = no difference” is returned in the first cycle, and the response becomes “No-Such-Name” in the second and subsequent cycles. MIB synchronization between the agent 10 and the agent 20 can be achieved.
【００５２】図１８を用いて、定期的な差分収集を行っ
たときのマネージャ１０内のＭＩＢテーブル１６１の内
容説明する。この例は、「システム情報９９９」にＭＩ
Ｂ状態の変更（９９９から０への変更）があったときを
示している。マネージャ１０からエージェント２０に対
する「Get-Next-Request」では１周期目に「システム情
報９９９＝０」と「ＭＩＢ差分状態＝ＭＩＢ変更／追加
あり」のみの応答となり、さらに２周期目は「ＭＩＢ差
分状態＝差分なし」のみの応答となり、３周期目以降は
全て「No-Such-Name」で済ませることができる。Referring to FIG. 18, the contents of the MIB table 161 in the manager 10 at the time of performing periodic difference collection will be described. In this example, the “System Information 999”
The state when the B state is changed (change from 999 to 0) is shown. In the “Get-Next-Request” from the manager 10 to the agent 20, only the “system information 999 = 0” and “MIB difference status = MIB changed / added” are responses in the first cycle, and the “MIB difference” in the second cycle. The response is only “state = no difference”, and all the third and subsequent cycles can be completed with “No-Such-Name”.
【００５３】図１９を用いて、定期的な差分収集を行っ
たときのマネージャ１０内のＭＩＢテーブル１６１の内
容を説明する。この例は、「システム情報１０００」が
ＭＩＢに追加になったときを示している。マネージャ１
０からエージェント２０に対する「Get-Next-Request」
では１周期目に「システム情報１０００＝１０００」と
「ＭＩＢ差分状態＝ＭＩＢ変更／追加あり」のみの応答
となり、さらに２周期目は「ＭＩＢ差分状態＝差分な
し」のみの応答となり、３周期目以降は全て「No-Such-
Name」で済ませることができる。Referring to FIG. 19, the contents of the MIB table 161 in the manager 10 when periodic difference collection is performed will be described. This example shows a case where “system information 1000” is added to the MIB. Manager 1
"Get-Next-Request" for Agent 20 from 0
In the first cycle, a response consisting only of “system information 1000 = 1000” and “MIB difference state = MIB changed / added” is given. In the second cycle, a response consisting only of “MIB difference state = no difference” is given. From then on, everything is "No-Such-
Name ”.
【００５４】以下、図２０〜図２４を用いて、エージェ
ント２０内のＭＩＢテーブル２４１の内容を説明する。
図２０を用いて、全ＭＩＢの差分フラグを未収集にした
ときのエージェント２０内のＭＩＢテーブル２４１の内
容を説明する。ＭＩＢテーブル２４１には、ＭＩＢ毎の
オブジェクトＩＤを意味する項欄と、値欄と、差分フラ
グが対応付けられて設けられている。例えば、項欄に
は、１〜９９９，１００１，１００２が記載される。値
欄にはＭＩＢ名に対応して値が記載される。例えば、シ
ステム情報１〜９９９に対応してそのときの装置状態が
それぞれ最初の値として記憶され、GetNext収集モード
に対応して「標準収集モード」、ＭＩＢ差分状態に対応
して「ＭＩＢ削除あり」が記載されている。この場合
は、実装している全ＭＩＢに対して差分フラグは全て未
収集とされる。ＭＩＢ削除あり時も本テーブルの内容と
なる。特に図２０〜図２４は管理対象ノード（エージェ
ント）２０のＭＩＢテーブル２４１に記憶されるもので
ある。The contents of the MIB table 241 in the agent 20 will be described below with reference to FIGS.
The contents of the MIB table 241 in the agent 20 when the difference flags of all MIBs have not been collected will be described with reference to FIG. The MIB table 241 is provided with an item column indicating an object ID for each MIB, a value column, and a difference flag in association with each other. For example, 1 to 999, 1001, and 1002 are described in the item column. The value column describes a value corresponding to the MIB name. For example, the device status at that time is stored as the first value corresponding to the system information 1 to 999, respectively, "standard collection mode" corresponding to the GetNext collection mode, and "MIB deleted" corresponding to the MIB difference status. Is described. In this case, all the difference flags are not collected for all the installed MIBs. The contents of this table are also used when MIB is deleted. 20 to 24 are particularly stored in the MIB table 241 of the managed node (agent) 20.
【００５５】図２１を用いて、ＭＩＢの全収集を行った
後のエージェント２０内ＭＩＢテーブル２４１の記載内
容を説明する。この状態では、システム情報１からシス
テム情報９９９および「Get-Next収集モード」の差分フ
ラグ欄は、収集済みとされ、「ＭＩＢ差分状態」をＭＩ
Ｂ削除ありから差分なしにエージェントが自立的に変え
たため、その差分フラグのみ未収集扱いとなっている。Referring to FIG. 21, the contents of the MIB table 241 in the agent 20 after all the MIBs have been collected will be described. In this state, the system information 1 to system information 999 and the difference flag column of “Get-Next collection mode” are determined to have been collected, and the “MIB difference state” is set to MI.
Since the agent autonomously changed without the difference after the deletion B, only the difference flag is not collected.
【００５６】図２２を用いて、定期的な差分収集を行っ
た後のエージェント２０内ＭＩＢテーブル２４１の内容
例を説明する。この例は、「システム情報１〜９９９」
に変化がないときを示している。このときの値欄に記載
された値は、図２１の値欄の記載内容と同様である。こ
のように、エージェント２０のＭＩＢテーブル２４１に
記載された全てのＭＩＢがマネージャ１０のＭＩＢテー
ブル１６１内の内容と同期がとれているので、全ての差
分フラグが収集済みとなる。Referring to FIG. 22, an example of the contents of the MIB table 241 in the agent 20 after the periodic difference collection is performed will be described. In this example, “system information 1 to 999”
Shows the case where there is no change in. The values described in the value column at this time are the same as the contents described in the value column of FIG. As described above, since all MIBs described in the MIB table 241 of the agent 20 are synchronized with the contents in the MIB table 161 of the manager 10, all difference flags have been collected.
【００５７】図２３を用いて、定期的な差分収集を行っ
た後のエージェント２０内ＭＩＢテーブル２４１の内容
例を説明する。この例は、「システム情報９９９」にＭ
ＩＢ状態の変更（９９９から０に変更）があったときを
示す。マネージャ１００からエージェント２０に対して
「Get-Next-Reqest」する前は収集前の差分フラグ欄に
示すように、「システム情報９９９」および「ＭＩＢ差
分状態」が未収集とされ、その値はそれぞれ０およびＭ
ＩＢ変更／追加ありである。未収集の差分フラグが設定
されたエージェントに対してマネージャ１０から１周期
目の「Get-Next-Request」の収集が行われた後の差分フ
ラグは、エージェント２０がＭＩＢ差分状態をＭＩＢ変
更／追加ありから差分なしへ自立的に変えたので、そこ
だけ未収集扱いとされている。未収集の差分フラグが設
定されたエージェントに対してマネージャ１０から２周
期目以降の「Get-Next-Request」の収集が行われた後
は、エージェント２０のＭＩＢテーブル２４１内の全て
のＭＩＢがマネージャ２０のＭＩＢテーブル１６１のＭ
ＩＢと同期がとられているので、差分フラグは全て収集
済みとなる。Referring to FIG. 23, an example of the contents of the MIB table 241 in the agent 20 after the periodic difference collection is performed will be described. In this example, “System information 999” contains M
This indicates that the IB state has been changed (changed from 999 to 0). Before “Get-Next-Reqest” from the manager 100 to the agent 20, “System information 999” and “MIB difference status” are not collected as shown in the difference flag column before collection, and the values are respectively 0 and M
IB changed / added. The difference flag after the manager 10 collects “Get-Next-Request” in the first cycle for the agent for which the uncollected difference flag is set is the agent 20 that changes / adds the MIB difference state to the MIB. Since it was changed autonomously from there to no difference, it is regarded as uncollected only there. After the manager 10 collects “Get-Next-Request” in the second and subsequent cycles for the agent for which the uncollected difference flag is set, all MIBs in the MIB table 241 of the agent 20 are changed to the manager. M of 20 MIB tables 161
Since synchronization with the IB has been established, all difference flags have been collected.
【００５８】図２４を用いて、定期的な差分収集を行っ
た後のエージェント２０内のＭＩＢテーブル２４１の内
容例を説明する。この例は、「システム情報１０００」
がＭＩＢ追加になったときを示している。マネージャ１
０からエージェント２０に対して「Get-Next-Reqest」
する前は、「システム情報１０００」および「ＭＩＢ差
分状態」が未収集とされ、その値はそれぞれ１０００お
よびＭＩＢ変更／追加ありとなっている。差分フラグが
未収集となっているエージェントに対してマネージャ１
０から１周期目の「Get-Next-Request」の収集が行われ
た後の差分フラグは、エージェント２０がＭＩＢ差分状
態をＭＩＢ変更／追加ありから差分なしへ自立的に変え
たので、そこだけ未収集扱いとなる。未収集の差分フラ
グが設定されたエージェントに対してマネージャ１０か
ら２周期目以降の「Get-Next-Request」の収集が行われ
た後は、エージェント２０のＭＩＢテーブル２４１内の
全てのＭＩＢがマネージャ１０のＭＩＢテーブル１６１
のＭＩＢと同期がとられているので、全て収集済みとな
る。With reference to FIG. 24, an example of the contents of the MIB table 241 in the agent 20 after performing the periodic difference collection will be described. In this example, "System information 1000"
Indicates when MIB is added. Manager 1
"Get-Next-Reqest" from 0 to agent 20
Before this, “system information 1000” and “MIB difference state” are not collected, and their values are 1000 and MIB changed / added, respectively. Manager 1 for agents whose difference flags have not been collected
The difference flag after the collection of “Get-Next-Request” from 0 to the first cycle is performed because the agent 20 autonomously changed the MIB difference state from “with / without MIB change” to “without difference”. Not collected. After the manager 10 collects “Get-Next-Request” in the second and subsequent cycles for the agent for which the uncollected difference flag is set, all MIBs in the MIB table 241 of the agent 20 are changed to the manager. 10 MIB tables 161
Are synchronized, and thus all have been collected.
【００５９】[0059]
【発明の効果】本発明のネットワーク管理情報収集方式
は、マネージャ１０がエージェント２０からＭＩＢを収
集するとき、差分があるＭＩＢの差分のみを収集しＭＩ
Ｂの収集量および収集時間を短縮化しているので以下の
効果がある。According to the network management information collection method of the present invention, when the manager 10 collects the MIB from the agent 20, only the MIB difference having a difference is collected and the
Since the collection amount and the collection time of B are reduced, the following effects are obtained.
【００６０】マネージャとエージェント間の通信量が
少なくなり、それと同じ通信路を共有している他の通信
を妨げる事や、しいては長時間通信帯域を占有してしま
う事を防ぐことができる。The amount of communication between the manager and the agent is reduced, so that it is possible to prevent other communication sharing the same communication path from being interrupted, and to prevent the communication band from being occupied for a long time.
【００６１】管理対象ノード数が多数存在する時はそ
の１つの管理対象ノードに対するアクセス量が減るの
で、全体としての管理情報収集時間を大幅に削減するこ
とが可能となる。When the number of managed nodes is large, the amount of access to one managed node is reduced, so that the total management information collection time can be greatly reduced.
【００６２】管理項目数をさらに増やそうとしたと
き、その特性が差分の発生しにくい管理項目であれば、
ほとんどネットワーク管理情報収集性能のパフォーマン
スを下げなくて済む。When the number of management items is to be further increased, if the characteristic is a management item that hardly causes a difference,
Almost no reduction in network management information collection performance.
【００６３】マネージャとエージェント間で差分があ
った分の問い合わせだけを行えばよいので．マネージャ
のエージェントに対する他のオペレーションが困難にな
るのを防止できオペレータの負担が軽減できる。It is only necessary to make an inquiry for the difference between the manager and the agent. It is possible to prevent other operations from becoming difficult for the manager's agent and reduce the burden on the operator.
【００６４】マネージャおよびエージェントは差分が
あった分だけの問い合わせ処理を行えばよいのでそれぞ
れその分、処理負荷を軽減することができる。またそれ
によって高性能な機器を求める必要がなくなり、ユーザ
の負担を軽減できる。Since the manager and the agent need only perform the inquiry processing for the difference, the processing load can be reduced accordingly. This eliminates the need for a high-performance device, and can reduce the burden on the user.
【００６５】マネージャがエージェントの状態をリア
ルタイムにオペレータに伝えるためにエージェントに対
してポーリング的にＭＩＢを収集したとき、そのあいだ
通信帯域の占有および処理負荷がかかってしまうことを
防くことができ、ネットワーク管理のためにネットワー
クへ悪影響を与えることが少なくできる。When the manager collects MIBs by polling the agent in order to convey the state of the agent to the operator in real time, it is possible to prevent the communication band from being occupied and the processing load being imposed during that time. Adverse effects on the network due to network management can be reduced.
【００６６】「Trap」を用いる必要性が少なくなり、
それがコネクションレス方式であるために発生するエー
ジェントからマネージャヘの通信経路上で紛失する問題
を防ぐことができる。また、その紛失があったときの救
済方式も機能にインプリメントを行う必要性が少なくな
り、マネージャおよびエージェントの開発ベンダーに多
く負担をかけなくて済む。さらに、また単位時間に状態
変化が多発してもエージェントからマネージャに対する
「Trap」通知の件数が増加しなくて済み通信帯域の圧迫
および、マネージャおよびエ−ジェントの処理負荷の増
加を招かなくて済む。また、「しきい値」によってある
件数分発生したらそれを抑止又は通知する方式も、実現
しなくて済む。「Trap」自体をＭＩＢの項目数分マネー
ジャおよびエージェントでインブリメントする必要性が
少なくなるのでそれぞれの開発ベンダーにそれを開発す
る負担を軽減できる。The need to use “Trap” is reduced,
It is possible to prevent the problem of being lost on the communication path from the agent to the manager due to the connectionless method. Also, there is less need to implement a function for a remedy method in the event of loss, and it is not necessary to put a lot of burden on manager and agent development vendors. Further, even if the state changes frequently occur in a unit time, the number of "Trap" notifications from the agent to the manager does not increase, thereby suppressing the communication band and increasing the processing load of the manager and the agent. I'm done. Further, a method of suppressing or notifying the occurrence of a certain number of occurrences by the “threshold value” does not have to be realized. Since the need to implement “Trap” itself by the number of MIB items by the manager and the agent is reduced, the burden of developing the “Trap” on each development vendor can be reduced.
【図１】本発明のネットワーク管理システムのシステム
構成例を示す図。FIG. 1 is a diagram showing a system configuration example of a network management system according to the present invention.
【図２】マネージャ、エージェント間でＭＩＢの設定／
参照を実現するプロトコル方式図。[FIG. 2] MIB setting / between manager and agent
FIG. 4 is a protocol scheme diagram for realizing reference.
【図３】ネットワーク管理装置のマネージャ構成例を示
す図。FIG. 3 is a diagram showing an example of a manager configuration of a network management device.
【図４】管理対象ノードのエージェント構成例を示す
図。FIG. 4 is a diagram illustrating an example of an agent configuration of a managed node.
【図５】本発明のＭＩＢ定義例（（ＳＮＭＰｖ１）での
例）を示す図。FIG. 5 is a diagram showing an MIB definition example (an example in (SNMPv1)) of the present invention.
【図６】差分収集モード実行シーケンス例を示す図。FIG. 6 is a diagram showing an example of a difference collection mode execution sequence.
【図７】マネージャから差分収集していないときにＭＩ
Ｂの削除があったときの実行シーケンス例を示す図。FIG. 7 is a diagram showing a case where MI is not collected from the manager;
The figure which shows the example of an execution sequence at the time of deletion of B.
【図８】マネージャから差分収集しているときにＭＩＢ
の削除があったときの実行シーケンス例を示す図。FIG. 8 is a diagram illustrating a MIB when a difference is collected from a manager;
The figure which shows the example of an execution sequence at the time of having deleted.
【図９】マネージャのＭＩＢ収集フローチャート例を示
す図。FIG. 9 is a diagram showing an example of a MIB collection flowchart of a manager.
【図１０】エージェントのＭＩＢ応答フローチャート例
を示す図。FIG. 10 is a diagram showing an example of an MIB response flowchart of an agent.
【図１１】エージェントのＭＩＢ差分状態の編集フロー
チャート例を示す図。FIG. 11 is a diagram showing an example of an editing flowchart of an MIB difference state of an agent.
【図１２】エージェントのＭＩＢが変化したときのフロ
ーチャート例を示す図。FIG. 12 is a diagram showing an example of a flowchart when the MIB of the agent changes.
【図１３】エージェントの標準収集モードでのGet-Next
応答フローチャート例を示す図。FIG. 13: Get-Next in the standard collection mode of the agent
The figure which shows the example of a response flowchart.
【図１４】エージェントの差分収集モードでのGet-Next
応答フローチャート例を示す図。FIG. 14: Get-Next in agent difference collection mode
The figure which shows the example of a response flowchart.
【図１５】マネージャ内ＭＩＢを全削除したときのマネ
ージャ内ＭＩＢテーブル例を示す図。FIG. 15 is a diagram showing an example of an in-manager MIB table when all the in-manager MIBs are deleted.
【図１６】ＭＩＢの全収集を行ったときのマネージャ内
ＭＩＢテーブル例を示す図。FIG. 16 is a diagram showing an example of an in-manager MIB table when all MIBs are collected.
【図１７】定期的な差分収集を行ったときのマネージャ
内ＭＩＢテーブル例を示す図。（「システム情報１〜９
９９」に変化がないとき）FIG. 17 is a diagram showing an example of an in-manager MIB table when periodic difference collection is performed. ("System information 1-9
99 "when there is no change)
【図１８】定期的な差分収集を行ったときのマネージャ
内ＭＩＢテーブル例を示す図。（「システム情報９９
９」にＭＩＢ変更［９９９→０への変更］があったと
き）FIG. 18 is a diagram illustrating an example of an in-manager MIB table when periodic difference collection is performed. ("System information 99
9 "when MIB change [change from 999 to 0]
【図１９】定期的な差分収集があったときのマネージャ
内ＭＩＢテーブル例を示す図。（「システム情報１００
０」がＭＩＢ追加になったとき）FIG. 19 is a diagram showing an example of an in-manager MIB table when there is periodic difference collection; ("System information 100
"0" is added to MIB)
【図２０】全ＭＩＢの差分フラグ＝未収集にしたときの
エージェント内ＭＩＢテーブル例を示す図。FIG. 20 is a diagram showing an example of an in-agent MIB table when the difference flags of all MIBs are set to uncollected.
【図２１】ＭＩＢの全収集を行った後のエージェント内
ＭＩＢテーブル例を示す図。FIG. 21 is a diagram showing an example of an in-agent MIB table after all MIBs have been collected.
【図２２】定期的な差分収集を行った後のエージェント
内ＭＩＢテーブル例を示す図。（「システム情報１〜９
９９」に変化がないとき）FIG. 22 is a diagram showing an example of an in-agent MIB table after performing periodic difference collection. ("System information 1-9
99 "when there is no change)
【図２３】定期的な差分収集を行った後のエージェント
内ＭＩＢテーブル例を示す図。（「システム情報９９
９」にＭＩＢ変更［９９９→０への変更］があったと
き）FIG. 23 is a diagram showing an example of an in-agent MIB table after performing periodic difference collection; ("System information 99
9 "when MIB change [change from 999 to 0]
【図２４】定期的な差分収集を行った後のエージェント
内ＭＩＢテーブル例を示す図。（「システム情報１００
０」がＭＩＢ追加になったとき）FIG. 24 is a diagram showing an example of an in-agent MIB table after performing periodic difference collection; ("System information 100
"0" is added to MIB)
１０ ネットワーク管理装置（マネージャ） １１ 下位プロトコルスタック １２ ＳＮＭＰ処理部 １３ ＳＮＭＰマネージャ制御部 １４ 画面制御部 １５ ネットワーク管理情報表示画面 １６ ＭＩＢテーブル記憶部 １６１ ＭＩＢテーブル ２０ 管理対象ノード（エージェント） ２１ 下位プロトコルスタック ２２ ＳＮＭＰ処理部 １３ ＳＮＭＰエージェント制御部 ２４ ＭＩＢテーブル記憶部 ２４１ ＭＩＢテーブル ３０ 通信回線 Reference Signs List 10 Network management device (manager) 11 Lower protocol stack 12 SNMP processing unit 13 SNMP manager control unit 14 Screen control unit 15 Network management information display screen 16 MIB table storage unit 161 MIB table 20 Managed node (agent) 21 Lower protocol stack 22 SNMP processing unit 13 SNMP agent control unit 24 MIB table storage unit 241 MIB table 30 Communication line
フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 29/06 Ｈ０４Ｌ 13/00 ３０５Ｃ ５Ｋ０５１ 29/14 ３１３ Ｈ０４Ｍ 3/00 Ｆターム(参考） 5B089 GA14 GA33 GB02 HB06 JA36 JB15 KA05 KA13 KC17 KC30 KC44 5K030 GA03 GA08 HB06 HB08 HC14 JA10 JT02 KA06 LA08 MC07 MC09 MD06 5K033 AA01 AA03 BA08 DA01 DB12 DB20 EA07 5K034 AA01 AA07 MM39 5K035 AA02 DD01 5K051 AA03 CC02 EE02 FF01 Continued on the front page (51) Int.Cl. 7 Identification symbol FI Theme coat II (Reference) H04L 29/06 H04L 13/00 305C 5K051 29/14 313 H04M 3/00 F-term (Reference) 5B089 GA14 GA33 GB02 HB06 JA36 JB15 KA05 KA13 KC17 KC30 KC44 5K030 GA03 GA08 HB06 HB08 HC14 JA10 JT02 KA06 LA08 MC07 MC09 MD06 5K033 AA01 AA03 BA08 DA01 DB12 DB20 EA07 5K034 AA01 AA07 MM39 5K035 AA02 DD01 5K051 AA03 CC
Claims (5)
と、複数の管理対象ノードを通信回線を介して接続した
ネットワークの管理情報収集方式において、管理対象ノ
ードにＭＩＢの収集モードと差分状態を記述するＭＩＢ
テーブルを設け、ネットワーク管理手段に設けたＭＩＢ
テーブルを管理対象ノードから差分データを収集するこ
とによって更新するようにしたことを特徴とするＳＮＭ
Ｐを用いたネットワーク管理情報収集方式。1. A management information collection method for a network in which at least one network management device and a plurality of managed nodes are connected via a communication line, a MIB describing a MIB collection mode and a difference state in the managed nodes.
MIB provided in table and network management means
SNM characterized in that a table is updated by collecting difference data from a managed node.
A network management information collection method using P.
制御部と、ＭＩＢテーブルを有し、管理対象ノードに対
して、ＳＮＭＰを用いて全てのＭＩＢデータを収集した
後は、ＳＮＭＰを用いて差分データを収集してＭＩＢテ
ーブルを更新することを特徴とする請求項１に記載のネ
ットワーク管理情報収集方式に用いるネットワーク管理
装置。2. An SNMP processing unit, an SNMP manager control unit, and an MIB table. After collecting all MIB data for a managed node using SNMP, difference data is collected using SNMP. 2. The network management apparatus according to claim 1, wherein the network management apparatus collects and updates the MIB table.
ーク管理情報を差分で収集できるように構成されている
ことを特徴とする請求項２記載のネットワーク管理情報
収集方式に用いるネットワーク管理装置。3. The network management apparatus used in the network management information collection method according to claim 2, wherein the SNMP manager control unit is configured to collect the network management information by a difference.
ト制御部と、ＭＩＢテーブルを有し、ＭＩＢに変更があ
ったときにＭＩＢテーブルに差分フラグを設定し、ネッ
トワーク管理装置からＳＮＭＰを用いてＭＩＢデータの
収集があったときに全てのＭＩＢデータを送信し、その
後ＭＩＢデータの差分データの収集があったときに差分
状態を参照して差分データのみを送信することを特徴と
する請求項１に記載のネットワーク管理情報収集方式に
用いる管理対象ノード。4. An SNMP processing unit, an SNMP agent control unit, and an MIB table, a difference flag is set in the MIB table when the MIB is changed, and the MIB data is transmitted from the network management apparatus using SNMP. 2. The system according to claim 1, wherein all MIB data is transmitted when data is collected, and then only difference data is transmitted with reference to a difference state when difference data of the MIB data is collected. Managed node used for the network management information collection method.
ワーク管理情報を差分で収集応答できるように構成され
ていることを特徴とする請求項４記載のネットワーク管
理情報収集方式に用いる管理対象ノード。5. The managed node used in the network management information collection method according to claim 4, wherein the SNMP agent control unit is configured to be able to collect and respond to the network management information with a difference.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23864098A JP3897911B2 (en) | 1998-08-25 | 1998-08-25 | Network management information collecting method, network management device, and managed device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP23864098A JP3897911B2 (en) | 1998-08-25 | 1998-08-25 | Network management information collecting method, network management device, and managed device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000066978A true JP2000066978A (en) | 2000-03-03 |
| JP3897911B2 JP3897911B2 (en) | 2007-03-28 |
Family
ID=17033152
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP23864098A Expired - Fee Related JP3897911B2 (en) | 1998-08-25 | 1998-08-25 | Network management information collecting method, network management device, and managed device |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3897911B2 (en) |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004507849A (en) * | 2000-08-31 | 2004-03-11 | ローデ ウント シュワルツ ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディット ゲゼルシャフト | Operation system of unmanned wireless transmitter, especially system for remote control and remote monitoring of unmanned wireless transmitter |
| WO2004027627A1 (en) * | 2002-09-18 | 2004-04-01 | Matsushita Electric Industrial Co., Ltd. | Information acquiring device and information providing device |
| JP2007174235A (en) * | 2005-12-21 | 2007-07-05 | Fujitsu Ltd | Attribute information collection device, attribute information collection method and attribute information collection program |
| JP2008504765A (en) * | 2004-06-30 | 2008-02-14 | シーメンス アクチエンゲゼルシヤフト | Method and apparatus for obtaining optical output level of PON |
| JP2008165828A (en) * | 2008-03-07 | 2008-07-17 | Konica Minolta Business Technologies Inc | Data transmission device, program, and data transmission method |
| US7602511B2 (en) | 2001-08-20 | 2009-10-13 | Brother Kogyo Kabushiki Kaisha | Transmission device enabling external device to edit address data registered in the transmission device |
| EP2312453A2 (en) | 2009-09-11 | 2011-04-20 | Fujitsu Limited | Control apparatus and data processing system |
| KR101058004B1 (en) | 2004-04-16 | 2011-08-19 | 삼성전자주식회사 | Simple network management protocol network management method and device using unique management information base of network device |
| JP2012198686A (en) * | 2011-03-18 | 2012-10-18 | Ricoh Co Ltd | Control system, control device, control method, control program, and storage medium |
| WO2013180255A1 (en) * | 2012-05-31 | 2013-12-05 | 株式会社日立製作所 | Communication devices and method |
| JP2014164314A (en) * | 2013-02-21 | 2014-09-08 | Canon Inc | Management apparatus, control method thereof, and program |
| JP2014215638A (en) * | 2013-04-22 | 2014-11-17 | 京セラドキュメントソリューションズ株式会社 | Apparatus management system, electronic apparatus, and apparatus management program |
| JP2016506678A (en) * | 2012-12-28 | 2016-03-03 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | Data optimization techniques for data exchange at the edge of wireless local area networks |
-
1998
- 1998-08-25 JP JP23864098A patent/JP3897911B2/en not_active Expired - Fee Related
Cited By (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4717323B2 (en) * | 2000-08-31 | 2011-07-06 | ローデ ウント シュワルツ ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディット ゲゼルシャフト | Unmanned radio transmitter operating system, in particular a system for remote control and remote monitoring of an unmanned radio transmitter |
| JP2004507849A (en) * | 2000-08-31 | 2004-03-11 | ローデ ウント シュワルツ ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディット ゲゼルシャフト | Operation system of unmanned wireless transmitter, especially system for remote control and remote monitoring of unmanned wireless transmitter |
| US7602511B2 (en) | 2001-08-20 | 2009-10-13 | Brother Kogyo Kabushiki Kaisha | Transmission device enabling external device to edit address data registered in the transmission device |
| WO2004027627A1 (en) * | 2002-09-18 | 2004-04-01 | Matsushita Electric Industrial Co., Ltd. | Information acquiring device and information providing device |
| KR101058004B1 (en) | 2004-04-16 | 2011-08-19 | 삼성전자주식회사 | Simple network management protocol network management method and device using unique management information base of network device |
| JP2008504765A (en) * | 2004-06-30 | 2008-02-14 | シーメンス アクチエンゲゼルシヤフト | Method and apparatus for obtaining optical output level of PON |
| JP2007174235A (en) * | 2005-12-21 | 2007-07-05 | Fujitsu Ltd | Attribute information collection device, attribute information collection method and attribute information collection program |
| US8275876B2 (en) | 2005-12-21 | 2012-09-25 | Fujitsu Limited | Method and apparatus for collecting attribute-information, and computer product |
| JP4684883B2 (en) * | 2005-12-21 | 2011-05-18 | 富士通株式会社 | Attribute information collecting apparatus, attribute information collecting method, and attribute information collecting program |
| JP2008165828A (en) * | 2008-03-07 | 2008-07-17 | Konica Minolta Business Technologies Inc | Data transmission device, program, and data transmission method |
| JP4631920B2 (en) * | 2008-03-07 | 2011-02-16 | コニカミノルタビジネステクノロジーズ株式会社 | Data transmitting apparatus, program, and data transmitting method |
| EP2312453A2 (en) | 2009-09-11 | 2011-04-20 | Fujitsu Limited | Control apparatus and data processing system |
| JP2012198686A (en) * | 2011-03-18 | 2012-10-18 | Ricoh Co Ltd | Control system, control device, control method, control program, and storage medium |
| WO2013180255A1 (en) * | 2012-05-31 | 2013-12-05 | 株式会社日立製作所 | Communication devices and method |
| JP2013250691A (en) * | 2012-05-31 | 2013-12-12 | Hitachi Ltd | Communication device and method |
| JP2016506678A (en) * | 2012-12-28 | 2016-03-03 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | Data optimization techniques for data exchange at the edge of wireless local area networks |
| JP2014164314A (en) * | 2013-02-21 | 2014-09-08 | Canon Inc | Management apparatus, control method thereof, and program |
| JP2014215638A (en) * | 2013-04-22 | 2014-11-17 | 京セラドキュメントソリューションズ株式会社 | Apparatus management system, electronic apparatus, and apparatus management program |
Also Published As
| Publication number | Publication date |
|---|---|
| JP3897911B2 (en) | 2007-03-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1384349B1 (en) | System and method for configuration of network resources | |
| EP0621706B1 (en) | System and method for monitoring simple network management protocol tables | |
| JP4509916B2 (en) | SNMP-based network management apparatus and method | |
| US6978301B2 (en) | System and method for configuring a network device | |
| US7756953B2 (en) | Method and apparatus for monitoring responses of configuration commands | |
| US7328260B1 (en) | Mapping discovered devices to SAN-manageable objects using configurable rules | |
| US20020069367A1 (en) | Network operating system data directory | |
| US20070043826A1 (en) | Graphical user interface and method for customer centric network management | |
| US20020069271A1 (en) | Event manager for network operating system | |
| US9331902B2 (en) | Apparatus and method providing unified network management | |
| CA2404191A1 (en) | Methods and apparatus for configuration change management in communications networks | |
| JP2000066978A (en) | Network management information collection system, network management device to be used for the system and node to be managed | |
| CN101099398B (en) | Method and devices for matching data between a manager and an agent in a management network | |
| CN114650226A (en) | Topology management method and device, network element management node and storage medium | |
| US7600147B2 (en) | Apparatus and method for managing traps in a network environment | |
| EP2036247B1 (en) | Automatic detection of agents | |
| JPH08147231A (en) | Retrieval method for network node | |
| JPH10210034A (en) | Network management system | |
| CN110768838A (en) | SNMP message processing method and related device | |
| CN113794580A (en) | Network equipment management method and device | |
| JP2002169733A (en) | Synchronism control system for network management system | |
| WO2016197617A1 (en) | Packet transport network device, and resource recovery method and apparatus therefor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20030228 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20030228 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060130 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060207 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060407 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060407 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060919 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061116 |
|
| 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: 20061219 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061220 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| R371 | Transfer withdrawn |
Free format text: JAPANESE INTERMEDIATE CODE: R371 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100105 Year of fee payment: 3 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |