JP4763227B2 - Ｓｎｍｐエージェント装置 - Google Patents
Ｓｎｍｐエージェント装置 Download PDFInfo
- Publication number
- JP4763227B2 JP4763227B2 JP2003091445A JP2003091445A JP4763227B2 JP 4763227 B2 JP4763227 B2 JP 4763227B2 JP 2003091445 A JP2003091445 A JP 2003091445A JP 2003091445 A JP2003091445 A JP 2003091445A JP 4763227 B2 JP4763227 B2 JP 4763227B2
- Authority
- JP
- Japan
- Prior art keywords
- error
- manager
- snmp
- detailed
- factor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明はＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）エージェント装置に関し、更に詳しくは１台以上のＳＮＭＰマネージャに対して、ｇｅｎＥｒｒ（ｇｅｎｅｒａｌ Ｅｒｒｏｒ）発生時に、エラーの詳細要因を読み出す手段を提供するＳＮＭＰエージェント装置に関する。ここでＳＮＭＰは、ネットワーク管理プロトコルの一種である。
【０００２】
【従来の技術】
ＳＮＭＰｖ１プロトコルは、ＲＦＣ１１５７で標準化されている。ＳＮＭＰマネージャ（以下、マネージャと略す）と、ＳＮＭＰエージェント装置（以下、エージェントと略す）との間で情報の要求と応答を伝達するのは、ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）であり、その中にはエラーの有無や種類を表わすためのエラーステータス（Ｅｒｒｏｒ Ｓｔａｔｕｓ）フィールドが用意されている。
【０００３】
しかしながら、Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドが取りうる値は６種類に限られており、エラーの種類に該当するものがない場合は、全てｇｅｎＥｒｒとなる。ＲＦＣ１９０１〜１９０８でＳＮＭＰｖ２が標準化されているが、ＰＤＵの構造はＳＮＭＰｖ１と同じで、Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドが取りうる値が拡張されている。
【０００４】
しかしながら、全てのエラーをカバーできるものではなく、結局エラーの種類に該当するものがない場合は、全てｇｅｎＥｒｒとなる。Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドでは、ｇｅｎＥｒｒとしてまとめられてしまうようなエージェント固有のエラーをマネージャから読み出すための手段として、エラーの詳細要因を表わすＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ：管理情報ベース）を定義する方法がある。
【０００５】
ＭＩＢの各オブジェクトは、図１０に示すようなツリー構造として表わすことができ、その中のｅｎｔｅｒｐｒｉｓｅｓサブツリー配下には、各ベンダ（コンピュータ，周辺デバイスの販売業者）が自社製品用のＭＩＢを登録する。その中に、エラーの詳細要因ＭＩＢを定義しておくことが可能である。この場合、エラー詳細要因ＭＩＢで読み出せるのはエージェントで最後に処理された要因に対応するエラー状況である。
【０００６】
従来のこの種の技術としては、ＳＮＭＰマネージャと複数のＳＮＭＰエージェントとが接続されたシステムにおいて、ＳＮＭＰマネージャは、ＳＮＭＰエージェントからのＭＩＢ情報に基づいて、ネットワーク上の障害を検出し、内蔵するＭＩＢデータベースに蓄積されたＭＩＢ情報のうち、ネットワーク上の障害に対応するネットワーク情報を更新するようにしたものがある（例えば特許文献１参照）。
【０００７】
【特許文献１】
特開２００２−８４２７９号公報（第３頁、第４頁、図１）
【０００８】
【発明が解決しようとする課題】
前述のエラーの詳細要因を表わすＭＩＢを定義した場合、エージェントからＥｒｒｏｒ ＳｔａｔｕｓがｇｅｎＥｒｒであるようなＧｅｔ ＲｅｓｐｏｎｓｅＰＤＵを受信したマネージャは、更にエラー詳細要因ＭＩＢをＧｅｔ（獲得）することで、エラーの詳細要因を知ることができる。
【０００９】
しかしながら、マネージャが複数存在すると、図１１に示すようにエラー発生からエラー詳細要因ＭＩＢの獲得まで更に他のマネージャからの要求が発生する可能性があり、この場合、エラー詳細情報が上書きされるために実際に得られるエラー詳細要因は他のマネージャからの要求に対応するものになってしまう。
【００１０】
図１１は動作シーケンス例を示す図である。図に示す例は、２台のＳＮＭＰマネージャ１１（＃１），１２（＃２）と、１台のＳＮＭＰエージェント装置２１とが接続された場合を示している。
【００１１】
今、マネージャ＃１からエージェント装置２１に対してＳｅｔ Ｒｅｑｕｅｓｔを通知したものとする（Ｓ１）。この時、エージェント装置２１側でエラーが発生すると（Ｓ２）、エージェント装置２１側で詳細要因ＭＩＢ値が設定される（Ｓ３）。そして、エージェント装置２１からマネージャ＃１に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ４）。
【００１２】
次に、マネージャ＃２よりエージェント装置２１に対してＳｅｔ Ｒｅｑｕｅｓｔが通知される（Ｓ５）。そして、同じようにエージェント装置２１でエラーが発生すると（Ｓ６）、詳細要因ＭＩＢ値が設定される（Ｓ７）。この時、マネージャ＃１の詳細要因はマネージャ＃２の詳細要因によって上書きされて消える。エージェント装置２１から、マネージャ＃２に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）が返る（Ｓ８）。
【００１３】
ここで、マネージャ＃１からエージェント装置２１に対して詳細要因を知るためのＧｅｔ Ｒｅｑｕｅｓｔが発行されると（Ｓ９）、エージェント装置２１では詳細要因ＭＩＢ値を読み出し（Ｓ１０）、エージェント装置２１からマネージャ＃１に対して詳細要因を示すＧｅｔ Ｒｅｓｐｏｎｓｅが返るが、このＧｅｔ
Ｒｅｓｐｏｎｓｅは、マネージャ＃２に対する詳細要因である。
【００１４】
本発明はこのような課題に鑑みてなされたものであって、複数のマネージャからの要求が競合した場合でも、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することを目的としている。
【００１５】
【課題を解決するための手段】
（１）請求項１記載の発明は、以下の通りである。図１は本発明の原理ブロック図である。図１１と同一のものは、同一の符号を付して示す。１１はエージェントを管理するＳＮＭＰマネージャ（以下、マネージャと略す）、１００はマネージャ１１とネットワーク２０を介して接続されるＳＮＭＰエージェント装置（以下、エージェントと略す）である。エージェント１００において、１０１はエージェント１００からの要求の受け付けや、応答と通知の生成や送信等を行なうＳＮＭＰ処理部、１０２は個々にマネージャ１１から読み出せる情報を持つデバイスである。デバイス１０２はＳＮＭＰ処理部１０１と接続されている。図では、マネージャ１１として＃１，＃２の２つの場合を示しているが、マネージャの数は２つに限るものではない。＃１と＃２のマネージャ１１は、それぞれ独立に動作する。
【００１６】
１１１はマネージャ１１のそれぞれに対応したエラー詳細要因を格納するためのエラー詳細要因記憶部である。図では、＃１と＃２の２つ設けられた場合を示している。エラー詳細要因記憶部＃１はマネージャ＃１のエラー詳細要因を保持し、エラー詳細要因記憶部＃２はマネージャ＃２のエラー詳細要因を保持する。
【００１７】
該エラー詳細要因記憶部１１１は請求項１のエラーの詳細要因をＳＮＭＰマネージャ毎に保持する手段を構成しており、ＳＮＭＰ処理部１０１が請求項１の保持している詳細要因をＳＮＭＰマネージャから読み出す手段を構成している。
【００１８】
このように構成すれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎に設けられたエラー詳細要因記憶部１１１に記憶されるので、エージェントで発生したエラーの詳細要因が後から発生したエラー詳細要因によって上書きされることがなくなり、エラー詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
（２）請求項２記載の発明は、前記処理手段がＳＮＭＰマネージャの識別情報をインデックスとして読み出すことを特徴とする。
【００１９】
このように構成すれば、インデックスネットワークより読み出すデータ領域を決定することができる。
（３）請求項３記載の発明は、前記処理手段が、ＳＮＭＰマネージャの識別情報をインデックスなしで読み出すことを特徴とする。
【００２０】
このように構成すれば、問い合わせ要求の発信元のネットワークアドレスより読み出すデータ領域を決定することができる。
（４）請求項４記載の発明は、ｇｅｎＥｒｒが発生した場合に、ＳＮＭＰマネージャに対する応答と共に前記エラーの詳細要因をＳＮＭＰマネージャに別途通知する手段を更に具備していることを特徴とする。
このように構成すれば、マネージャがエージェントに対して問い合わせをすることなく、その詳細要因を知ることができる。
【００２１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
【００２２】
先ず、図１に示す構成を用いて、本発明の動作を説明する。本発明は、マネージャ１１からの要求に対して、エージェント１００は図２に示すようなシーケンスで動作する。図２は本発明の動作シーケンス例を示す図である。先ず、マネージャ＃１からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ１）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ２）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ３）。
【００２３】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃１に対する応答を返す前にエラー詳細要因記憶部＃１にエラーの詳細要因を格納する（Ｓ４）。格納するデータ領域は、図３に示すように、マネージャ識別情報１５１と、エラー詳細要因データ１５２から構成されており、マネージャ識別情報１５１は、ＩＰアドレス等のネットワークアドレスとする。どのデータ領域に格納するかの決定には、マネージャ１１からの要求に含まれる送信元ネットワークアドレスを用いる。
【００２４】
ＳＮＭＰ ＰＤＵ転送をＰＤＵ／ＩＰで行なう場合のＩＰデータグラムを示したものが図４である。図４は、ＳＮＭＰメッセージを含むＩＰデータグラムフォーマット例を示す図である。図において、３０はＩＰヘッダ、５０はＵＤＰヘッダ、６０はＳＮＭＰ ＰＤＵである。
【００２５】
ＩＰヘッダ３０は、バージョンヘッダ長３１と、サービスタイプ３２と、全長３３と、識別子３４と、フラグメント情報３５と、ＴＴＬ３６と、プロトコル３７と、ヘッダチェックサム３８と、送信元ＩＰアドレス３９と、送信先ＩＰアドレス４０と、オプション４１から構成されている。ＵＤＰヘッダ５０は、送信元ポート番号５１と、送信先ポート番号５２と、サイズ５３と、チェックサム５４から構成されている。
【００２６】
ＩＰヘッダ３０には、送信元アドレス３９が、ＵＤＰヘッダ５０には送信元ポート番号５１が含まれており、エージェント１００からマネージャ１１への応答の送信先は、要求の送信元アドレス・ポートとなる。
【００２７】
再び図２の説明にもどる。ＳＮＭＰ処理部１０１は、マネージャ＃１に対してエラーが発生したことを示すＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ５）。
【００２８】
次に、マネージャ＃２からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ６）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ７）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ８）。
【００２９】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃２に対する応答を返す前にエラー詳細要因記憶部＃２にエラーの詳細要因を格納する（Ｓ９）。ＳＮＭＰ処理部１０１は、マネージャ＃２に対してエラーが発生したことを示すＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ１０）。
【００３０】
このように、エージェント１００は、要求に対する応答を返信するために要求の送信元ネットワークアドレスを必ず知っており、図５に示すように、データ領域中のマネージャネットワークアドレスと比較すれば、一致したところが格納すべきデータ領域である。
【００３１】
ここで、マネージャ＃１から詳細要因の通知要求であるＧｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行されると（Ｓ１１）、ＳＮＭＰ処理部１０１はエラー詳細要因記憶部＃１から該当する詳細要因を読み出し（Ｓ１２）、マネージャ＃１に対して応答（Ｇｅｔ Ｒｅｓｐｏｎｓｅ）として返す（Ｓ１３）。
【００３２】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎にエラー詳細要因記憶部１１１に記憶するので、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
【００３３】
図５は要求の送信元ネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。先ず、要求の送信元であるマネージャ１１からエージェント１００に対して送信要求が送られてくるが、ＳＮＭＰ処理部１０１はこの送信要求から送信要求元アドレスを取得する（Ｓ１）。次に、ＳＮＭＰ処理部１０１は、最初のエラー詳細要因格納データ領域（エラー詳細要因記憶部１１１）から最初のデータを読み込む（Ｓ２）。
【００３４】
次に、ＳＮＭＰ処理部１０１は、エラー詳細要因格納データ領域のネットワークアドレスと要求送信元ネットワークアドレスを比較する（Ｓ３）。そして、双方のアドレスが等しいかどうかチェックする（Ｓ４）。等しくない場合には、次のエラー詳細要因格納データ領域を読み込み（Ｓ５）、ステップＳ３のアドレス比較処理に戻る。
【００３５】
ステップＳ４において、双方のアドレスが等しい場合、ＳＮＭＰ処理部１０１は、現在のエラー詳細要因格納データ領域を格納先／読み出し先領域とする（Ｓ６）。
【００３６】
前述したように、マネージャ１１からエラー詳細要因の問い合わせがあった場合には、ＳＮＭＰ処理部１０１は、格納しておいたエラー詳細要因記憶部１１１から読み出して応答する。読み出すデータ領域の決定の第１の方法は、ネットワークアドレスより行なうものであり、第２の方法は、問い合わせ要求の送信元ネットワークアドレスにより行なうものである。
【００３７】
第１の方法における読み出すデータ領域の決定方法を図６に示す。図６はインデックスのネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。ＳＮＭＰ処理部１０１は、オブジェクトＩＤのインデックス部分からネットワークアドレスを取り出す（Ｓ１）。次に、最初のエラー詳細要因格納データ領域を読み取る（Ｓ２）。
【００３８】
次に、ＳＮＭＰ処理部１０１は、エラー詳細要因格納データ領域のネットワークアドレスとインデックスのネットワークアドレスを比較する（Ｓ３）。そして、双方のネットワークアドレスが等しいかどうかチェックする（Ｓ４）。等しくない場合には、次のエラー詳細要因格納データ領域を読み込み（Ｓ５）、ステップＳ３に戻りネットワークアドレスの比較処理を行なう。双方のネットワークアドレスが等しい場合には、現在のエラー詳細要因格納データ領域を格納先／読み出し先領域とする（Ｓ６）。
【００３９】
このようにすれば、インデックスのネットワークアドレスより読み出すデータ領域を決定することができる。
【００４０】
なお、第２の方法による読み出す領域の決定方法は、格納時と同じで図５に示した通りである。このようにすれば、問い合わせ要求の送信元ネットワークアドレスより読み出すデータ領域を決定することができる。
【００４１】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でもエージェントで発生したエラーの詳細要因を正しく読み出すことが可能になる。
【００４２】
また、本発明によれば、図７に示すように、ｇｅｎＥｒｒ発生時に、マネージャに対する応答と共に、エラー詳細要因をマネージャにＴｒａｐとして通知することができる。このようにすれば、マネージャがエージェントに対して問い合わせをすることなく詳細要因を知ることができる。
【００４３】
図７はエラー詳細要因通知の動作シーケンス図である。先ず、マネージャ＃２からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ１）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ２）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ３）。
【００４４】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃２に対する応答を返す前にエラー詳細要因記憶部＃２にエラーの詳細要因を格納する（Ｓ４）。そして、ＳＮＭＰ処理部１０１は、ＳＮＭＰマネージャ＃２に対してＴｒａｐ（詳細要因）を通知する（Ｓ６）。このようにすれば、マネージャがエージェントに対して問い合わせをすることなく詳細要因を知ることができる。
【００４５】
図８は本発明の一実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例では、ＤＳＬＡＭ（ＡＤＳＬモデム多重化）装置がエージェント１００となっている。図において、１１はマネージャであり、＃１〜＃４まで設けられた例を示している。
【００４６】
エージェント１００には、４台のマネージャ１１が登録可能であり、登録した以外のマネージャからの要求は受け付けない。エージェント１００において、２００は装置全体の制御部と上位装置とのインタフェース部を持つＣＯＭパッケージ、３０１はＡＤＳＬ回線とのインタフェース部を持つＬＩＦパッケージでありそれぞれ活線挿抜が可能である。ＬＩＦパッケージ３０１は＃１〜＃ｎまでのｎ個設けられている。
【００４７】
エージェントとしての機能は、ＣＯＭパッケージ２００にて行なわれ、１０１がＳＮＭＰ処理部、１１１はエラー詳細要因記憶部である。該エラー詳細要因記憶部１１１は、マネージャ１１の数に対応して＃１〜＃４までの４個設けられている。２２１はＳＮＭＰ処理部１０１及びＬＩＦパッケージ３０１と接続されるパッケージ間通信部である。このように構成された装置の動作を説明すれば、以下の通りである。
【００４８】
ＳＮＭＰによるＬＩＦパッケージに関する情報の読み出しや制御の際、ＳＮＭＰ処理部１０１は、パッケージ間通信部２２１を通してＬＩＦパッケージ３０１と通信を行なうが、該当パッケージが挿入されていない場合や故障中である場合は通信を行なうことはできず、装置固有のエラーが発生する。このように、ＳＮＭＰ処理において装置固有のエラーが発生した場合は、マネージャ１１に対してエラーステータス（Ｅｒｒｏｒ Ｓｔａｔｕｓ）がｇｅｎＥｒｒであるＧｅｔ Ｒｅｓｐｏｎｓｅを返すと共に、マネージャ１１に対応するエラー詳細要因記憶部１１１にエラーの詳細要因を格納しておく。
【００４９】
エラーが発生しなかった時は、マネージャ１１に対応するエラー詳細要因記憶部１１１をクリアしておく。これにより、あるマネージャからの要求が原因で発生したｇｅｎＥｒｒの詳細要因は、それ以降に同一マネージャから何らかの要求があるまで保持され、他のマネージャからの影響を受けることはない。
【００５０】
なお、エラー詳細要因ＭＩＢのゲット（Ｇｅｔ）では、エラー詳細要因格納用データ領域はクリアしない。これにより、図９に示すように、Ｇｅｔ Ｒｅｓｐｏｎｓｅが途中で消失した場合でも、マネージャが再度ゲットすれば、エラー詳細要因を読み出すことができる。エラー詳細要因ＭＩＢは、インデックスなしとしている。これにより、マネージャはエラー詳細要因ＭＩＢにインデックスを付与する必要がなく、従来のエラー詳細要因ＭＩＢのゲット処理をそのまま利用することができる。
【００５１】
図９は詳細要因ＭＩＢのＧｅｔ Ｒｅｓｐｏｎｓｅが消滅した場合の動作シーケンスを示す図である。図７と同一のものは、同一の符号を付して示す。マネージャ１１＃１からエラーの詳細要因を知らせて欲しい旨のＧｅｔ Ｒｅｑｕｅｓｔが発行される（Ｓ１）。ＳＮＭＰ処理部１０１はこの要求を受けると、エラー詳細要因記憶部＃１からエラー詳細要因を読み出す（Ｓ２）。この時、エラー詳細要因を読み出しても、エラー詳細要因記憶部１１１＃１の内容をクリアしない。
【００５２】
ＳＮＭＰ処理部１０１がこのエラー詳細要因をマネージャ１１にＧｅｔ Ｒｅｓｐｏｎｓｅとして送信するが、消失したものとする（Ｓ３）。この時、マネージャ１１からＧｅｔ Ｒｅｓｐｏｎｓｅ（詳細要因）が再度発行される（Ｓ４）。ＳＮＭＰ処理部１０１はこの要求を受けると、エラー詳細要因記憶部＃１から詳細要因を読み出し（Ｓ５）、マネージャ＃１に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（詳細要因）を送信する（Ｓ６）。これによれば、Ｇｅｔ Ｒｅｓｐｏｎｓｅが途中で消失した場合でも、マネージャが再度ゲットすれば、エラー詳細要因を読み出すことができる。
【００５３】
このように、本発明によれば、ＳＮＭＰエージェント装置が複数のＳＮＭＰマネージャに管理される構成において、複数のマネージャからの要求が競合した場合であっても、要求の処理の際に生じたエラーの詳細要因に関する情報をＳＮＭＰマネージャから正しく得ることができるという効果を奏する。
【００５４】
これにより、ＳＮＭＰマネージャはＳＮＭＰエージェント装置に対して要求をする前にＳＮＭＰエージェント装置の状態を詳しく知る必要がなく、またエラーが発生してもその詳細要因を得ることで、その後のアクションを決定することができ、ネットワークトラヒックの削減と操作性の向上に寄与するところが大きい。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、以下の効果が得られる。
（１）請求項１記載の発明によれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎にエラー詳細要因記憶部１１１に記憶するので、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
（２）請求項２記載の発明によれば、インデックスネットワークより読み出すデータ領域を決定することができる。
（３）請求項３記載の発明によれば、問い合わせ要求の送信元のネットワークアドレスより読み出すデータ領域を決定することができる。
（４）請求項４記載の発明によれば、マネージャがエージェントに対して問い合わせをすることなく、その詳細要因を知ることができる。
【００５６】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でも、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
【図面の簡単な説明】
【図１】本発明の原理ブロック図である。
【図２】本発明の動作シーケンス例を示す図である。
【図３】エラー詳細要因格納データ領域の構成例を示す図である。
【図４】ＳＮＭＰメッセージを含むＩＰデータグラムフォーマット例を示す図である。
【図５】要求の送信元ネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。
【図６】インデックスのネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。
【図７】エラー詳細要因通知の動作シーケンス例を示す図である。
【図８】本発明の一実施の形態例を示すブロック図である。
【図９】詳細要因ＭＩＢのＧｅｔ Ｒｅｓｐｏｎｓｅが消滅した場合の動作シーケンス例を示す図である。
【図１０】ＭＩＢツリーを示す図である。
【図１１】従来の動作シーケンス例を示す図である。
【符号の説明】
１１ ＳＮＭＰマネージャ
２０ ネットワーク
１００ ＳＮＭＰエージェント装置
１０１ ＳＮＭＰ処理部
１１１ エラー詳細要因記憶部
【発明の属する技術分野】
本発明はＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）エージェント装置に関し、更に詳しくは１台以上のＳＮＭＰマネージャに対して、ｇｅｎＥｒｒ（ｇｅｎｅｒａｌ Ｅｒｒｏｒ）発生時に、エラーの詳細要因を読み出す手段を提供するＳＮＭＰエージェント装置に関する。ここでＳＮＭＰは、ネットワーク管理プロトコルの一種である。
【０００２】
【従来の技術】
ＳＮＭＰｖ１プロトコルは、ＲＦＣ１１５７で標準化されている。ＳＮＭＰマネージャ（以下、マネージャと略す）と、ＳＮＭＰエージェント装置（以下、エージェントと略す）との間で情報の要求と応答を伝達するのは、ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）であり、その中にはエラーの有無や種類を表わすためのエラーステータス（Ｅｒｒｏｒ Ｓｔａｔｕｓ）フィールドが用意されている。
【０００３】
しかしながら、Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドが取りうる値は６種類に限られており、エラーの種類に該当するものがない場合は、全てｇｅｎＥｒｒとなる。ＲＦＣ１９０１〜１９０８でＳＮＭＰｖ２が標準化されているが、ＰＤＵの構造はＳＮＭＰｖ１と同じで、Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドが取りうる値が拡張されている。
【０００４】
しかしながら、全てのエラーをカバーできるものではなく、結局エラーの種類に該当するものがない場合は、全てｇｅｎＥｒｒとなる。Ｅｒｒｏｒ Ｓｔａｔｕｓフィールドでは、ｇｅｎＥｒｒとしてまとめられてしまうようなエージェント固有のエラーをマネージャから読み出すための手段として、エラーの詳細要因を表わすＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ：管理情報ベース）を定義する方法がある。
【０００５】
ＭＩＢの各オブジェクトは、図１０に示すようなツリー構造として表わすことができ、その中のｅｎｔｅｒｐｒｉｓｅｓサブツリー配下には、各ベンダ（コンピュータ，周辺デバイスの販売業者）が自社製品用のＭＩＢを登録する。その中に、エラーの詳細要因ＭＩＢを定義しておくことが可能である。この場合、エラー詳細要因ＭＩＢで読み出せるのはエージェントで最後に処理された要因に対応するエラー状況である。
【０００６】
従来のこの種の技術としては、ＳＮＭＰマネージャと複数のＳＮＭＰエージェントとが接続されたシステムにおいて、ＳＮＭＰマネージャは、ＳＮＭＰエージェントからのＭＩＢ情報に基づいて、ネットワーク上の障害を検出し、内蔵するＭＩＢデータベースに蓄積されたＭＩＢ情報のうち、ネットワーク上の障害に対応するネットワーク情報を更新するようにしたものがある（例えば特許文献１参照）。
【０００７】
【特許文献１】
特開２００２−８４２７９号公報（第３頁、第４頁、図１）
【０００８】
【発明が解決しようとする課題】
前述のエラーの詳細要因を表わすＭＩＢを定義した場合、エージェントからＥｒｒｏｒ ＳｔａｔｕｓがｇｅｎＥｒｒであるようなＧｅｔ ＲｅｓｐｏｎｓｅＰＤＵを受信したマネージャは、更にエラー詳細要因ＭＩＢをＧｅｔ（獲得）することで、エラーの詳細要因を知ることができる。
【０００９】
しかしながら、マネージャが複数存在すると、図１１に示すようにエラー発生からエラー詳細要因ＭＩＢの獲得まで更に他のマネージャからの要求が発生する可能性があり、この場合、エラー詳細情報が上書きされるために実際に得られるエラー詳細要因は他のマネージャからの要求に対応するものになってしまう。
【００１０】
図１１は動作シーケンス例を示す図である。図に示す例は、２台のＳＮＭＰマネージャ１１（＃１），１２（＃２）と、１台のＳＮＭＰエージェント装置２１とが接続された場合を示している。
【００１１】
今、マネージャ＃１からエージェント装置２１に対してＳｅｔ Ｒｅｑｕｅｓｔを通知したものとする（Ｓ１）。この時、エージェント装置２１側でエラーが発生すると（Ｓ２）、エージェント装置２１側で詳細要因ＭＩＢ値が設定される（Ｓ３）。そして、エージェント装置２１からマネージャ＃１に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ４）。
【００１２】
次に、マネージャ＃２よりエージェント装置２１に対してＳｅｔ Ｒｅｑｕｅｓｔが通知される（Ｓ５）。そして、同じようにエージェント装置２１でエラーが発生すると（Ｓ６）、詳細要因ＭＩＢ値が設定される（Ｓ７）。この時、マネージャ＃１の詳細要因はマネージャ＃２の詳細要因によって上書きされて消える。エージェント装置２１から、マネージャ＃２に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）が返る（Ｓ８）。
【００１３】
ここで、マネージャ＃１からエージェント装置２１に対して詳細要因を知るためのＧｅｔ Ｒｅｑｕｅｓｔが発行されると（Ｓ９）、エージェント装置２１では詳細要因ＭＩＢ値を読み出し（Ｓ１０）、エージェント装置２１からマネージャ＃１に対して詳細要因を示すＧｅｔ Ｒｅｓｐｏｎｓｅが返るが、このＧｅｔ
Ｒｅｓｐｏｎｓｅは、マネージャ＃２に対する詳細要因である。
【００１４】
本発明はこのような課題に鑑みてなされたものであって、複数のマネージャからの要求が競合した場合でも、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することを目的としている。
【００１５】
【課題を解決するための手段】
（１）請求項１記載の発明は、以下の通りである。図１は本発明の原理ブロック図である。図１１と同一のものは、同一の符号を付して示す。１１はエージェントを管理するＳＮＭＰマネージャ（以下、マネージャと略す）、１００はマネージャ１１とネットワーク２０を介して接続されるＳＮＭＰエージェント装置（以下、エージェントと略す）である。エージェント１００において、１０１はエージェント１００からの要求の受け付けや、応答と通知の生成や送信等を行なうＳＮＭＰ処理部、１０２は個々にマネージャ１１から読み出せる情報を持つデバイスである。デバイス１０２はＳＮＭＰ処理部１０１と接続されている。図では、マネージャ１１として＃１，＃２の２つの場合を示しているが、マネージャの数は２つに限るものではない。＃１と＃２のマネージャ１１は、それぞれ独立に動作する。
【００１６】
１１１はマネージャ１１のそれぞれに対応したエラー詳細要因を格納するためのエラー詳細要因記憶部である。図では、＃１と＃２の２つ設けられた場合を示している。エラー詳細要因記憶部＃１はマネージャ＃１のエラー詳細要因を保持し、エラー詳細要因記憶部＃２はマネージャ＃２のエラー詳細要因を保持する。
【００１７】
該エラー詳細要因記憶部１１１は請求項１のエラーの詳細要因をＳＮＭＰマネージャ毎に保持する手段を構成しており、ＳＮＭＰ処理部１０１が請求項１の保持している詳細要因をＳＮＭＰマネージャから読み出す手段を構成している。
【００１８】
このように構成すれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎に設けられたエラー詳細要因記憶部１１１に記憶されるので、エージェントで発生したエラーの詳細要因が後から発生したエラー詳細要因によって上書きされることがなくなり、エラー詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
（２）請求項２記載の発明は、前記処理手段がＳＮＭＰマネージャの識別情報をインデックスとして読み出すことを特徴とする。
【００１９】
このように構成すれば、インデックスネットワークより読み出すデータ領域を決定することができる。
（３）請求項３記載の発明は、前記処理手段が、ＳＮＭＰマネージャの識別情報をインデックスなしで読み出すことを特徴とする。
【００２０】
このように構成すれば、問い合わせ要求の発信元のネットワークアドレスより読み出すデータ領域を決定することができる。
（４）請求項４記載の発明は、ｇｅｎＥｒｒが発生した場合に、ＳＮＭＰマネージャに対する応答と共に前記エラーの詳細要因をＳＮＭＰマネージャに別途通知する手段を更に具備していることを特徴とする。
このように構成すれば、マネージャがエージェントに対して問い合わせをすることなく、その詳細要因を知ることができる。
【００２１】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態例を詳細に説明する。
【００２２】
先ず、図１に示す構成を用いて、本発明の動作を説明する。本発明は、マネージャ１１からの要求に対して、エージェント１００は図２に示すようなシーケンスで動作する。図２は本発明の動作シーケンス例を示す図である。先ず、マネージャ＃１からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ１）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ２）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ３）。
【００２３】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃１に対する応答を返す前にエラー詳細要因記憶部＃１にエラーの詳細要因を格納する（Ｓ４）。格納するデータ領域は、図３に示すように、マネージャ識別情報１５１と、エラー詳細要因データ１５２から構成されており、マネージャ識別情報１５１は、ＩＰアドレス等のネットワークアドレスとする。どのデータ領域に格納するかの決定には、マネージャ１１からの要求に含まれる送信元ネットワークアドレスを用いる。
【００２４】
ＳＮＭＰ ＰＤＵ転送をＰＤＵ／ＩＰで行なう場合のＩＰデータグラムを示したものが図４である。図４は、ＳＮＭＰメッセージを含むＩＰデータグラムフォーマット例を示す図である。図において、３０はＩＰヘッダ、５０はＵＤＰヘッダ、６０はＳＮＭＰ ＰＤＵである。
【００２５】
ＩＰヘッダ３０は、バージョンヘッダ長３１と、サービスタイプ３２と、全長３３と、識別子３４と、フラグメント情報３５と、ＴＴＬ３６と、プロトコル３７と、ヘッダチェックサム３８と、送信元ＩＰアドレス３９と、送信先ＩＰアドレス４０と、オプション４１から構成されている。ＵＤＰヘッダ５０は、送信元ポート番号５１と、送信先ポート番号５２と、サイズ５３と、チェックサム５４から構成されている。
【００２６】
ＩＰヘッダ３０には、送信元アドレス３９が、ＵＤＰヘッダ５０には送信元ポート番号５１が含まれており、エージェント１００からマネージャ１１への応答の送信先は、要求の送信元アドレス・ポートとなる。
【００２７】
再び図２の説明にもどる。ＳＮＭＰ処理部１０１は、マネージャ＃１に対してエラーが発生したことを示すＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ５）。
【００２８】
次に、マネージャ＃２からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ６）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ７）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ８）。
【００２９】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃２に対する応答を返す前にエラー詳細要因記憶部＃２にエラーの詳細要因を格納する（Ｓ９）。ＳＮＭＰ処理部１０１は、マネージャ＃２に対してエラーが発生したことを示すＧｅｔ Ｒｅｓｐｏｎｓｅ（ｇｅｎＥｒｒ）を返す（Ｓ１０）。
【００３０】
このように、エージェント１００は、要求に対する応答を返信するために要求の送信元ネットワークアドレスを必ず知っており、図５に示すように、データ領域中のマネージャネットワークアドレスと比較すれば、一致したところが格納すべきデータ領域である。
【００３１】
ここで、マネージャ＃１から詳細要因の通知要求であるＧｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行されると（Ｓ１１）、ＳＮＭＰ処理部１０１はエラー詳細要因記憶部＃１から該当する詳細要因を読み出し（Ｓ１２）、マネージャ＃１に対して応答（Ｇｅｔ Ｒｅｓｐｏｎｓｅ）として返す（Ｓ１３）。
【００３２】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎にエラー詳細要因記憶部１１１に記憶するので、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
【００３３】
図５は要求の送信元ネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。先ず、要求の送信元であるマネージャ１１からエージェント１００に対して送信要求が送られてくるが、ＳＮＭＰ処理部１０１はこの送信要求から送信要求元アドレスを取得する（Ｓ１）。次に、ＳＮＭＰ処理部１０１は、最初のエラー詳細要因格納データ領域（エラー詳細要因記憶部１１１）から最初のデータを読み込む（Ｓ２）。
【００３４】
次に、ＳＮＭＰ処理部１０１は、エラー詳細要因格納データ領域のネットワークアドレスと要求送信元ネットワークアドレスを比較する（Ｓ３）。そして、双方のアドレスが等しいかどうかチェックする（Ｓ４）。等しくない場合には、次のエラー詳細要因格納データ領域を読み込み（Ｓ５）、ステップＳ３のアドレス比較処理に戻る。
【００３５】
ステップＳ４において、双方のアドレスが等しい場合、ＳＮＭＰ処理部１０１は、現在のエラー詳細要因格納データ領域を格納先／読み出し先領域とする（Ｓ６）。
【００３６】
前述したように、マネージャ１１からエラー詳細要因の問い合わせがあった場合には、ＳＮＭＰ処理部１０１は、格納しておいたエラー詳細要因記憶部１１１から読み出して応答する。読み出すデータ領域の決定の第１の方法は、ネットワークアドレスより行なうものであり、第２の方法は、問い合わせ要求の送信元ネットワークアドレスにより行なうものである。
【００３７】
第１の方法における読み出すデータ領域の決定方法を図６に示す。図６はインデックスのネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。ＳＮＭＰ処理部１０１は、オブジェクトＩＤのインデックス部分からネットワークアドレスを取り出す（Ｓ１）。次に、最初のエラー詳細要因格納データ領域を読み取る（Ｓ２）。
【００３８】
次に、ＳＮＭＰ処理部１０１は、エラー詳細要因格納データ領域のネットワークアドレスとインデックスのネットワークアドレスを比較する（Ｓ３）。そして、双方のネットワークアドレスが等しいかどうかチェックする（Ｓ４）。等しくない場合には、次のエラー詳細要因格納データ領域を読み込み（Ｓ５）、ステップＳ３に戻りネットワークアドレスの比較処理を行なう。双方のネットワークアドレスが等しい場合には、現在のエラー詳細要因格納データ領域を格納先／読み出し先領域とする（Ｓ６）。
【００３９】
このようにすれば、インデックスのネットワークアドレスより読み出すデータ領域を決定することができる。
【００４０】
なお、第２の方法による読み出す領域の決定方法は、格納時と同じで図５に示した通りである。このようにすれば、問い合わせ要求の送信元ネットワークアドレスより読み出すデータ領域を決定することができる。
【００４１】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でもエージェントで発生したエラーの詳細要因を正しく読み出すことが可能になる。
【００４２】
また、本発明によれば、図７に示すように、ｇｅｎＥｒｒ発生時に、マネージャに対する応答と共に、エラー詳細要因をマネージャにＴｒａｐとして通知することができる。このようにすれば、マネージャがエージェントに対して問い合わせをすることなく詳細要因を知ることができる。
【００４３】
図７はエラー詳細要因通知の動作シーケンス図である。先ず、マネージャ＃２からＳｅｔ Ｒｅｑｕｅｓｔがエージェント１００に対して発行される（Ｓ１）。エージェント１００側では、ＳＮＭＰ処理部１０１でこの要求依頼を受けると、デバイス１０２に対して必要な処理を設定する（Ｓ２）。ここで、デバイス１０２で処理に失敗したものとする。このエラーは、デバイス１０２からＳＮＭＰ処理部１０１に通知される（Ｓ３）。
【００４４】
ＳＮＭＰ処理部１０１は、このエラー通知を受けると、マネージャ＃２に対する応答を返す前にエラー詳細要因記憶部＃２にエラーの詳細要因を格納する（Ｓ４）。そして、ＳＮＭＰ処理部１０１は、ＳＮＭＰマネージャ＃２に対してＴｒａｐ（詳細要因）を通知する（Ｓ６）。このようにすれば、マネージャがエージェントに対して問い合わせをすることなく詳細要因を知ることができる。
【００４５】
図８は本発明の一実施の形態例を示すブロック図である。図１と同一のものは、同一の符号を付して示す。この実施の形態例では、ＤＳＬＡＭ（ＡＤＳＬモデム多重化）装置がエージェント１００となっている。図において、１１はマネージャであり、＃１〜＃４まで設けられた例を示している。
【００４６】
エージェント１００には、４台のマネージャ１１が登録可能であり、登録した以外のマネージャからの要求は受け付けない。エージェント１００において、２００は装置全体の制御部と上位装置とのインタフェース部を持つＣＯＭパッケージ、３０１はＡＤＳＬ回線とのインタフェース部を持つＬＩＦパッケージでありそれぞれ活線挿抜が可能である。ＬＩＦパッケージ３０１は＃１〜＃ｎまでのｎ個設けられている。
【００４７】
エージェントとしての機能は、ＣＯＭパッケージ２００にて行なわれ、１０１がＳＮＭＰ処理部、１１１はエラー詳細要因記憶部である。該エラー詳細要因記憶部１１１は、マネージャ１１の数に対応して＃１〜＃４までの４個設けられている。２２１はＳＮＭＰ処理部１０１及びＬＩＦパッケージ３０１と接続されるパッケージ間通信部である。このように構成された装置の動作を説明すれば、以下の通りである。
【００４８】
ＳＮＭＰによるＬＩＦパッケージに関する情報の読み出しや制御の際、ＳＮＭＰ処理部１０１は、パッケージ間通信部２２１を通してＬＩＦパッケージ３０１と通信を行なうが、該当パッケージが挿入されていない場合や故障中である場合は通信を行なうことはできず、装置固有のエラーが発生する。このように、ＳＮＭＰ処理において装置固有のエラーが発生した場合は、マネージャ１１に対してエラーステータス（Ｅｒｒｏｒ Ｓｔａｔｕｓ）がｇｅｎＥｒｒであるＧｅｔ Ｒｅｓｐｏｎｓｅを返すと共に、マネージャ１１に対応するエラー詳細要因記憶部１１１にエラーの詳細要因を格納しておく。
【００４９】
エラーが発生しなかった時は、マネージャ１１に対応するエラー詳細要因記憶部１１１をクリアしておく。これにより、あるマネージャからの要求が原因で発生したｇｅｎＥｒｒの詳細要因は、それ以降に同一マネージャから何らかの要求があるまで保持され、他のマネージャからの影響を受けることはない。
【００５０】
なお、エラー詳細要因ＭＩＢのゲット（Ｇｅｔ）では、エラー詳細要因格納用データ領域はクリアしない。これにより、図９に示すように、Ｇｅｔ Ｒｅｓｐｏｎｓｅが途中で消失した場合でも、マネージャが再度ゲットすれば、エラー詳細要因を読み出すことができる。エラー詳細要因ＭＩＢは、インデックスなしとしている。これにより、マネージャはエラー詳細要因ＭＩＢにインデックスを付与する必要がなく、従来のエラー詳細要因ＭＩＢのゲット処理をそのまま利用することができる。
【００５１】
図９は詳細要因ＭＩＢのＧｅｔ Ｒｅｓｐｏｎｓｅが消滅した場合の動作シーケンスを示す図である。図７と同一のものは、同一の符号を付して示す。マネージャ１１＃１からエラーの詳細要因を知らせて欲しい旨のＧｅｔ Ｒｅｑｕｅｓｔが発行される（Ｓ１）。ＳＮＭＰ処理部１０１はこの要求を受けると、エラー詳細要因記憶部＃１からエラー詳細要因を読み出す（Ｓ２）。この時、エラー詳細要因を読み出しても、エラー詳細要因記憶部１１１＃１の内容をクリアしない。
【００５２】
ＳＮＭＰ処理部１０１がこのエラー詳細要因をマネージャ１１にＧｅｔ Ｒｅｓｐｏｎｓｅとして送信するが、消失したものとする（Ｓ３）。この時、マネージャ１１からＧｅｔ Ｒｅｓｐｏｎｓｅ（詳細要因）が再度発行される（Ｓ４）。ＳＮＭＰ処理部１０１はこの要求を受けると、エラー詳細要因記憶部＃１から詳細要因を読み出し（Ｓ５）、マネージャ＃１に対してＧｅｔ Ｒｅｓｐｏｎｓｅ（詳細要因）を送信する（Ｓ６）。これによれば、Ｇｅｔ Ｒｅｓｐｏｎｓｅが途中で消失した場合でも、マネージャが再度ゲットすれば、エラー詳細要因を読み出すことができる。
【００５３】
このように、本発明によれば、ＳＮＭＰエージェント装置が複数のＳＮＭＰマネージャに管理される構成において、複数のマネージャからの要求が競合した場合であっても、要求の処理の際に生じたエラーの詳細要因に関する情報をＳＮＭＰマネージャから正しく得ることができるという効果を奏する。
【００５４】
これにより、ＳＮＭＰマネージャはＳＮＭＰエージェント装置に対して要求をする前にＳＮＭＰエージェント装置の状態を詳しく知る必要がなく、またエラーが発生してもその詳細要因を得ることで、その後のアクションを決定することができ、ネットワークトラヒックの削減と操作性の向上に寄与するところが大きい。
【００５５】
【発明の効果】
以上説明したように、本発明によれば、以下の効果が得られる。
（１）請求項１記載の発明によれば、複数のマネージャからの要求が競合した場合でも、エラーの詳細要因は、マネージャ毎にエラー詳細要因記憶部１１１に記憶するので、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
（２）請求項２記載の発明によれば、インデックスネットワークより読み出すデータ領域を決定することができる。
（３）請求項３記載の発明によれば、問い合わせ要求の送信元のネットワークアドレスより読み出すデータ領域を決定することができる。
（４）請求項４記載の発明によれば、マネージャがエージェントに対して問い合わせをすることなく、その詳細要因を知ることができる。
【００５６】
このように、本発明によれば、複数のマネージャからの要求が競合した場合でも、エージェントで発生したエラーの詳細要因を正しく読み出すことができるＳＮＭＰエージェント装置を提供することができる。
【図面の簡単な説明】
【図１】本発明の原理ブロック図である。
【図２】本発明の動作シーケンス例を示す図である。
【図３】エラー詳細要因格納データ領域の構成例を示す図である。
【図４】ＳＮＭＰメッセージを含むＩＰデータグラムフォーマット例を示す図である。
【図５】要求の送信元ネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。
【図６】インデックスのネットワークアドレスから対応するデータ格納領域を決定するフローチャートを示す図である。
【図７】エラー詳細要因通知の動作シーケンス例を示す図である。
【図８】本発明の一実施の形態例を示すブロック図である。
【図９】詳細要因ＭＩＢのＧｅｔ Ｒｅｓｐｏｎｓｅが消滅した場合の動作シーケンス例を示す図である。
【図１０】ＭＩＢツリーを示す図である。
【図１１】従来の動作シーケンス例を示す図である。
【符号の説明】
１１ ＳＮＭＰマネージャ
２０ ネットワーク
１００ ＳＮＭＰエージェント装置
１０１ ＳＮＭＰ処理部
１１１ エラー詳細要因記憶部
Claims (4)
- ＳＮＭＰマネージャからの要求に基づいて処理を行なう際に、
前記要求に基づく処理によって発生したエラーの詳細要因を、前記ＳＮＭＰマネージャに対して応答する前に、対応するＳＮＭＰマネージャ毎に格納する記憶手段と、
前記ＳＮＭＰマネージャに対応するエラーの詳細要因を前記記憶手段から読み出して、
読み出した前記エラーの詳細要因を対応する前記ＳＮＭＰマネージャに送信する処理手段と、
を具備していることを特徴とするＳＮＭＰエージェント装置。 - 前記処理手段がＳＮＭＰマネージャの識別情報をインデックスとして読み出すことを特徴とする請求項１記載のＳＮＭＰエージェント装置。
- 前記処理手段が、ＳＮＭＰマネージャの識別情報をインデックスなしで読み出すことを特徴とする請求項１記載のＳＮＭＰエージェント装置。
- ｇｅｎＥｒｒが発生した場合に、ＳＮＭＰマネージャに対する応答と共に前記エラーの詳細要因をＳＮＭＰマネージャに別途通知する手段を更に具備していることを特徴とする請求項１記載のＳＮＭＰエージェント装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091445A JP4763227B2 (ja) | 2003-03-28 | 2003-03-28 | Ｓｎｍｐエージェント装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003091445A JP4763227B2 (ja) | 2003-03-28 | 2003-03-28 | Ｓｎｍｐエージェント装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004302532A JP2004302532A (ja) | 2004-10-28 |
| JP4763227B2 true JP4763227B2 (ja) | 2011-08-31 |
Family
ID=33404809
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003091445A Expired - Fee Related JP4763227B2 (ja) | 2003-03-28 | 2003-03-28 | Ｓｎｍｐエージェント装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4763227B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6045410B2 (ja) * | 2013-03-14 | 2016-12-14 | 三菱電機株式会社 | ネットワーク装置及び状態変化通知方法 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH02184140A (ja) * | 1989-01-11 | 1990-07-18 | Fujitsu Ltd | Ｌａｎ制御装置 |
| JPH0512142A (ja) * | 1991-07-03 | 1993-01-22 | Fujitsu Ltd | 電子計算機本体におけるエラー情報読み出し方式 |
| JPH0736794A (ja) * | 1993-07-19 | 1995-02-07 | Ricoh Co Ltd | Ｓｃｓｉインタフェイスシステム |
| JPH08328983A (ja) * | 1995-05-30 | 1996-12-13 | Fuji Xerox Co Ltd | ネットワーク管理情報検索方式 |
| JPH09259051A (ja) * | 1996-03-22 | 1997-10-03 | Fujitsu Ltd | アラーム通知処理方式 |
| JPH11122444A (ja) * | 1997-10-16 | 1999-04-30 | Canon Inc | 画像読取システム及び画像読取システムにおける画像情報格納方法 |
| JP3570300B2 (ja) * | 1999-07-02 | 2004-09-29 | 日本電気株式会社 | 障害管理方式および方法 |
| JP2001075935A (ja) * | 1999-09-07 | 2001-03-23 | Nec Ibaraki Ltd | プロセッサ間通信方法 |
| JP2002082792A (ja) * | 2000-06-22 | 2002-03-22 | Konica Corp | 管理システム、中継サーバー、管理装置、管理方法及び画像形成装置 |
-
2003
- 2003-03-28 JP JP2003091445A patent/JP4763227B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004302532A (ja) | 2004-10-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| McCloghrie et al. | The interfaces group MIB | |
| US7257817B2 (en) | Virtual network with adaptive dispatcher | |
| US7484222B1 (en) | Method and system for setting expressions in network management notifications | |
| US7899047B2 (en) | Virtual network with adaptive dispatcher | |
| US6684241B1 (en) | Apparatus and method of configuring a network device | |
| TWI324456B (en) | An intelligent automatic setting restoration method and device | |
| EP0715435B1 (en) | Batch transfer system and method for high performance graphic display of network topology | |
| US7386628B1 (en) | Methods and systems for processing network data packets | |
| KR100716167B1 (ko) | 네트워크 관리 시스템 및 방법 | |
| US9083615B2 (en) | Diagnosing network problems in an IPV6 dual stack network | |
| JPH08508376A (ja) | Ｌａｎ領域用汎用管理オブジェクト・モデル | |
| US7120833B2 (en) | Error codes in Agent X | |
| US6694304B1 (en) | System and method for retrieving network management table entries | |
| JP2002344517A (ja) | 二重ｉｐネットワークにおいてイベントソースを識別するための方法 | |
| JP4763227B2 (ja) | Ｓｎｍｐエージェント装置 | |
| US20030055947A1 (en) | Address conversion apparatus, monitoring apparatus, and computer-readable medium storing a program thereof | |
| US7275094B1 (en) | System and method for configuring contents of network management notifications | |
| Cisco | IBM Channel Attach Commands | |
| Cisco | IBM Channel Attach Commands | |
| Cisco | IBM Channel Attach Commands | |
| Cisco | System Error Messages for 11.2 P | |
| Cisco | System Error Messages for 11.2 P | |
| JP2004500778A (ja) | 多数のフォールト・トレラント・ネットワークにおける非フォールト・トレラント・ネットワーク・ノード | |
| US7440420B2 (en) | Automatic resynchronization of physically relocated links in a multi-link frame relay system | |
| McCloghrie et al. | RFC2863: The Interfaces Group MIB |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060323 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080815 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080821 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20081014 Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081014 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20081125 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20090122 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110506 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110506 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110609 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140617 Year of fee payment: 3 |
|
| 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: R313115 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| LAPS | Cancellation because of no payment of annual fees |