RFC2089 日本語訳
2089 V2ToV1 Mapping SNMPv2 onto SNMPv1 within a bi-lingual SNMP agent.B. Wijnen, D. Levi. January 1997. (Format: TXT=23814 bytes) (Obsoleted by RFC2576) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Wijnen
Request for Comments: 2089 IBM
Category: Informational D. Levi
SNMP Research, Inc
January 1997
Wijnenがコメントのために要求するワーキンググループB.をネットワークでつないでください: 2089年のIBMカテゴリ: 情報のD.レビのSNMP研究、Inc1997年1月
V2ToV1
Mapping SNMPv2 onto SNMPv1
within a bi-lingual SNMP agent
バイリンガルSNMPエージェントの中のSNMPv1へのV2ToV1 Mapping SNMPv2
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
The goal of this memo is to document a common way of mapping an SNMPv2 response into an SNMPv1 response within a bi-lingual SNMP agent (one that supports both SNMPv1 and SNMPv2).
このメモの目標はバイリンガルSNMPエージェント(SNMPv1とSNMPv2の両方を支持するもの)の中でSNMPv2応答をSNMPv1応答に写像する一般的な方法を記録することです。
Table of Contents
目次
1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2.0 Mapping SNMPv2 into SNMPv1 . . . . . . . . . . . . . . . . 2
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status . . . 3
2.2 Mapping SNMPv2 exceptions into SNMPv1 . . . . . . . . . . 3
2.3 Mapping noSuchObject and noSuchInstance . . . . . . . . . 4
2.4 Mapping endOfMibView . . . . . . . . . . . . . . . . . . . 5
2.5 Mapping SNMPv2 SMI into SNMPv1 . . . . . . . . . . . . . . 5
3.0 Processing SNMPv1 requests . . . . . . . . . . . . . . . . 6
3.1 Processing an SNMPv1 GET request . . . . . . . . . . . . . 6
3.2 Processing an SNMPv1 GETNEXT request . . . . . . . . . . . 7
3.3 Processing an outgoing SNMPv2 trap . . . . . . . . . . . . 8
4.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 10
5.0 References . . . . . . . . . . . . . . . . . . . . . . . . 10
6.0 Security Considerations . . . . . . . . . . . . . . . . . 10
7.0 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Background Information . . . . . . . . . . . . . 12
A.1 Mapping of error-status Values . . . . . . . . . . . . . 12
A.2 SNMPv1 traps without Counter64 varBinds. . . . . . . . . 12
1.0 SNMPv1. . . . . . . . . . 3 2.3Mapping noSuchObjectへのSNMPv1エラー状況. . . 3 2.2Mapping SNMPv2例外とSNMPv1. . . . . . . . . . . . . . 5 3.0Processing SNMPv1へのnoSuchInstance. . . . . . . . . 4 2.4Mapping endOfMibView.52.5Mapping SNMPv2 SMIへのSNMPv1. . . . . . . . . . . . . . . . 2 2.1Mapping SNMPv2エラー状況への序論.22.0Mapping SNMPv2は…を要求します…; SNMPv1 GET要求. . . . . . . . . . . . . 6 3.2Processingを処理して、.63.1に、SNMPv1 GETNEXTが出発しているSNMPv2の罠の.84.0Acknowledgements. . . . . . . . . . . . . . . . . . . . . 10 5.0のReferences. . . . . . . . . . . . . . . . . . . . . . . . 10 6.0Security Considerations. . . . . . . . . . . . . . . . . 10 7.0AuthorsのAddresses.11に.73.3Processingを要求する、Appendix A.Background情報…… . . . . . . . エラー状況Values. . . . . . . . . . . . . 12A.2 SNMPv1に関する12A.1マッピングはCounter64 varBindsなしで捕らえられます。 . . . . . . . . 12
Wijnen & Levi Informational [Page 1] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[1ページ]のRFC2089V2toV1 January 1997
1.0 Introduction
1.0 序論
We now have the SNMPv1 protocol (RFC1157 [1]) as a full standard and the SNMPv2 protocol (RFC1905 [1]) as a DRAFT standard. It can be expected that many agent implementations will support both SNMPv1 and SNMPv2 requests coming from SNMP management entities. In many cases the underlying instrumentation will be implemented using the new SNMPv2 SMI and SNMPv2 protocol. The SNMP engine then gets the task to ensure that any SNMPv2 response data coming from such SNMPv2 compliant instrumentation gets converted to a proper SNMPv1 response if the original request came in as an SNMPv1 request. The SNMP engine should also deal with mapping SNMPv2 traps which are generated by an application or by the SNMPv2 compliant instrumentation into SNMPv1 traps if the agent has been configured to send traps to an SNMPv1 manager.
完全な規格としてのRFC1157[1])とSNMPv2は議定書を作ります。現在、私たちにはSNMPv1プロトコルがある、((DRAFT規格としてのRFC1905[1])。 多くのエージェント実現がSNMP経営体から来るSNMPv1とSNMPv2要求の両方を支持すると予想できます。 多くの場合、基本的な計装は、新しいSNMPv2 SMIとSNMPv2プロトコルを使用することで実行されるでしょう。 そして、SNMPエンジンで、タスクは、オリジナルの要求がSNMPv1要求として入ったならそのようなSNMPv2対応することの計装から来るのが得るどんなSNMPv2応答データも適切なSNMPv1応答に変えたのを保証します。 また、エージェントがSNMPv1マネージャに罠を送るために構成されたなら、SNMPエンジンはアプリケーションで発生するSNMPv2罠を写像するか、SNMPv2で対応する計装をSNMPv1罠まで取扱うはずです。
It seems beneficial if all such agents do this mapping in the same way. This document describes such a mapping based on discussions and perceived consensus on the various mailing lists. The authors of this document have also compared their own implementations of these mappings. They had a few minor differences and decided to make their implementation behave the same and document this mapping so others can benefit from it.
そのようなすべてのエージェントが同様にこのマッピングをするなら、それは有益に見えます。 このドキュメントは議論に基づいていて、様々なメーリングリストに関するコンセンサスであると知覚されたそのようなマッピングについて説明します。 また、このドキュメントの作者はそれら自身のこれらのマッピングの実現を比較しました。 彼らは、いくつかの小異を持って、彼らの実現を同じように振る舞わせて、他のものがそれの利益を得ることができるようにこのマッピングを記録すると決めました。
We recommend that all agents implement this same mapping.
私たちは、すべてのエージェントがこの同じマッピングを実行することを勧めます。
Note that the mapping described in this document should also be followed by SNMP proxies that provide a mapping between SNMPv1 management applications and SNMPv2 agents.
また、本書では説明されたマッピングがSNMPv1管理アプリケーションとSNMPv2エージェントの間にマッピングを提供するSNMPプロキシが従われるべきであることに注意してください。
2.0 Mapping SNMPv2 into SNMPv1
2.0 SNMPv2をSNMPv1に写像すること。
These are the type of mappings that we need:
これらは私たちが必要とするマッピングのタイプです:
o Mapping of the SNMPv2 error-status into SNMPv1 error-status
o SNMPv1エラー状況へのSNMPv2エラー状況に関するマッピング
o Mapping of the SNMPv2 exceptions into SNMPv1 error-status
o SNMPv1エラー状況へのSNMPv2例外に関するマッピング
o Skipping object instances that have a non-SNMPv1 Syntax
(specifically Counter64)
o 非SNMPv1 Syntaxを持っている物の例をスキップします。(明確にCounter64)
o Mapping of SNMPv2 traps into SNMPv1 traps
o SNMPv1罠へのSNMPv2罠に関するマッピング
Wijnen & Levi Informational [Page 2] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[2ページ]のRFC2089V2toV1 January 1997
2.1 Mapping SNMPv2 error-status into SNMPv1 error-status
2.1 SNMPv2エラー状況をSNMPv1エラー状況に写像すること。
With the new SNMPv2 protocol (RFC1905 [1]) we get a set of error- status values that return the cause of an error in much more detail. But an SNMPv1 manager does not understand such error-status values.
新しさで、SNMPv2は議定書を作ります。(私たちがずっと多くの詳細に誤りの原因を返す1セットの誤り状態値を得るRFC1905[1])。 しかし、SNMPv1マネージャはそのようなエラー状況値を理解していません。
So, when the instrumentation code returns response data and uses an SNMPv2 error-status to report on the success or failure of the requested operation and if the original SNMP request is an SNMPv1 request, then we must map such an error-status into an SNMPv1 error- status when composing the SNMP response PDU.
それで、そして、計装コードが応答データを返して、要求された操作の成否とオリジナルのSNMP要求がSNMPv1要求であるかどうかに関して報告するのにSNMPv2エラー状況を使用すると、SNMP応答PDUを構成するとき、私たちはSNMPv1誤りへのそのようなエラー状況状態を写像しなければなりません。
The SNMPv2 error status is mapped to an SNMPv1 error-status using this table:
SNMPv2エラー状況はこのテーブルを使用することでSNMPv1エラー状況に写像されます:
SNMPv2 error-status SNMPv1 error-status
=================== ===================
noError noError
tooBig tooBig
noSuchName noSuchName
badValue badValue
readOnly readOnly
genErr genErr
wrongValue badValue
wrongEncoding badValue
wrongType badValue
wrongLength badValue
inconsistentValue badValue
noAccess noSuchName
notWritable noSuchName
noCreation noSuchName
inconsistentName noSuchName
resourceUnavailable genErr
commitFailed genErr
undoFailed genErr
authorizationError noSuchName
SNMPv2エラー状況SNMPv1エラー状況=================== =================== noError noError tooBig tooBig noSuchName noSuchName badValue badValue readOnly readOnly genErr genErr wrongValue badValue wrongEncoding badValue wrongType badValue wrongLength badValue inconsistentValue badValue noAccess noSuchName notWritable noSuchName noCreation noSuchName inconsistentName noSuchName resourceUnavailable genErr commitFailed genErr undoFailed genErr authorizationError noSuchName
2.2 Mapping SNMPv2 exceptions into SNMPv1
2.2 SNMPv2例外をSNMPv1に写像すること。
In SNMPv2 we have so called exception values. These will allow an SNMPv2 response PDU to return as much management information as possible, even if one or more of the requested variables do not exist. SNMPv1 does not support exception values, and thus does not return the value of management information when any error occurs.
したがって、SNMPv2では、私たちは、例外を値と呼びました。 これらで、SNMPv2応答PDUはできるだけ多くの経営情報を返すことができるでしょう、要求された変数が1かもうも存在していないなら。 SNMPv1は例外値を支持しないで、またその結果、何か誤りがいつ発生するかという経営情報の値を返しません。
When multiple variables do not exist, an SNMPv1 agent can return only a single error and index of a single variable. The agent determines by its implementation strategy which variable to identify as the
複数の変数が存在していないと、SNMPv1エージェントはただ一つの変数のただ一つの誤りとインデックスしか返すことができません。 エージェントは、どの変数を特定するかを実現戦略で決心しています。
Wijnen & Levi Informational [Page 3] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[3ページ]のRFC2089V2toV1 January 1997
cause of the error via the value of the error-index field. Thus, an SNMPv1 manager may make no assumption on the validity of the other variables in the request.
誤りインデックス部の値を通した誤りの原因。 したがって、SNMPv1マネージャは要求でもう片方の正当性における仮定を全く変数にしないかもしれません。
So, when an SNMPv1 request is received, we must check the varBinds returned from SNMPv2 compliant instrumentation for exception values, and convert these exception values into SNMPv1 error codes.
それで、SNMPv1要求が受信されているとき、私たちは、例外値のためのSNMPv2対応することの計装から返されたvarBindsをチェックして、これらの例外値をSNMPv1エラーコードに変換しなければなりません。
The type of exception we can get back and the action we must take depends on the SNMP operation that is requested.
私たちが取り戻すことができる例外と私たちが取らなければならない行動のタイプは要求されているSNMP操作を当てにします。
o For SNMP GET requests we can get back noSuchObject and
noSuchInstance.
o SNMP GET要求のために、私たちはnoSuchObjectとnoSuchInstanceを取り戻すことができます。
o For SNMP GETNEXT requests we can get back endOfMibView.
o SNMP GETNEXT要求のために、私たちはendOfMibViewを取り戻すことができます。
o For SNMP SET requests we cannot get back any exceptions.
o SNMP SET要求のために、私たちは少しの例外も取り戻すことができません。
o For SNMP GETBULK requests we can get back endOfMibView, but
such a request should only come in as an SNMPv2 request, so we
do not have to worry about any mapping onto SNMPv1. If a
GETBULK comes in as an SNMPv1 request, it is treated as an
error and the packet is dropped.
o SNMP GETBULK要求のために、私たちがendOfMibViewを取り戻すことができますが、そのような要求がSNMPv2要求として入るだけであるべきであるので、私たちはSNMPv1へのどんなマッピングも心配する必要はありません。 GETBULKがSNMPv1要求として入るなら、それは誤りとして扱われます、そして、パケットは落とされます。
2.3 Mapping noSuchObject and noSuchInstance
2.3 noSuchObjectとnoSuchInstanceを写像すること。
A noSuchObject or noSuchInstance exception generated by SNMPv2 compliant instrumentation indicates that the requested object instance can not be returned. The SNMPv1 error code for this condition is noSuchName, and so the error-status field of the response PDU should be set to noSuchName. Also, the error-index field is set to the index of the varBind for which an exception occurred, and the varBind list from the original request is returned with the response PDU.
SNMPv2対応することの計装で発生するnoSuchObjectかnoSuchInstance例外が、要求された物の例を返すことができないのを示します。 この状態のためのSNMPv1エラーコードがnoSuchNameであるので、応答PDUのエラー状況分野はnoSuchNameに設定されるべきです。 また、例外が起こったvarBindのインデックスに誤りインデックス部を設定します、そして、応答PDUと共にオリジナルの要求からのvarBindリストを返します。
Note that when the response contains multiple exceptions, that the agent may pick any one to be returned.
エージェントが返されるいくらか1つを選ぶかもしれないという応答であるときに複数の例外を含むメモ。
Wijnen & Levi Informational [Page 4] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[4ページ]のRFC2089V2toV1 January 1997
2.4 Mapping endOfMibView
2.4 endOfMibViewを写像すること。
When SNMPv2 compliant instrumentation returns a varBind containing an endOfMibView exception in response to a GETNEXT request, it indicates that there are no object instances available which lexicographically follow the object in the request. In an SNMPv1 agent, this condition normally results in a noSuchName error, and so the error-status field of the response PDU should be set to noSuchName. Also, the error- index field is set to the index of the varBind for which an exception occurred, and the varBind list from the original request is returned with the response PDU.
SNMPv2対応することの計装がGETNEXT要求に対応してendOfMibView例外を含むvarBindを返すとき、それは、要求で辞書編集に物に従う利用可能などんな物の例もないのを示します。 SNMPv1エージェントでは、この状態が通常noSuchName誤りをもたらすので、応答PDUのエラー状況分野はnoSuchNameに設定されるべきです。 また、例外が起こったvarBindのインデックスに誤りインデックス部を設定します、そして、応答PDUと共にオリジナルの要求からのvarBindリストを返します。
Note that when the response contains multiple exceptions, that the agent may pick any one to be returned.
エージェントが返されるいくらか1つを選ぶかもしれないという応答であるときに複数の例外を含むメモ。
2.5 Mapping SNMPv2 SMI into SNMPv1
2.5 SNMPv2 SMIをSNMPv1に写像すること。
The SNMPv2 SMI (RFC1902 [2]) defines basically one new syntax that is problematic for SNMPv1 managers. That is the syntax Counter64. All the others can be handled by SNMPv1 managers.
SNMPv2 SMI、(RFC1902[2])は基本的に、あるSNMPv1マネージャにとって、問題が多い新しい構文を定義します。 それは構文Counter64です。 SNMPv1マネージャはすべての他のものを扱うことができます。
The net impact on bi-lingual agents is that they should make sure that they never return a varBind with a Counter64 value to an SNMPv1 manager.
バイリンガルエージェントへのネットの影響は彼らが、Counter64値があるvarBindをSNMPv1マネージャに決して返さないのを確実にするべきであるということです。
The best accepted practice is to consider such object instances implicitly excluded from the view. So:
最も良い慣例は、そのような物の例が視点からそれとなく除かれると考えることになっています。 そのように:
o On an SNMPv1 GET request, we return an error-status of
noSuchName and the error-index is set to the varBind that
causes this error.
o SNMPv1 GET要求のときに、私たちはnoSuchNameのエラー状況を返します、そして、誤りインデックスはこの誤りを引き起こすvarBindに設定されます。
o On an SNMPv1 GETNEXT request, we skip the object instance and
fetch the next object instance that follows the one with a
syntax of Counter64.
o SNMPv1 GETNEXT要求のときに、私たちは、物の例をスキップして、Counter64の構文でものに続く次の物の例をとって来ます。
o Any SET request that has a varBind with a Counter64 value must
have come from a SNMPv2 manager, and so it should not cause a
problem. If we do receive a Counter64 value in an SNMPv1 SET
packet, it should result in an ASN.1 parse error since
Counter64 is not valid in the SNMPv1 protocol. When an ASN.1
parse error occurs, the counter snmpInASNParseErrs is
incremented and no response is returned.
o Counter64値があるvarBindを持っているどんなSET要求もSNMPv2マネージャから来たに違いないので、それは問題を引き起こすべきではありません。 私たちであるならSNMPv1 SETパケットでCounter64値を受けてください、そして、それは分析するべきです。Counter64がSNMPv1プロトコルで有効でないので、ASN.1の結果は誤りを分析します。 ASN.1が分析するとき、誤りは発生します、そして、カウンタsnmpInASNParseErrsは増加しています、そして、応答を全く返しません。
o The GETBULK is an SNMPv2 operation, so it should never come
from an SNMPv1 manager. If we do receive a GETBULK PDU from in
an SNMPv1 packet, then we consider it an invalid PDU-type and
we drop the packet.
o GETBULKがSNMPv2操作であるので、それはSNMPv1マネージャから決して来るべきではありません。 私たちであるならコネからGETBULK PDUを受け取ってください。SNMPv1パケット、次に、それが無効のPDU-タイプであると考えます、そして、私たちはパケットを落とします。
Wijnen & Levi Informational [Page 5] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[5ページ]のRFC2089V2toV1 January 1997
3.0 Processing SNMPv1 requests
3.0 処理SNMPv1要求
This sections contains a step by step description of how to handle SNMPv1 requests in an agent where the underlying instrumentation code is SNMPv2 compliant.
このセクションはどう、エージェントでの基本的な計装コードがSNMPv2対応であるSNMPv1要求を扱うかに関する段階的な記述を含みます。
3.1 Processing an SNMPv1 GET request
3.1 SNMPv1 GET要求を処理すること。
First, the request is converted into a call to the underlying instrumentation. This is implementation specific.
まず最初に、要求は基本的な計装への呼び出しに変換されます。 これは実現特有です。
When such instrumentation returns response data using SNMPv2 syntax and error-status values, then:
そして、そのような計装がいつ、SNMPv2構文を使用することで応答データを返すか、そして、エラー状況は以下を評価します。
1. If the error-status is anything other than noError,
1. エラー状況であるなら、noErrorを除いて、何でもあります。
a. The error status is translated to an SNMPv1 error-status
using the table from 2.1, "Mapping SNMPv2 error-status into
SNMPv1 error-status" on page 2
a。 エラー状況は2.1からテーブルを使用することでSNMPv1エラー状況に翻訳されます、2ページで「SNMPv2エラー状況をSNMPv1エラー状況に写像し」て
b. The error-index is set to the position (in the original
request) of the varBind that caused the error-status.
b。 誤りインデックスはエラー状況を引き起こしたvarBindの位置(オリジナルの要求における)に設定されます。
c. The varBindList of the response PDU is made exactly the
same as the varBindList that was received in the original
request.
c。 応答PDUのvarBindListはまさにオリジナルの要求に受け取られたvarBindListとして同じように作られています。
2. If the error-status is noError, then find any varBind that
contains an SNMPv2 exception (noSuchObject or noSuchInstance)
or an SNMPv2 syntax that is unknown to SNMPv1 (Counter64).
(Note that if there are more than one, the agent may choose any
such varBind.) If there are any such varBinds, then for the
one chosen:
2. エラー状況がnoErrorであるなら、SNMPv2例外(noSuchObjectかnoSuchInstance)かSNMPv1において、未知であることのSNMPv2構文(Counter64)を含むあらゆるvarBindを見つけてください。 (1以上があれば、エージェントがどんなそのようなvarBindも選ぶかもしれないことに注意してください。) 何かそして、選ばれたもののためのそのようなvarBindsがあれば:
a. Set the error-status to noSuchName
a。 noSuchNameにエラー状況を設定してください。
b. Set the error-index to the position (in the varBindList of
the original request) of the varBind that returned such an
SNMPv2 exception or syntax.
b。 そのようなSNMPv2例外か構文を返したvarBindの位置(オリジナルの要求のvarBindListの)に誤りインデックスを設定してください。
c. Make the varBindList of the response PDU exactly the same
as the varBindList that was received in the original
request.
c。 まさにオリジナルの要求に受け取られたvarBindListとして同じように応答のvarBindListをPDUにしてください。
Wijnen & Levi Informational [Page 6] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[6ページ]のRFC2089V2toV1 January 1997
3. If there are no such varBinds, then:
3. 次に、どれかそのようなvarBindsがなければ:
a. Set the error-status to noError
a。 noErrorにエラー状況を設定してください。
b. Set the error-index to zero
b。 誤りインデックスをゼロに設定してください。
c. Compose the varBindList of the response, using the data as
it is returned by the instrumentation code.
c。 計装コードでそれを返すのでデータを使用して、応答のvarBindListを構成してください。
3.2 Processing an SNMPv1 GETNEXT request
3.2 SNMPv1 GETNEXT要求を処理すること。
First, the request is converted into a call to the underlying instrumentation. This is implementation specific. There may be repetitive calls to (possibly different pieces of) instrumentation code to try to find the first object which lexicographically follows each of the objects in the request. Again, this is implementation specific.
まず最初に、要求は基本的な計装への呼び出しに変換されます。 これは実現特有です。 反復性の呼び出しがあるかもしれない、(ことによると異なった断片、)、最初の物がどの辞書編集であるかがわかろうとする計装コードは要求でそれぞれの物に従います。 一方、これは実現特有です。
When the instrumentation finally returns response data using SNMPv2 syntax and error-status values, then:
そして、計装がいつ、SNMPv2構文を使用することで最終的に応答データを返すか、そして、エラー状況は以下を評価します。
1. If the error-status is anything other than noError,
1. エラー状況であるなら、noErrorを除いて、何でもあります。
a. The error status is translated to an SNMPv1 error-status
using the table from 2.1, "Mapping SNMPv2 error-status into
SNMPv1 error-status" on page 2
a。 エラー状況は2.1からテーブルを使用することでSNMPv1エラー状況に翻訳されます、2ページで「SNMPv2エラー状況をSNMPv1エラー状況に写像し」て
b. The error-index is set to the position (in the original
request) of the varBind that caused the error-status.
b。 誤りインデックスはエラー状況を引き起こしたvarBindの位置(オリジナルの要求における)に設定されます。
c. The varBindList of the response PDU is made exactly the
same as the varBindList that was received in the original
request.
c。 応答PDUのvarBindListはまさにオリジナルの要求に受け取られたvarBindListとして同じように作られています。
2. If the error-status is noError, then:
2. 次に、エラー状況がnoErrorであるなら:
a. If there are any varBinds containing an SNMPv2 syntax of
Counter64, then consider these varBinds to be not in view
and repeat the call to the instrumentation code as often as
needed till a value other than Counter64 is returned.
a。 何かCounter64のSNMPv2構文を含むvarBindsがあれば、視点にはこれらのvarBindsがないと考えてください、そして、必要に応じてCounter64以外の値を返すまで計装コードに呼び出しを同じくらいしばしば繰り返してください。
b. Find any varBind that contains an SNMPv2 exception
endOfMibView. (Note that if there are more than one, the
agent may choose any such varBind.) If there are any such
varBinds, then for the one chosen:
b。 SNMPv2例外endOfMibViewを含むあらゆるvarBindを見つけてください。 (1以上があれば、エージェントがどんなそのようなvarBindも選ぶかもしれないことに注意してください。) 何かそして、選ばれたもののためのそのようなvarBindsがあれば:
1) Set the error-status to noSuchName
1) noSuchNameにエラー状況を設定してください。
Wijnen & Levi Informational [Page 7] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[7ページ]のRFC2089V2toV1 January 1997
2) Set the error-index to the position (in the varBindList
of the original request) of the varBind that returned
such an SNMPv2 exception.
2) そのようなSNMPv2例外を返したvarBindの位置(オリジナルの要求のvarBindListの)に誤りインデックスを設定してください。
3) Make the varBindList of the response PDU exactly the
same as the varBindList that was received in the
original request.
3) まさにオリジナルの要求に受け取られたvarBindListとして同じように応答のvarBindListをPDUにしてください。
c. If there are no such varBinds, then:
c。 次に、どれかそのようなvarBindsがなければ:
1) Set the error-status to noError
1) noErrorにエラー状況を設定してください。
2) Set the error-index to zero
2) 誤りインデックスをゼロに設定してください。
3) Compose the varBindList of the response, using the data
as it is returned by the instrumentation code.
3) 計装コードでそれを返すのでデータを使用して、応答のvarBindListを構成してください。
3.3 Processing an outgoing SNMPv2 TRAP
3.3 出発しているSNMPv2 TRAPを処理すること。
If SNMPv2 compliant instrumentation presents an SNMPv2 trap to the SNMP engine and such a trap passes all regular checking and then is to be sent to an SNMPv1 destination, then the following steps must be followed to convert such a trap to an SNMPv1 trap. This is basically the reverse of the SNMPv1 to SNMPv2 mapping as described in RFC1908 [3].
SNMPv2対応することの計装がSNMPエンジンにSNMPv2罠を提示して、そのような罠がすべての定期的な照合を向かわせて、次に、SNMPv1の目的地に送ることであるなら、そのような罠をSNMPv1罠に変換するために以下の方法に従わなければなりません。 これはRFC1908[3]で説明されるように基本的にSNMPv2マッピングへのSNMPv1の逆です。
1. If any of the varBinds in the varBindList has an SNMPv2 syntax
of Counter64, then such varBinds are implicitly considered to
be not in view, and so they are removed from the varBindList to
be sent with the SNMPv1 trap.
1. varBindListのvarBindsのどれかにCounter64のSNMPv2構文があるなら視点にはそのようなvarBindsがいないとそれとなく考えられるので、SNMPv1罠と共に送るためにvarBindListから彼らを取り除きます。
2. The 3 special varBinds in the varBindList of an SNMPv2 trap
(sysUpTime.0 (TimeTicks), snmpTrapOID.0 (OBJECT IDENTIFIER) and
optionally snmpTrapEnterprise.0 (OBJECT IDENTIFIER)) are
removed from the varBindList to be sent with the SNMPv1 trap.
These 2 (or 3) varBinds are used to decide how to set other
fields in the SNMPv1 trap PDU as follows:
2. そして、SNMPv2のvarBindListの3特別なvarBindsが捕らえる、(sysUpTime.0(TimeTicks)、snmpTrapOID.0(OBJECT IDENTIFIER)、任意に、snmpTrapEnterprise.0(OBJECT IDENTIFIER)は、SNMPv1罠と共に送るためにvarBindListから取り外されます。 これらの2(または、3)varBindsが以下のSNMPv1罠PDUに他の分野をはめ込む方法を決めるのに使用されます:
a. The value of sysUpTime.0 is copied into the timestamp field
of the SNMPv1 trap.
a。 sysUpTime.0の値はSNMPv1罠のタイムスタンプ分野にコピーされます。
Wijnen & Levi Informational [Page 8] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[8ページ]のRFC2089V2toV1 January 1997
b. If the snmpTrapOID.0 value is one of the standard traps the
specific-trap field is set to zero and the generic trap
field is set according to this mapping:
b。 snmpTrapOID.0値が標準の罠の1つであるなら、特定の罠分野はゼロに設定されます、そして、このマッピングによると、一般的な罠分野は設定されます:
value of snmpTrapOID.0 generic-trap
=============================== ============
1.3.6.1.6.3.1.1.5.1 (coldStart) 0
1.3.6.1.6.3.1.1.5.2 (warmStart) 1
1.3.6.1.6.3.1.1.5.3 (linkDown) 2
1.3.6.1.6.3.1.1.5.4 (linkUp) 3
1.3.6.1.6.3.1.1.5.5 (authenticationFailure) 4
1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss) 5
snmpTrapOID.0の一般的な罠の値=============================== ============ 1.3.6.1.6.3.1.1.5.1 (コールドスタート)0 1.3.6.1.6.3.1.1.5.2(warmStart)1 1.3.6.1.6.3.1.1.5.3(linkDown)2 1.3.6.1.6.3.1.1.5.4(結合)3 1.3.6.1.6.3.1.1.5.5(authenticationFailure)4 1.3.6.1.6.3.1.1.5.6(egpNeighborLoss)5
The enterprise field is set to the value of
snmpTrapEnterprise.0 if this varBind is present, otherwise
it is set to the value snmpTraps as defined in RFC1907 [4].
このvarBindが存在しているなら、企業分野はsnmpTrapEnterprise.0の値に設定されます。さもなければ、それはRFC1907[4]で定義されるように値のsnmpTrapsに設定されます。
c. If the snmpTrapOID.0 value is not one of the standard
traps, then the generic-trap field is set to 6 and the
specific-trap field is set to the last subid of the
snmpTrapOID.0 value.
c。 snmpTrapOID.0値が標準の罠の1つでないなら、一般的な罠分野は6に設定されます、そして、特定の罠分野はsnmpTrapOID.0価値の最後のsubidに設定されます。
o If the next to last subid of snmpTrapOID.0 is zero,
then the enterprise field is set to snmpTrapOID.0 value
and the last 2 subids are truncated from that value.
o If the next to last subid of snmpTrapOID.0 is not zero,
then the enterprise field is set to snmpTrapOID.0 value
and the last 1 subid is truncated from that value.
o 持続するsnmpTrapOID.0のsubidの次のことはゼロです、そして、次に、企業分野はsnmpTrapOID.0値に設定されます、そして、最後の2subidsはその値の先端を切られます。○ snmpTrapOID.0のsubidを持続する次のIfがゼロでなく、次に、企業分野がsnmpTrapOID.0値に設定されて、最後の1subidはその値を先端を切られるなら。
In any event, the snmpTrapEnterprise.0 varBind (if present)
is ignored in this case.
とにかく、snmpTrapEnterprise.0varBind(存在しているなら)はこの場合無視されます。
3. The agent-addr field is set with the appropriate address of the
the sending SNMP entity, which is the IP address of the sending
entity of the trap goes out over UDP; otherwise the agent-addr
field is set to address 0.0.0.0.
3. エージェント-addr分野は罠の送付実体のアドレスがUDPの上に行かせるIPである送付SNMP実体の適切なアドレスで設定されます。 さもなければ、エージェント-addr分野は.0にアドレス0.0.0に設定されます。
Wijnen & Levi Informational [Page 9] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[9ページ]のRFC2089V2toV1 January 1997
4.0 Acknowledgements
4.0 承認
The authors wish to thank the contributions of the SNMPv2 Working Group in general. Special thanks for their detailed review and comments goes to these individuals:
作者は感謝に一般に、SNMPv2作業部会の貢献を願っています。 彼らの詳細なレビューとコメントの特別な感謝はこれらの個人のものになります:
Mike Daniele (DEC)
Dave Harrington (Cabletron)
Brian O'Keefe (Hewlett Packard)
Keith McCloghrie (Cisco Systems)
Dave Perkins (independent)
Shawn Routhier (Epilogue)
Juergen Schoenwaelder (University of Twente)
マイク・ダニエル(12月)・デーヴ・ハリントン(Cabletron)・ブライアン・オキーフ(ヒューレットパッカード)キースMcCloghrie(シスコシステムズ)デーヴパーキンス(独立する)のショーンRouthier(エピローグ)ユルゲンSchoenwaelder(Twenteの大学)
5.0 References
5.0の参照箇所
[1] Jeffrey D. Case, Mark Fedor, Martin Lee Schoffstall and James
R. Davin, Simple Network Management Protocol (SNMP), SNMP
Research, Performance Systems International, MIT Laboratory
for Computer Science, RFC 1157, May 1990.
[1] ジェフリーD.事件とマークヒョードルとマーチンリーSchoffstallとジェームス・R.デーヴィン、簡単なネットワークマネージメントが議定書を作る、(SNMP)、SNMPは研究します、国際言語運用機構、MITコンピュータサイエンス研究所、RFC1157、5月1990
[2] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Structure of Managment Information for Version 2
of the Simple Network Management Protocol (SNMPv2), SNMP
Research Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1902, January 1996.
ジェフリーD.事件、キースMcCloghrie、マーシャル・T.ローズ、およびスティーブンWaldbusserが構造化する簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのManagment情報の[2]、SNMPはIncについて研究します、シスコシステムズInc、ドーヴァービーチコンサルティングInc、国際ネットワークサービス、RFC1902、1996年1月。
[3] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework, SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1908, January 1996.
[3] Incに相談して、インターネット標準ネットワークマネージメント枠組み、SNMP研究Inc、シスコシステムズInc、ドーヴァーのバージョン1とバージョン2の間のジェフリーD.事件とキースMcCloghrieとマーシャル・T.ローズとスティーブンWaldbusser、共存は無能にされます、国際ネットワークサービス、RFC1908、1996年1月。
[4] Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose and Steven
Waldbusser, Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2), SNMP Research
Inc, Cisco Systems Inc, Dover Beach Consulting Inc,
International Network Services, RFC1907, January 1996.
[4] ジェフリーD.事件とキースMcCloghrieとマーシャル・T.ローズとスティーブンWaldbusser、簡単なネットワークマネージメントのバージョン2のための管理情報ベースは(SNMPv2)について議定書の中で述べます、SNMP研究Inc、シスコシステムズInc、ドーヴァービーチコンサルティングInc、国際ネットワークサービス、RFC1907、1996年1月。
6.0 Security Considerations
6.0 セキュリティ問題
Security considerations are not discussed in this memo.
このメモでセキュリティ問題について議論しません。
Wijnen & Levi Informational [Page 10] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[10ページ]のRFC2089V2toV1 January 1997
7.0 Authors' Addresses
7.0 作者のアドレス
Bert Wijnen
IBM International Operations
Watsonweg 2
1423 ND Uithoorn
The Netherlands
バートのWijnen IBMの国際経営活動Watsonweg2 1423第オイトホルンオランダ
Phone: +31-079-322-8316
E-mail: wijnen@vnet.ibm.com
以下に電話をしてください。 +31-079-322-8316 メールしてください: wijnen@vnet.ibm.com
David Levi
SNMP Research, Inc
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
USA
デヴィッドレビSNMP Research、Inc3001Kimberlin Heights通り ノクスビル、テネシー37920-9716米国
Phone: +1-615-573-1434
E-mail: levi@snmp.com
以下に電話をしてください。 +1-615-573-1434 メールしてください: levi@snmp.com
Wijnen & Levi Informational [Page 11] RFC 2089 V2toV1 January 1997
Wijnenとレビ情報[11ページ]のRFC2089V2toV1 January 1997
APPENDIX A. Background Information
付録A.基礎的な情報
Here follows some reasoning as to why some choices were made.
ここで、いくつかの選択がされた理由に関する何らかの推理が続きます。
A.1 Mapping of error-status values
エラー状況値に関するA.1マッピング
The mapping of SNMPv2 error-status values to SNMPv1 error-status values is based on the common interpretation of how an SNMPv1 entity should create an error-status value based on the elements of procedure defined in RFC1157 [1].
SNMPv1エラー状況値へのSNMPv2エラー状況値に関するマッピングはSNMPv1実体がどうRFC1157[1]で定義された手順の要素に基づくエラー状況値を作成するべきであるかに関する一般的な解釈に基づいています。
There was a suggestion to map wrongEncoding into genErr, because it could be caused by an ASN.1 parsing error. Such maybe true, but in most cases when we detect the ASN.1 parsing error, we do not yet know about the PDU data yet. Most people who responded to our queries have implemented the mapping to a badValue. So we "agreed" on the mapping to badValue.
それがASN.1構文解析誤りで引き起こされる場合があったので、wrongEncodingをgenErrに写像するために、提案がありました。 ASN.1が誤りを分析するのを検出するとき、あれほど多分本当に、しかし、多くの場合、私たちはPDUデータに関してまだまだ知っていません。 私たちの質問に応じたほとんどの人々がbadValueにマッピングを実行しました。 それで、私たちはマッピングでbadValueに「同意しました」。
A.2 SNMPv1 Traps without Counter64 varBinds.
A.2 SNMPv1はCounter64 varBindsなしで捕らえます。
RFC1448 says that if one of the objects in the varBindList is not included in the view, then the trap is NOT sent. Current SNMPv2u and SNMPv2* documents make the same statement. However, the "rough consensus" is that it is better to send partial information than no information at all. Besides:
RFC1448は、varBindListの物の1つが視点に含まれていないなら罠が送られないと言います。 現在のSNMPv2uとSNMPv2*ドキュメントは同じ声明を出します。 しかしながら、「荒いコンセンサス」は部分的な情報を送るのが全くどんな情報ほども役に立たないということです。 さらに:
o RFC1448 does not allow for a TRAP to be sent with the varBinds
that are not included in the view removed, so it is an all or
nothing decision.
o RFC1448が、TRAPが取り除かれた意見に含まれていないvarBindsと共に送られるのを許容しないのでそれがある、すべてか無、決定。
o We do NOT include the Counter64 varBinds... so the "not in
view" varBinds are not sent to the trap destination.
o 私たちはCounter64 varBindsを入れません… したがって、varBindsがあるという「視点でない」は罠の目的地に発信しませんでした。
o The Counter64 objects are "implicit" not in view. If any
objects are explicit not in view, then this is checked before
we do the conversion from an SNMPv2 trap to an SNMPv1 trap, and
so the trap is not sent at all.
o Counter64物はどんな視点でも「暗黙ではありません」。 どれか物がどんな視点でも明白でないなら、私たちがSNMPv2罠からSNMPv1罠まで変換するので罠が全く送られない前にこれはチェックされます。
Wijnen & Levi Informational [Page 12]
Wijnenであって、レビInformationalです。[12ページ]
一覧
スポンサーリンク
