JP2012164134A - Management device, management method, and program - Google Patents
Management device, management method, and program Download PDFInfo
- Publication number
- JP2012164134A JP2012164134A JP2011024019A JP2011024019A JP2012164134A JP 2012164134 A JP2012164134 A JP 2012164134A JP 2011024019 A JP2011024019 A JP 2011024019A JP 2011024019 A JP2011024019 A JP 2011024019A JP 2012164134 A JP2012164134 A JP 2012164134A
- Authority
- JP
- Japan
- Prior art keywords
- management
- snmp
- mib
- network
- vendor
- 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.)
- Withdrawn
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
Description
本発明は、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を利用してネットワーク上のデバイスを管理する技術に関する。 The present invention relates to a technique for managing devices on a network by using SNMP (Simple Network Management Protocol).
近年、ネットワークに接続された各種のデバイスを、ＳＮＭＰを利用して管理・監視するデバイス管理プログラムが数多く普及している。ＳＮＭＰによる管理の対象となるデバイスはＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）と呼ばれる管理情報データベースを持っており、デバイス管理プログラムは管理対象デバイスのＭＩＢに基づいて適切な設定を行うことによりデバイスを管理している。ＭＩＢにはインターネットに関する技術の標準を定める団体であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）が発行するＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）で定義された標準ＭＩＢとデバイスのベンダーが独自に定義するプライベートＭＩＢが存在する。 In recent years, many device management programs for managing and monitoring various devices connected to a network by using SNMP have become widespread. A device to be managed by SNMP has a management information database called MIB (Management Information Base), and the device management program manages the device by performing appropriate settings based on the MIB of the managed device. . The MIB includes a standard MIB defined by RFC (Request For Comment) issued by IETF (Internet Engineering Task Force), which is an organization that establishes technical standards related to the Internet, and a private MIB that is uniquely defined by a device vendor.
近年普及しているデバイス管理プログラムの中には、標準ＭＩＢのみならず、複数のベンダーのプライベートＭＩＢをサポートするものも数多く存在している。このようなデバイス管理プログラムとしては、ｓｙｓＯｂｊｅｃｔＩＤと呼ばれるＭＩＢオブジェクトに格納されたオブジェクト識別子（以下、ＯＩＤ）を参照してベンダーの判別をおこなうものが知られている（例えば、特許文献１参照）。 Among device management programs that have become widespread in recent years, there are many programs that support not only standard MIBs but also private MIBs of a plurality of vendors. As such a device management program, there is known a device for determining a vendor by referring to an object identifier (hereinafter referred to as OID) stored in a MIB object called sysObjectID (see, for example, Patent Document 1).
ここで、１ベンダーが、異なるＭＩＢをサポートする複数の機種のデバイスを提供する場合がある。従来のデバイス管理プログラムでは、こういった場合、ベンダーの判別処理の後、より詳細にデバイスの種別を判別するための手続きが必要であった。 Here, one vendor may provide a plurality of types of devices that support different MIBs. In such a case, the conventional device management program requires a procedure for discriminating the device type in more detail after the vendor discriminating process.
たとえば、複数のベンダーの複数の機種のデバイスが接続された大規模なネットワーク環境では、デバイス管理プログラムによる機種の判別処理に必要な送信パケットの数が増大してしまう。そのために、デバイス管理プログラムが動作する情報処理装置のパフォーマンス、およびシステム内のネットワークトラフィックに対する大きな障害となっていた。 For example, in a large-scale network environment in which devices of a plurality of models from a plurality of vendors are connected, the number of transmission packets required for the model determination process by the device management program increases. For this reason, the performance of the information processing apparatus on which the device management program operates and the network traffic in the system are serious obstacles.
そこで、本発明は、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）を利用して、ネットワーク上のデバイスをＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）の値により管理する管理装置であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信手段と、前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする。 Therefore, the present invention is a management device that manages devices on a network using MIB (Management Information Base) values using SNMP (Simple Network Management Protocol), and is a parent device of a node having a value that specifies a vendor. A transmission unit that transmits a GetNextRequest command specifying a node and a node indicating a specific function of the device to a target device on the network, and a reception unit that receives a GetResponse command as a response to the GetNextRequest command from the target device And analyzing the received GetResponse command to determine the vendor of the target device and the presence or absence of the specific function And determining means.
本発明によれば、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。 According to the present invention, an improvement in performance of a management apparatus that manages network devices can be expected. In addition, it can be expected that the network traffic in the system will be greatly reduced in searching for network devices and investigating functions.
以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、実施例においては、デバイス管理プログラムにより実現される処理の管理対象となるネットワークデバイスの例として、複合機能デバイスとしている。しかしながら、プリンタやスキャナを含む単機能のデバイスなどであっても、本実施例は適用可能である。 The best mode for carrying out the present invention will be described below with reference to the drawings. In the embodiment, a multifunction device is used as an example of a network device that is a management target of processing realized by the device management program. However, this embodiment can be applied even to a single function device including a printer and a scanner.
図１は、本実施例が適用されるネットワークシステムの構成例を示す図である。同図において、１００はローカルエリアネットワークである。ローカルエリアネットワーク１００には、管理装置１１０、および、複合機能デバイス１２０、１３０、１４０が接続されている。管理装置１１０では、デバイス管理プログラムが実行され、後述する手順によって複合機能デバイス１２０、１３０、１４０を管理しているものとする。
FIG. 1 is a diagram illustrating a configuration example of a network system to which the present embodiment is applied. In the figure,
図２は、本実施例が適用される管理装置１１０の構成を示すブロック図である。なお、本実施例における管理装置１１０は一般的なパーソナルコンピューターの構成を持つものとする。
FIG. 2 is a block diagram illustrating a configuration of the
ＲＯＭ２０１若しくはハードディスク（ＨＤ）２１０に記憶されたデバイス管理プログラム（詳細後述）を実行するＣＰＵ２００を備える。さらに、ＣＰＵ２００は、システムバス２０３に接続された各デバイスを総括的に制御する。２０２はＲＡＭであり、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。２０４はキーボードコントローラ（ＫＢＣ）であり、キーボード（ＫＢ）２０８や不図示のポインティングデバイス等からの指示入力を制御する。２０５はＤＩＳＰコントローラ（ＤＩＳＰＣ）であり、ディスプレイ（ＤＩＳＰ）２０９への表示を制御する。２０６はディスクコントローラ（ＤＫＣ）であり、ハードディスク（ＨＤ）２１０、フロッピー（登録商標）ディスクコントローラ（ＦＤ）２１１、ＣＤ−ＲＯＭドライブ（ＣＤ）２１２とのアクセスを制御する。２０７はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ１００を介して複合機能デバイス１２０、１３０、１４０と双方向にデータを授受する。なお、後述するすべての説明で特に断りのない限り、管理装置１１０で提供する機能の主体はＣＰＵ２００であり、ハードディスク（ＨＤ）２１０などに格納されるデバイス管理プログラムを実行することでそれら機能が実現されるものとする。また、デバイス管理プログラムは、ＣＤ−ＲＯＭなどの記憶媒体に格納された形で供給されても良く、ＣＤ−ＲＯＭドライブ２１２などによって記憶媒体からプログラムが読み取られ、ハードディスク（ＨＤ）２１０にインストールされる。ほかにも、デバイス管理プログラムはネットワークからダウンロードされる形で供給され、ハードディスク（ＨＤ）２１０にインストールされてもよい。
A
図３は、本実施例が適用されるネットワークシステムにおいて、管理装置１１０、および、複合機能デバイス１２０、１３０、１４０上で稼働するソフトウェア構成を説明するブロック図である。
FIG. 3 is a block diagram illustrating a software configuration that runs on the
枠３００内は、デバイス管理プログラムに関連するＳＮＭＰにより複合機能デバイス１２０、１３０、１４０を管理するＳＮＭＰマネージャーとしての機能モジュール群を示している。管理装置１１０において、デバイス管理プログラム３００、および、各モジュールは、ハードディスク（ＨＤ）２１０に保存されたファイルとして存在する。これらは実行時にＯＳやその他のモジュールによってＲＡＭ２０２にロードされ、ＣＰＵ２００により実行される実行形式ファイルである。
In the
３０１は、ＵＩ制御モジュールであり、キーボード（ＫＢ）２０８や不図示のポインティングデバイス等からの指示入力をコマンドに変換し、全体制御モジュール３０２に送信するモジュールである。ＵＩ制御モジュール３０１はまた、後述のモジュールによる処理を経て複合機能デバイス１２０、１３０、１４０に対しておこなった処理の結果をＤＩＳＰコントローラ（ＤＩＳＰＣ）２０５を介してディスプレイ（ＤＩＳＰ）２０９に表示する。３０２は、全体制御モジュールであり、ＵＩ制御モジュール３０１から受信したコマンドを後述のデバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５に振り分ける制御をおこなうモジュールである。さらに、全体制御モジュールは、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の処理結果を受信して、必要に応じて変換し、ＵＩ制御モジュール３０１に通知する。
３０３はデバイス管理モジュールであり、ＵＩ制御モジュール３０１から指定された特定の複合機能デバイス１２０、１３０、１４０に対して詳細な情報を取得・設定するためのモジュールである。より詳細には、デバイス管理モジュール３０３はＳＮＭＰ制御部３０７を介して複合機能デバイスの名称や設置場所、さらには、各種のネットワーク情報を取得設定するために、復号機能デバイスのＭＩＢ情報の取得・設定をおこなうためのモジュールである。３０４は、デバイス探索モジュールであり、ＳＮＭＰ制御モジュール３０７を介してネットワークに接続された複合機能デバイス１２０、１３０、１４０を探索するモジュールである。本実施例においては、複合機能デバイスに実装が期待されるＭＩＢの情報を取得するため、ＳＮＭＰの”ＧｅｔＲｅｑｕｅｓｔ”をブロードキャストやユニキャストで送信し、正常にＭＩＢの情報を取得できたデバイスを管理対象の複合機能デバイスとして認識する。３０５は、デバイス監視モジュールであり、複合機能デバイス１２０、１３０、１４０の状態を示すＭＩＢ情報を、あらかじめ設定された間隔で定期的に取得し、複合機能デバイスの障害を検出するためのモジュールである。デバイス監視モジュール３０５はさらに、取得したＭＩＢ情報から複合機能デバイス１２０、１３０、１４０の障害を検出した場合、データベースモジュール３０６に障害の履歴情報を登録するとともに、ＵＩモジュール３０１に対して障害の発生を通知する。
A
３０６は、データベースモジュールであり、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の処理結果やＳＮＭＰ制御モジュール３０７が参照するＭＩＢ情報、その他、設定された各種のパラメータが保存される。３０７は、ＳＮＭＰ制御モジュールで、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の要求に応じてＭＩＢオブジェクトのハンドリング、ＳＮＭＰパケットの送受信などをおこなうためのモジュールである。
A
一方、ＳＮＭＰエージェント３１１は、複合機能デバイス１２０上で稼働し、ＭＩＢ情報モジュール３１２を参照して、ＳＮＭＰマネージャーから送信されたＳＮＭＰパケットに応答を返すプログラムである。ＳＮＭＰエージェント３２１、３３１、および、ＭＩＢ情報モジュール３２２、３３２はそれぞれ、複合機能デバイス１３０、１４０上で稼働し、それぞれ、ＳＮＭＰエージェント３１１、および、ＭＩＢ情報モジュール３１２と同様の構成を持つものとする。
On the other hand, the SNMP
図４は、ＭＩＢの構成を示す概念図である。ＭＩＢの構成はツリー構造で示され、各ノードはＭＩＢオブジェクトと呼ばれる。各ＭＩＢオブジェクトは、それぞれ、オブジェクト識別子（ＯＩＤ）と呼ばれるＩＤが割り当てられている。ＯＩＤは、木構造の階層ごとに割り当てられた枝番により表される。例えば、ＭＩＢオブジェクト４０７のＯＩＤは、「１．３．６．１．２．１．４３」のように表される。ＳＮＭＰマネージャーは、ＳＮＭＰエージェント３１１、３２１、３３１に対して、ＯＩＤを指定して機器の情報の取得及び設定変更を要求する。
FIG. 4 is a conceptual diagram showing the configuration of the MIB. The structure of the MIB is shown in a tree structure, and each node is called a MIB object. Each MIB object is assigned an ID called an object identifier (OID). The OID is represented by a branch number assigned to each hierarchy of the tree structure. For example, the OID of the
また、ＭＩＢはエージェントの持つ機能により実装が異なっている。例えば、モデム機能を持つデバイス対しては、ＭＩＢオブジェクト４０６以下の葉ノードで示されるＭＩＢオブジェクトの実装が期待され、プリント機能を持つデバイスに対してはＭＩＢオブジェクト４０７以下のノードで示されるＭＩＢの実装が期待されている。さらに、ＭＩＢオブジェクト４０９以下は、デバイスのベンダーを示すＭＩＢオブジェクト４１０、４１１、４１２が定義され、これらベンダーを示すＭＩＢオブジェクト以下はプライベートＭＩＢと呼ばれ、各ベンダーが独自に定義するＭＩＢである。
Also, the implementation of MIB differs depending on the function of the agent. For example, a device having a modem function is expected to implement a MIB object indicated by a leaf node below the
図５は、ＳＮＭＰメッセージのデータ構造の一例を示す図である。 FIG. 5 is a diagram illustrating an example of a data structure of the SNMP message.
５００はＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）であり、後述のパラメータによって構成されるＳＮＭＰの基本的なデータユニットである。５０１は、ＰＤＵタイプフィールドであり、ＳＮＭＰのリクエストの種別を示すＩＤが設定される。ＳＮＭＰ Ｖｅｒｓｉｏｎ１（以下、ＳＮＭＰｖ１）ではＰＤＵタイプとしては、”ＧｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”、”ＳｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＲｅｓｐｏｎｓｅ”、及び、”Ｔｒａｐ”が定義されている。これらのうち”Ｔｒａｐ”については、異なるデータ構造を持ち、本実施例においては説明を省略する。５０２は、リクエストＩＤフィールドである。リクエストＩＤフィールド５０２には、ＳＮＭＰマネージャーからの要求とＳＮＭＰエージェント３１１、３２１、３３１からの応答とを一意に識別するためのリクエストＩＤが格納される。
５０３は、エラーステータスフィールドであり、ＳＮＭＰマネージャーからのＳＮＭＰリクエストにＳＮＭＰエージェント３１１、３２１、３３１が正常に応答を返せなかった場合、その理由を示すコードを格納する領域である。ＳＮＭＰｖ１における代表的なエラーステータス５０３としては以下のものがある。なお、”ＧｅｔＲｅｓｐｏｎｓｅ”以外のＰＤＵでは、エラーステータス５０３にはｎｏＥｒｒｏｒが設定される。
（１）ｎｏＥｒｒｏｒ：正常終了
（２）ｔｏｏＢｉｇ：要求されたＳＮＭＰリクエストに対する応答がＰＤＵのサイズ制限を超えてしまう
（３）ｎｏＳｕｃｈＮａｍｅ：ＳＮＭＰリクエストで要求されたＭＩＢオブジェクトが実装されていない
（４）ｂａｄＶａｌｕｅ：”ＳｅｔＲｅｑｕｅｓｔ”で要求された値がＭＩＢの定義に矛盾している
（５）ｒｅａｄＯｎｌｙ：読み出しのみ可能なＭＩＢオブジェクトに対して”ＳｅｔＲｅｑｕｅｓｔ”が要求された
（６）ｇｅｎＥｒｒｏｒ：上記以外のエラーが発生した
(1) noError: normal end (2) tooBig: response to the requested SNMP request exceeds the size limit of the PDU (3) noSuchName: MIB object requested by the SNMP request is not implemented (4) badValue : The value requested in "SetRequest" is inconsistent with the MIB definition (5) readOnly: "SetRequest" is requested for a MIB object that can only be read (6) genError: An error other than the above occurs did
５０４は、エラーインデックスフィールドである。ＳＮＭＰのＰＤＵ５００では、後述の変数バインディングリスト５０５（以下、ＶＢＬ５０５）において複数のＭＩＢオブジェクトの指定が可能である。エラーインデックスフィールド５０４に格納されるエラーインデックスは、これら複数のＭＩＢオブジェクトのうち、エラーが発生したＭＩＢオブジェクトを示す最も小さい値が格納される。また、エラーステータスがｎｏＥｒｒｏｒの場合、本エラーインデックスには０が設定される。５０５は、ＶＢＬ（Ｖａｒｉａｂｌｅ Ｂｉｎｄｉｎｇ Ｌｉｓｔ）フィールドであり、１以上のＭＩＢのＯＩＤ、および、その値が情報が格納されている。
５０６、５０８、５１０は、ＯＩＤフィールドであり、５０７、５０９、５１１は値フィールドである。ＯＩＤフィールド５０６、５０８、５１０には、各ＭＩＢオブジェクトに割り当てられた実際のＯＩＤの後にインスタンス識別子を付け加えた値が格納される。インスタンス識別子は、ＭＩＢオブジェクトが単一の値しか有さない場合には「０」が設定される。
一方、ＭＩＢオブジェクトがテーブル形式で複数の値を有する場合には、テーブル内の夫々の値に対して「１」以上の連続であるとは限られない数字により表されるインスタンス識別子が付与される。この場合に、従来では、ＰＤＵとして”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を用い、これを繰り返し呼び出すことにより、テーブル内の全ての情報を取得することが可能である。また、”ＧｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”の場合、値フィールド５０７、５０９、５１１にはＮＵＬＬが指定される。”ＳｅｔＲｅｑｕｅｓｔ”の場合、値フィールド５０７、５０９、５１１には、デバイス管理プログラム３００が複合機能デバイス１２０、１３０、１４０に対して設定する値が格納される。さらに、”ＧｅｔＲｅｓｐｏｎｓｅ”の場合、値フィールド５０７、５０９、５１１には、複合機能デバイス１２０、１３０、１４０においてＭＩＢに設定されている値が格納される。
On the other hand, when the MIB object has a plurality of values in a table format, an instance identifier represented by a number that is not necessarily continuous with “1” or more is assigned to each value in the table. . In this case, conventionally, “GetNextRequest” is used as a PDU, and it is possible to obtain all information in the table by repeatedly calling it. In the case of “GetRequest” and “GetNextRequest”, NULL is specified in the value fields 507, 509, and 511. In the case of “SetRequest”, values set to the
図６は、ＳＮＭＰのパケットの送受信の特徴を示すシーケンス図であり、図６（ａ）は後述のＳＮＭＰエージェント６２０におけるＭＩＢの実装状況を示す図である。
FIG. 6 is a sequence diagram showing the characteristics of SNMP packet transmission / reception, and FIG. 6A is a diagram showing the MIB implementation status in the
ＭＩＢオブジェクト６０３、６０４、６０６は複合機能デバイスに実装されており、値として「ａ」、「ｂ」、「ｃ」が設定されているが、ＭＩＢオブジェクト６０５については複合機能デバイスに実装されていないものとする。また、根ノードにあたる６００、および、内部ノードにあたる６０１、６０２については値をもたず、定義上のみに存在するＭＩＢオブジェクトであり、ＭＩＢオブジェクト６０５と同様に実装されていないものとする。
MIB objects 603, 604, and 606 are mounted on the multi-function device, and “a”, “b”, and “c” are set as values, but the
図６（ｂ）は、ＳＮＭＰマネージャー６１０と図６（ａ）のツリー構造によって示されるＭＩＢが実装されたＳＮＭＰエージェント６２０間におけるＳＮＭＰパケットの送受信の様子を示すシーケンス図である。
FIG. 6B is a sequence diagram showing how SNMP packets are transmitted and received between the SNMP manager 610 and the
６３０では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。ここで、最後の「０」は上述のインスタンス識別子にあたるため、ＯＩＤ「１．２．１．０」は図６（ａ）のＭＩＢオブジェクト６０３を示している。６３１では、”ＧｅｔＲｅｑｕｅｓｔ” ６３０を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ＭＩＢオブジェクト６０３は図６（ａ）の記載の通り、値として「ａ」が設定されているため、ＯＩＤ「１．２．１．０」の値として「ａ」を返す。
In 630, “GetRequest” for the OID “1.2.1.0” is transmitted from the SNMP manager 610 to the
６３２では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６３３では、”ＧｅｔＲｅｑｕｅｓｔ”６３２を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ここで、ＯＩＤ「１．２．０」は図６（ａ）のＭＩＢオブジェクト６０１を示しているが、ＭＩＢオブジェクト６０１はＭＩＢツリーの内部ノードにあたるため、ＳＮＭＰエージェント６２０には実装されていないものとする。したがって、”ＧｅｔＲｅｓｐｏｎｓｅ”６３３は、エラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
In 632, “GetRequest” for the OID “1.2.0” is transmitted from the SNMP manager 610 to the
６３４では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０に図６（ａ）のＭＩＢオブジェクト６０１を示すＯＩＤ「１．２」の次のインスタンスを要求するために”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。ここで、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”の場合、指定したＭＩＢオブジェクトの次のインスタンスを要求するため、本実施例においては、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”で指定するＯＩＤにインスタンス識別子である「０」を付加しないこととする。６３５では、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対してＭＩＢオブジェクト６０１の次のインスタンスであるＭＩＢオブジェクト６０３を示すＯＩＤ「１．２．１．０」とその値である「ａ」が”ＧｅｔＲｅｓｐｏｎｓｅ”として通知される。
In 634, “GetNextRequest” is transmitted from the SNMP manager 610 to the
６３６では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．４．５．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６３７では、”ＧｅｔＲｅｑｕｅｓｔ”６３６を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ここで、ＯＩＤ「１．４．５．０」は図６（ａ）のＭＩＢオブジェクト６０５を示しているが、上記記載の通りＳＮＭＰエージェント６２０には実装されていない。したがって、”ＧｅｔＲｅｓｐｏｎｓｅ”６３７はエラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
In 636, “GetRequest” for the OID “1.4.5.0” is transmitted from the SNMP manager 610 to the
６３８では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０に図６（ａ）のＭＩＢオブジェクト６０５を示すＯＩＤ「１．４．５」の次のインスタンスを要求するために”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。６３９では、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対してＭＩＢオブジェクト６０５の次のインスタンスであるＭＩＢオブジェクト６０６を示すＯＩＤ「１．２．７．０」とその値である「ｃ」が”ＧｅｔＲｅｓｐｏｎｓｅ”として通知される。
In 638, “GetNextRequest” is transmitted from the SNMP manager 610 to the
６４０では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１．０」および「１．４．５．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６４１では、”ＧｅｔＲｅｑｕｅｓｔ”を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。なお、ＭＩＢオブジェクト６０５はＳＮＭＰエージェント６２０には実装されていないＭＩＢオブジェクトであるため、”ＧｅｔＲｅｓｐｏｎｓｅ”６３７はエラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
In 640, “GetRequest” for the OIDs “1.2.1.0” and “1.4.5.0” is transmitted from the SNMP manager 610 to the
６４２では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１」（ＭＩＢオブジェクト６０３）、および、「１．４．５」（ＭＩＢオブジェクト６０５）に対する”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。６４３では、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”６４２を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。なお、ＭＩＢオブジェクト６０３、および、６０５の次のインスタンスは、それぞれ、ＭＩＢオブジェクト６０４、および、６０６である。したがって、６４３では、”ＧｅｔＲｅｓｐｏｎｓｅ”として、ＯＩＤ「１．２．３．０」、および、「１．４．７．０」と、それぞれの値として「ｂ」、および、「ｃ」が送信される。
In 642, “GetNextRequest” for the OID “1.2.1” (MIB object 603) and “1.4.5” (MIB object 605) is transmitted from the SNMP manager 610 to the
以上、図６において説明したように”ＧｅｔＲｅｑｕｅｓｔ”では、ＭＩＢツリーの内部ノードにあたるＭＩＢオブジェクトや実装されていないＭＩＢオブジェクト、さらには、それらを含む複数のＯＩＤを同一のパケットで送信した場合、必ずエラーが発生する。一方、ＧｅｔＮｅｘｔＲｅｑｕｅｓでは、ＭＩＢツリーの内部ノードにあたるＭＩＢオブジェクトや実装されていないＭＩＢオブジェクト、さらには、それらを含む複数のＯＩＤを同一のパケットで送信しても、エラーとなる可能性は極めて少ない。 As described above with reference to FIG. 6, in “GetRequest”, an MIB object corresponding to an internal node of the MIB tree, an unimplemented MIB object, or a plurality of OIDs including them are transmitted in the same packet without fail. Will occur. On the other hand, in GetNextRequests, there is very little possibility of an error even if an MIB object corresponding to an internal node of the MIB tree, an MIB object that is not mounted, or a plurality of OIDs including them are transmitted in the same packet.
図７は、管理装置において行われる処理を説明するためのフローチャートである。本処理では、多数のネットワークデバイスの中から複合機能デバイス１２０、１３０、１４０を検出するため、それらデバイスのベンダー、モデム機能の有無、プリント機能の有無を判別するものとする。なお、本実施例においては、ＰＩＮＧ等の手段で事前に何らかのデバイスに割り当てられているＩＰアドレスを判別しており、本処理はそれらのＩＰアドレスを用いてベンダー、および、機能の判別処理をおこなうものとする。
FIG. 7 is a flowchart for explaining processing performed in the management apparatus. In this process, since the
Ｓ７００では、ネットワークデバイスのベンダーを識別するために図４のＭＩＢオブジェクト４０９のＯＩＤである「１．３．６．１．１．４」を図５に示すＶＢＬ５０５に設定し、Ｓ７０１に移行する。Ｓ７０１では、ネットワークデバイスのモデムの有無を判別するため、図４のＭＩＢオブジェクト４０６のＯＩＤである「１．３．６．１．２．１．３８」を図５に示すＶＢＬ５０５に設定し、Ｓ７０２に移行する。Ｓ７０２では、ネットワークデバイスのプリンタの有無を判別するため、図４のＭＩＢオブジェクト４０７のＯＩＤである「１．３．６．１．２．１．４３」を図５に示すＶＢＬ５０５に設定し、Ｓ７０３に移行する。
In S700, in order to identify the vendor of the network device, “1.3.6.1.1.4” which is the OID of the
Ｓ７０３では、Ｓ７００〜Ｓ７０２でＯＩＤを設定したＶＢＬ５０５を含むＰＤＵ５００のＰＤＵタイプ５０１に”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を指定してＳＮＭＰパケットを送信し、Ｓ７０４に移行する。
In S703, an SNMP packet is transmitted by specifying “GetNextRequest” in the
Ｓ７０４では、Ｓ７０３においてパケット送信したＩＰアドレスからのＳＮＭＰパケットを受信したかどうかの判断がおこなわれる。本ステップにおいて、ＳＮＭＰパケットを受信したと判断した場合には、Ｓ７０５に移行し、それ以外の場合はＳ７０４に戻る。 In S704, it is determined whether an SNMP packet has been received from the IP address that transmitted the packet in S703. If it is determined in this step that an SNMP packet has been received, the process proceeds to S705. Otherwise, the process returns to S704.
Ｓ７０５では、Ｓ７０４で受信したＳＮＭＰパケットのＰＤＵタイプ５０１の確認がおこなわれる。本ステップにおいて、ＰＤＵタイプ５０１に設定された値が”ＧｅｔＲｅｓｐｏｎｓｅ”を示すものであると判断した場合は、Ｓ７０６に移行し、それ以外の場合は、Ｓ７０４に戻る。
In S705, the
Ｓ７０６では、Ｓ７０５で受信したパケットが”ＧｅｔＲｅｓｐｏｎｓｅ”であると判断した場合にリクエストＩＤ５０２の値を参照する。本ステップにおいて、リクエストＩＤ５０２が、Ｓ７０３で送信したＳＮＭＰパケットのものと一致する場合にはＳ７０７に移行し、それ以外の場合にはＳ７０４に戻る。
In S706, when it is determined that the packet received in S705 is “GetResponse”, the value of the
Ｓ７０７では、Ｓ７０４で受信したＳＮＭＰパケットにおけるエラーステータス５０３の確認がおこなわれる。本ステップにおいて、エラーステータス５０３がｎｏＥｒｒｏｒ（ｎｕｌｌ）であると判断した場合には、Ｓ７０９に移行し、それ以外の場合には、Ｓ７０８に移行する。Ｓ７０８では、Ｓ７０７においてエラーステータス５０３がｎｏＥｒｒｏｒではないと判断した場合の処理として、エラーステータス５０３に設定された値に応じたエラー処理を実行して処理を終了する。
In S707, the
Ｓ７０９では、Ｓ７０７においてエラーステータス５０３がｎｏＥｒｒｏｒであると判断した場合にＳ７０４で受信したＳＮＭＰパケットのＶＢＬ５０５の先頭に格納されたＯＩＤ５０６を参照し、Ｓ７１０に移行する。Ｓ７１０では、Ｓ７０９で参照したＯＩＤ５０６に、後述のベンダー判別テーブル（図８（ａ））に登録されているＯＩＤが含まれているかどうかの判別がおこなわれる。本ステップにおいて、ＯＩＤ５０６がベンダー判別テーブルに登録されたＯＩＤを含んでいると判断した場合には、Ｓ７１２に移行し、それ以外の場合には、Ｓ７１１に移行する。Ｓ７１１では、Ｓ７０３でパケット送信したＩＰアドレスのデバイス（対象デバイス）はサポート外として処理を終了する。
In S709, if it is determined in S707 that the
Ｓ７１２では、Ｓ７０４で受信したＳＮＭＰパケットのＶＢＬ５０５の２番目のＯＩＤ５０８を参照し、Ｓ７１３に移行する。Ｓ７１３では、Ｓ７１２で参照した２番目のＯＩＤ５０８にモデム機能を含むことを示すＯＩＤ４０６（「１．３．６．１．２．１．３８」）が含まれているかどうかの判断がおこなわれる。例えば、「１．３．６．１．２．１．３８．＊」といった値が返却された場合にはモデム機能を含むことを示すＯＩＤ４０６が含まれるので、対象デバイスがモデム機能を持つことが判定できる。一方、「１．３．６．１．２．１．３９．＊」といった値が返却される場合には対象デバイスがモデム機能を持たないことを判定できる。本ステップにおいて、２番目のＯＩＤ５０８にＯＩＤ４０６が含まれていると判断した場合にはＳ７１５に移行し、それ以外の場合にはＳ７１４に移行する。Ｓ７１４では、Ｓ７０３でパケット送信したＩＰアドレスのデバイス（対象デバイス）がモデム機能はないと判断してＳ７１６に移行する。一方、Ｓ７１５では、対象デバイスがモデム機能を持つと判断してＳ７１６に移行する。
In S712, the
Ｓ７１６では、Ｓ７０４で対象デバイスから受信したＳＮＭＰパケットのＶＢＬ５０５の３番目のＯＩＤ５１０を参照し、Ｓ７１７に移行する。Ｓ７１７では、Ｓ７１６で参照した３番目のＯＩＤ５１０にプリント機能を含むことを示すＯＩＤ４０７（「１．３．６．１．２．１．４３」）が含まれているかどうかの判断がおこなわれる。本ステップにおいて、３番目のＯＩＤ５１０にＯＩＤ４０７が含まれていると判断した場合にＳ７１９に移行し、それ以外の場合は、Ｓ７１８に移行する。Ｓ７１８では、対象デバイスがプリント機能を備えていないと判断して処理を終了する。Ｓ７１９では、対象デバイスがプリント機能を備えていると判断して処理を終了する。
In S716, the
図８は、本実施例において、管理対象デバイスのベンダー、および、機能を判別するための判別テーブルである。 FIG. 8 is a discrimination table for discriminating vendors and functions of managed devices in this embodiment.
図８（ａ）は、ベンダー判別用のテーブルであり、８００はデバイス管理プログラム３００がサポートするベンダー名を示している。一方、８０１は、デバイス管理プログラムがサポートするベンダーのプライベートＭＩＢのプリフィックスを示している。図７のＳ７１０では、受信した”ＧｅｔＲｅｓｐｏｎｓｅ”のＯＩＤに図８（ａ）で定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスのベンダーが判別される。
FIG. 8A is a table for identifying a vendor, and 800 indicates a vendor name supported by the
一方、図８（ｂ）は、機能判別用のテーブルであり、８１０はデバイスに実装された機能名を示している。一方、８１１はデバイスが８１０で示す機能をサポートするにあたって実装が期待されるＯＩＤのプリフィックスを示している。図７のＳ７１３、および、Ｓ７１７では、受信した”ＧｅｔＲｅｓｐｏｎｓｅ”のＯＩＤに本図８（ｂ）で定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスの機能が判別される。 On the other hand, FIG. 8B is a function determination table, and 810 indicates a function name installed in the device. On the other hand, 811 indicates an OID prefix expected to be implemented when the device supports the function indicated by 810. In S713 and S717 of FIG. 7, it is determined whether the prefix defined in FIG. 8B is included in the received OID of “GetResponse”, and the function of the device is determined.
以上のように、本発明では、デバイス管理プログラム３００により、管理対象となるデバイスに対して”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を送信し、”ＧｅｔＲｅｓｐｏｎｓｅ”に含まれるＯＩＤの構成からベンダーや機能をまとめて判別する機能を提供する。これにより、管理対象となるデバイスに実装が保証されていない複数のＭＩＢを１つのリクエストとして送信できるため、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。
As described above, according to the present invention, the
Claims (6)
ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、
前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信手段と、
前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする管理装置。 A management device that uses SNMP (Simple Network Management Protocol) to manage devices on a network based on MIB (Management Information Base) values,
Transmitting means for transmitting a GetNextRequest command specifying a parent node of a node having a value for specifying a vendor, a node indicating a specific function of the device, and a target device on the network;
Receiving means for receiving a GetResponse command as a response to the GetNextRequest command from the target device;
A management apparatus comprising: a determination unit that determines the vendor of the target device and the presence or absence of the specific function by analyzing the received GetResponse command.
前記判別手段は、前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することで判別した前記対象デバイスのベンダーが前記テーブルに登録されていない場合には、前記特定の機能に関する判別を行わないことを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。 Holding means for holding a table in which vendors supported by the management device are registered;
The determination unit does not perform determination regarding the specific function when a vendor of the target device determined by analyzing the received GetResponse command is not registered in the table. The management device according to any one of 1 to 3.
ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信工程と、
前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信工程と、
前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別工程とを有することを特徴とする管理方法。 A management method in a management apparatus that manages devices on a network using MIB (Management Information Base) values using SNMP (Simple Network Management Protocol),
A transmitting step of transmitting a GetNextRequest command specifying a parent node of a node having a value for specifying a vendor and a node indicating a specific function of the device to a target device on the network;
A receiving step of receiving a GetResponse command as a response to the GetNextRequest command from the target device;
A management method comprising: a determination step of determining the vendor of the target device and the presence or absence of the specific function by analyzing the received GetResponse command.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011024019A JP2012164134A (en) | 2011-02-07 | 2011-02-07 | Management device, management method, and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2011024019A JP2012164134A (en) | 2011-02-07 | 2011-02-07 | Management device, management method, and program |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2012164134A true JP2012164134A (en) | 2012-08-30 |
Family
ID=46843467
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2011024019A Withdrawn JP2012164134A (en) | 2011-02-07 | 2011-02-07 | Management device, management method, and program |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2012164134A (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014164314A (en) * | 2013-02-21 | 2014-09-08 | Canon Inc | Management apparatus, control method thereof, and program |
| US10028108B2 (en) | 2015-03-31 | 2018-07-17 | Brother Kogyo Kabushiki Kaisha | Communication device and setting device for communicating a plurality of setting values related to a plurality of setting items |
| CN110851086A (en) * | 2019-10-11 | 2020-02-28 | 杭州珐珞斯科技有限公司 | Data reading method, device, system and equipment of printing equipment |
-
2011
- 2011-02-07 JP JP2011024019A patent/JP2012164134A/en not_active Withdrawn
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2014164314A (en) * | 2013-02-21 | 2014-09-08 | Canon Inc | Management apparatus, control method thereof, and program |
| US10028108B2 (en) | 2015-03-31 | 2018-07-17 | Brother Kogyo Kabushiki Kaisha | Communication device and setting device for communicating a plurality of setting values related to a plurality of setting items |
| CN110851086A (en) * | 2019-10-11 | 2020-02-28 | 杭州珐珞斯科技有限公司 | Data reading method, device, system and equipment of printing equipment |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10680874B2 (en) | Network service fault handling method, service management system, and system management module | |
| RU2562438C2 (en) | Network system and network management method | |
| EP1276275B1 (en) | Management method for network apparatus | |
| EP3961987A1 (en) | Intent-based telemetry collection service | |
| JP5093598B2 (en) | Control relay program, control relay device, and control relay method | |
| US9742639B1 (en) | Intelligent network resource discovery and monitoring | |
| JP4988674B2 (en) | Network monitoring device, network monitoring method, and network monitoring program | |
| US11456920B2 (en) | Mechanisms for cloud-based configuration and management of network devices using network mediators implemented in the network devices | |
| JP7251534B2 (en) | A cloud-based configuration and management mechanism for network devices using a network arbiter implemented separately from the network devices | |
| US8935386B2 (en) | Network topology | |
| CN101447895A (en) | Collocation method for synchronizing network management and network element and device thereof | |
| EP2587725A1 (en) | Network management interface for heterogeneous data networks and system using the same | |
| EP4024770A1 (en) | Data processing method and apparatus, and computer storage medium | |
| JP5617304B2 (en) | Switching device, information processing device, and fault notification control program | |
| JP2016536920A (en) | Apparatus and method for network performance monitoring | |
| US11038898B2 (en) | Slow protocol packet processing method and related apparatus | |
| WO2020010906A1 (en) | Method and device for operating system (os) batch installation, and network device | |
| JP2012164134A (en) | Management device, management method, and program | |
| JP5181958B2 (en) | Device management apparatus, device management system, device information acquisition program, and recording medium recording the program | |
| JP5383927B2 (en) | Method and management device for discovering communication devices connected to communication network | |
| CN113824595B (en) | Link switching control method and device and gateway equipment | |
| JP2006011703A (en) | Information collection device, information collection method, information collection program and device management system | |
| US20130031227A1 (en) | Transmission of configuration to a device for provisioning in a network | |
| CN112751701B (en) | System, method and computer readable medium for managing network devices | |
| KR101070522B1 (en) | System and method for monitoring and blocking of spoofing attack |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20140513 |