RFC2863 日本語訳
2863 The Interfaces Group MIB. K. McCloghrie, F. Kastenholz. June 2000. (Format: TXT=155014 bytes) (Obsoletes RFC2233) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. McCloghrie
Request for Comments: 2863 Cisco Systems
Obsoletes: 2233 F. Kastenholz
Category: Standards Track Argon Networks
June 2000
McCloghrieがコメントのために要求するワーキンググループK.をネットワークでつないでください: 2863 シスコシステムズは以下を時代遅れにします。 2233年のF.Kastenholzカテゴリ: 規格は2000年6月にアルゴンネットワークを追跡します。
The Interfaces Group MIB
インタフェースはMIBを分類します。
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Table of Contents
目次
1 Introduction ................................................. 2 2 The SNMP Network Management Framework ........................ 2 3 Experience with the Interfaces Group ......................... 3 3.1 Clarifications/Revisions ................................... 4 3.1.1 Interface Sub-Layers ..................................... 4 3.1.2 Guidance on Defining Sub-layers .......................... 7 3.1.3 Virtual Circuits ......................................... 8 3.1.4 Bit, Character, and Fixed-Length Interfaces .............. 8 3.1.5 Interface Numbering ...................................... 10 3.1.6 Counter Size ............................................. 14 3.1.7 Interface Speed .......................................... 16 3.1.8 Multicast/Broadcast Counters ............................. 17 3.1.9 Trap Enable .............................................. 17 3.1.10 Addition of New ifType values ........................... 18 3.1.11 InterfaceIndex Textual Convention ....................... 18 3.1.12 New states for IfOperStatus ............................. 18 3.1.13 IfAdminStatus and IfOperStatus .......................... 19 3.1.14 IfOperStatus in an Interface Stack ...................... 21 3.1.15 Traps ................................................... 21 3.1.16 ifSpecific .............................................. 23 3.1.17 Creation/Deletion of Interfaces ......................... 23 3.1.18 All Values Must be Known ................................ 24 4 Media-Specific MIB Applicability ............................. 24 5 Overview ..................................................... 25 6 Interfaces Group Definitions ................................. 26
1つの序論… 2 2、SNMPネットワークマネージメントフレームワーク… インタフェースの2 3経験は分類されます… 3 3.1の明確化/改正… 4 3.1 .1 副層を連結してください… 4 3.1 副層を定義するときの.2指導… 7 3.1 .3 仮想の回路… 8 3.1 .4のビット、キャラクター、および固定長は連結します… 8 3.1 .5 付番を連結してください… 10 3.1 .6 サイズを打ち返してください… 14 3.1 .7 速度を連結してください… 16 3.1 .8マルチキャスト/放送は反対します… 3.1.9罠が可能にする17… 17 3.1 New ifType値の.10追加… 18 3.1 .11 InterfaceIndexの原文のコンベンション… 18 3.1 .12 IfOperStatusのための新しい州… 18 3.1 .13IfAdminStatusとIfOperStatus… 19 3.1 インタフェースの.14IfOperStatusが積み重ねます… 21 3.1 .15 捕らえます… 21 3.1 .16はifSpecificされます… 23 3.1 .17 インタフェースの作成/削除… 23 3.1 .18、すべてのValues Must、Knownになってください… 24 4 メディア特有のMIBの適用性… 24 5概要… 25 6つのインタフェースが定義を分類します… 26
McCloghrie & Kastenholz Standards Track [Page 1] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[1ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
7 Acknowledgements ............................................. 64 8 References ................................................... 64 9 Security Considerations ...................................... 66 10 Authors' Addresses .......................................... 67 11 Changes from RFC 2233 ....................................... 67 12 Notice on Intellectual Property ............................. 68 13 Full Copyright Statement .................................... 69
7つの承認… 64 8つの参照箇所… 64 9 セキュリティ問題… 66 10人の作者のアドレス… RFC2233からの67 11回の変化… 67 12に知的所有権で気付きます… 68 13の完全な著作権宣言文… 69
1. Introduction
1. 序論
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II [17], especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the ' interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the ' interfaces' group. This memo obsoletes RFC 2233, the previous version of the Interfaces Group MIB.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはNetwork Interfacesを管理するのに使用される管理オブジェクトについて説明します。 このメモは'インタフェース'グループに関連したインターネットワーク層の下で様々な副層を管理する使用のための多数のメディア特有のMIBモジュールの定義から獲得していた状態でMIB-II[17]の'インタフェース'グループ、特に経験について議論します。 明確化を指定する、拡大、'インタフェース'のMIB-IIモデルの中の構造的な問題は分類されます。 このメモはRFC2233、Interfaces Group MIBの旧バージョンを時代遅れにします。
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [16].
このドキュメントのキーワード“MUST"と「必須NOT」はRFC2119[16]で説明されるように解釈されることです。
2. The SNMP Network Management Framework
2. SNMPネットワークマネージメントフレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [1].
o RFC2571[1]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
The second version, called SMIv2, is described in STD 58, which
consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[2]、STD16、RFC1212[3]、およびRFC1215[4]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58で説明されます。(STDはRFC2578[5]、RFC2579[6]、およびRFC2580[7]から成ります)。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the
SNMP message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [9] and
RFC 1906 [10]. The third version of the message protocol is
called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and
RFC 2574 [12].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[8]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[9]とRFC1906[10]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[10]、RFC2572[11]、およびRFC2574[12]でSNMPv3と呼ばれて、説明されます。
McCloghrie & Kastenholz Standards Track [Page 2] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[2ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[13].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[8]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[13]で説明されます。
o A set of fundamental applications described in RFC 2573 [14]
and the view-based access control mechanism described in RFC
2575 [15].
o 1セットの基礎的応用はRFCで2573[14]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[15]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22].
RFC2570[22]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(例えば、Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
3. Experience with the Interfaces Group
3. インタフェースグループの経験
One of the strengths of internetwork-layer protocols such as IP [18] is that they are designed to run over any network interface. In achieving this, IP considers any and all protocols it runs over as a single "network interface" layer. A similar view is taken by other internetwork-layer protocols. This concept is represented in MIB-II by the 'interfaces' group which defines a generic set of managed objects such that any network interface can be managed in an interface-independent manner through these managed objects. The ' interfaces' group provides the means for additional managed objects specific to particular types of network interface (e.g., a specific medium such as Ethernet) to be defined as extensions to the ' interfaces' group for media-specific management. Since the standardization of MIB-II, many such media-specific MIB modules have been defined.
IP[18]などのインターネットワーク層のプロトコルの強さの1つはそれらがどんなネットワーク・インターフェースもひくように設計されているということです。 これを達成する際に、IPはそれがただ一つの「ネットワーク・インターフェース」層として実行するありとあらゆるプロトコルを考えます。 他のインターネットワーク層のプロトコルは同様の意見を取ります。 この概念はMIB-IIにインタフェースから独立している方法でこれらの管理オブジェクトを通してどんなネットワーク・インターフェースにも対処できるように管理オブジェクトのジェネリックセットを定義する'インタフェース'グループによって表されます。 'インタフェース'への拡大がメディア特有の管理のために分類されるとき、'インタフェース'グループは特定のタイプのネットワーク・インターフェース(例えば、イーサネットなどの特定の媒体)に特定の追加管理オブジェクトが定義される手段を提供します。 MIB-IIの標準化以来、そのような多くのメディア特有のMIBモジュールが定義されています。
Experience in defining these media-specific MIB modules has shown that the model defined by MIB-II is too simplistic and/or static for some types of media-specific management. As a result, some of these media-specific MIB modules assume an evolution or loosening of the
これらのメディア特有のMIBモジュールを定義する経験は、何人かのタイプのメディア特有の管理に、MIB-IIによって定義されたモデルが安易過ぎる、そして/または、静的であることを示しました。 その結果、これらのメディア特有のMIBモジュールのいくつかが発展か緩みを仮定します。
McCloghrie & Kastenholz Standards Track [Page 3] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[3ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
model. This memo documents and standardizes that evolution of the model and fills in the gaps caused by that evolution. This memo also incorporates the interfaces group extensions documented in RFC 1229 [19].
モデル化してください。 このメモは、その発展によって引き起こされたギャップで、記録して、モデルのその発展を標準化して、いっぱいになります。 また、このメモは群拡大がRFC1229[19]に記録したインタフェースを取り入れます。
3.1. Clarifications/Revisions
3.1. 明確化/改正
There are several areas for which experience has indicated that clarification, revision, or extension of the model would be helpful. The following sections discuss the changes in the interfaces group adopted by this memo in each of these areas.
経験がモデルの明確化、改正、または拡大が役立っているのを示したいくつかの領域があります。 以下のセクションはグループがそれぞれのこれらの領域にこのメモで採用したインタフェースの変化について論じます。
In some sections, one or more paragraphs contain discussion of rejected alternatives to the model adopted in this memo. Readers not familiar with the MIB-II model and not interested in the rationale behind the new model may want to skip these paragraphs.
数人のセクションでは、1つ以上のパラグラフがこのメモに採用されたモデルへの拒絶された代替手段の議論を含んでいます。 MIB-IIモデルに詳しくなくてまた新しいモデルの後ろで原理に関心がない読者はこれらのパラグラフをスキップしたがっているかもしれません。
3.1.1. Interface Sub-Layers
3.1.1. インタフェース副層
Experience in defining media-specific management information has shown the need to distinguish between the multiple sub-layers beneath the internetwork-layer. In addition, there is a need to manage these sub-layers in devices (e.g., MAC-layer bridges) which are unaware of which, if any, internetwork protocols run over these sub-layers. As such, a model of having a single conceptual row in the interfaces table (MIB-II's ifTable) represent a whole interface underneath the internetwork-layer, and having a single associated media-specific MIB module (referenced via the ifType object) is too simplistic. A further problem arises with the value of the ifType object which has enumerated values for each type of interface.
メディア特有の経営情報を定義する経験はインターネットワーク層の下の複数の副層を見分ける必要性を示しました。 さらに、もしあれば、インターネットワークプロトコルがどれについてこれらの副層をひくかを気づかない状態でそうするデバイス(例えば、MAC-層のブリッジ)でこれらの副層を管理する必要があります。 そういうものとして、インタフェースのただ一つの概念的な行に(MIB-IIのifTable)をテーブルの上に置かせるモデルはインターネットワーク層の下に全体のインタフェースを表します、そして、ただ一つの関連メディア特有のMIBモジュール(ifTypeオブジェクトを通して、参照をつけられる)を持っているのは安易過ぎます。 さらなる問題はそれぞれのタイプのインタフェースに値を列挙したifTypeオブジェクトの値で起こります。
Consider, for example, an interface with PPP running over an HDLC link which uses a RS232-like connector. Each of these sub-layers has its own media-specific MIB module. If all of this is represented by a single conceptual row in the ifTable, then an enumerated value for ifType is needed for that specific combination which maps to the specific combination of media-specific MIBs. Furthermore, such a model still lacks a method to describe the relationship of all the sub-layers of the MIB stack.
例えばRS232のようなコネクタを使用するHDLCリンクをひくPPPとのインタフェースを考えてください。 それぞれのこれらの副層には、それ自身のメディア特有のMIBモジュールがあります。 このすべてがifTableのただ一つの概念的な行で表されるなら、ifTypeのための列挙された値がメディア特有の特定の組み合わせにMIBsを写像するその特定の組み合わせに必要です。 その上、そのようなモデルはまだMIBスタックのすべての副層の関係について説明するメソッドを欠いています。
An associated problem is that of upward and downward multiplexing of the sub-layers. An example of upward multiplexing is MLP (Multi- Link-Procedure) which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer(s) above. An example of downward multiplexing would be several instances of PPP, each framed within a separate X.25 virtual circuit,
関連する問題は副層の上向きの、そして、下向きのマルチプレクシングのものです。 上向きのマルチプレクシングに関する例は単一のポイントツーポイント接続として上で副層に見えることによっていくつかのシリアル・ラインの上に負荷分割法を供給するMLP(マルチLinkの手順)です。 下向きのマルチプレクシングに関する例はPPPのいくつかのインスタンス、別々のX.25仮想の回路の中に縁どられたそれぞれでしょう。
McCloghrie & Kastenholz Standards Track [Page 4] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[4ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
all of which run over one fractional T1 channel, concurrently with other uses of the T1 link. The MIB structure must allow these sorts of relationships to be described.
それのすべてがT1リンクの他の用途で断片的なT1が同時にチャネルを開設する1つ以上を実行します。 MIB構造は、これらの種類の関係が説明されるのを許容しなければなりません。
Several solutions for representing multiple sub-layers were rejected. One was to retain the concept of one conceptual row for all the sub- layers of an interface and have each media-specific MIB module identify its "superior" and "subordinate" sub-layers through OBJECT IDENTIFIER "pointers". This scheme would have several drawbacks: the superior/subordinate pointers would be contained in the media- specific MIB modules; thus, a manager could not learn the structure of an interface without inspecting multiple pointers in different MIB modules; this would be overly complex and only possible if the manager had knowledge of all the relevant media-specific MIB modules; MIB modules would all need to be retrofitted with these new "pointers"; this scheme would not adequately address the problem of upward and downward multiplexing; and finally, enumerated values of ifType would be needed for each combination of sub-layers. Another rejected solution also retained the concept of one conceptual row for all the sub-layers of an interface but had a new separate MIB table to identify the "superior" and "subordinate" sub-layers and to contain OBJECT IDENTIFIER "pointers" to the media-specific MIB module for each sub-layer. Effectively, one conceptual row in the ifTable would represent each combination of sub-layers between the internetwork-layer and the wire. While this scheme has fewer drawbacks, it still would not support downward multiplexing, such as PPP over MLP: observe that MLP makes two (or more) serial lines appear to the layers above as a single physical interface, and thus PPP over MLP should appear to the internetwork-layer as a single interface; in contrast, this scheme would result in two (or more) conceptual rows in the ifTable, both of which the internetwork-layer would run over. This scheme would also require enumerated values of ifType for each combination of sub-layers.
複数の副層を表すためのいくつかのソリューションが拒絶されました。 1つで、それぞれのメディア特有のMIBモジュールは、インタフェースのすべてのサブ層のための1つの概念的な行の概念を保有して、OBJECT IDENTIFIER「指針」を通して「優れ」て「下位」の副層を特定することになっていました。 この体系には、いくつかの欠点があるでしょう: 優れたか下位の指針はメディアの特定のMIBモジュールで含まれるでしょう。 したがって、異なったMIBモジュールで複数の指針を点検しないで、マネージャはインタフェースの構造を学ぶことができませんでした。 マネージャにすべての関連メディア特有のMIBモジュールに関する知識がある場合にだけ、これは、ひどく複雑であって、可能でしょうに。 MIBモジュールはすべて、これらの新しい「指針」で改装される必要があるでしょう。 この体系は適切に上向きの、そして、下向きのマルチプレクシングのその問題を訴えないでしょう。 そして、最終的に、ifTypeの列挙された値が副層の各組み合わせに必要でしょう。 別の拒絶されたソリューションは、各副層のためのメディア特有のMIBモジュールにまた、インタフェースのすべての副層のための1つの概念的な行の概念を保有しましたが、「優れ」て「下位」の副層を特定して、OBJECT IDENTIFIER「指針」を含む新しい別々のMIBテーブルを持っていました。 事実上、ifTableの1つの概念的な行がインターネットワーク層とワイヤの間の副層の各組み合わせを表すでしょう。 この体系には、より少ない欠点がある間、まだ、MLPの上のPPPなどの下向きのマルチプレクシングをサポートしていないでしょう: MLPが単一の物理インターフェースとして上に2個(さらに)のシリアル・ラインを層に現れさせるのを観測してください。そうすれば、その結果、MLPの上のPPPは単一のインタフェースとしてインターネットワーク層に見えるはずです。 対照的に、この体系はifTableの2つ(さらに)の概念的な行をもたらすでしょう。インターネットワーク層はその両方をひくでしょう。また、この体系は副層の各組み合わせのためにifTypeの列挙された値を必要とするでしょう。
The solution adopted by this memo is to have an individual conceptual row in the ifTable to represent each sub-layer, and have a new separate MIB table (the ifStackTable, see section 6 below) to identify the "superior" and "subordinate" sub-layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable. This solution supports both upward and downward multiplexing, allows the IANAifType to Media-Specific MIB mapping to identify the media- specific MIB module for that sub-layer, such that the new table need only be referenced to obtain information about layering, and it only requires enumerated values of ifType for each sub-layer, not for combinations of them. However, it does require that the descriptions of some objects in the ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to any sub-layer (rather than only to a sub-layer immediately beneath
見てください。このメモによって採用されたソリューションが各副層を表すためにifTableに個々の概念的な行を持っていて、新しい別々のMIBテーブルを持つことである、(ifStackTable、下のセクション6) INTEGER「指針」を通して「優れ」て「下位」の副層をifTableの適切な概念的な行に特定するために。 このソリューションは、両方が上向きの、そして、下向きのマルチプレクシングであるとサポートします、とIANAifTypeはその副層のためにメディアの特定のMIBモジュールを特定するメディア特有のMIBマッピングに許容します、新しいテーブルがレイヤリングの情報を得るためには参照をつけられるだけでよくて、それらの組み合わせに必要であるのではなく、各副層のためにifTypeの列挙された値を必要とするだけであるように。 しかしながら、ifTable(明確にifType、ifPhysAddress、ifInUcastPkts、およびifOutUcastPkts)のいくつかのオブジェクトの記述がどんな副層にも適用するために一般化されるのが必要である、(むしろ、すぐに下の副層だけ
McCloghrie & Kastenholz Standards Track [Page 5] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[5ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
the network layer as previously), plus some (specifically, ifSpeed) which need to have appropriate values identified for use when a generalized definition does not apply to a particular sub-layer.
ネットワーク層、同じくらい以前に)、そのうえ、適切な値を必要とする或るもの(明確にifSpeed)は、使用のために一般化された定義がいつ特定の副層に適用されないかを特定しました。
In addition, this adopted solution makes no requirement that a device, in which a sub-layer is instrumented by a conceptual row of the ifTable, be aware of whether an internetwork protocol runs on top of (i.e., at some layer above) that sub-layer. In fact, the counters of packets received on an interface are defined as counting the number "delivered to a higher-layer protocol". This meaning of "higher-layer" includes:
さらに、この採用されたソリューションは副層がどれであるかにifTableの概念的な行によって器具を取り付けられたデバイスがインターネットワークプロトコルがその(すなわち、上の何らかの層の)副層の上で稼働するかどうかを意識しているという要件を全く作りません。 事実上、インタフェースに受け取られたパケットのカウンタは「上位層プロトコルに提供された」数を数えると定義されます。 「より高い層」のこの意味は:
(1) Delivery to a forwarding module which accepts
packets/frames/octets and forwards them on at the same protocol
layer. For example, for the purposes of this definition, the
forwarding module of a MAC-layer bridge is considered as a
"higher-layer" to the MAC-layer of each port on the bridge.
(1) /が同じプロトコル層で/八重奏を縁どっていて、それらを進めるパケットを受け入れる推進モジュールへの配送。 例えば、この定義の目的のために、MAC-層のブリッジの推進モジュールはブリッジの上のそれぞれのポートのMAC-層への「より高い層」であるとみなされます。
(2) Delivery to a higher sub-layer within a interface stack. For
example, for the purposes of this definition, if a PPP module
operated directly over a serial interface, the PPP module would
be considered the higher sub-layer to the serial interface.
(2) インタフェーススタックの中の、より高い副層への配送。 例えば、この定義の目的のために、PPPモジュールがシリアルインタフェースの上で直営するなら、PPPモジュールはシリアルインタフェースへの、より高い副層であると考えられるでしょうに。
(3) Delivery to a higher protocol layer which does not do packet
forwarding for sub-layers that are "at the top of" the
interface stack. For example, for the purposes of this
definition, the local IP module would be considered the higher
layer to a SLIP serial interface.
(3) 副層のためのパケット推進をしないより高いプロトコル層への配送、「」 インタフェースの先端では、積み重ねてください。 例えば、この定義の目的のために、ローカルアイピーモジュールはSLIPシリアルインタフェースへの、より高い層であると考えられるでしょう。
Similarly, for output, the counters of packets transmitted out an interface are defined as counting the number "that higher-level protocols requested to be transmitted". This meaning of "higher- layer" includes:
同様に、出力において、インタフェースから伝えられたパケットのカウンタは「上位レベル・プロトコルは伝えられるよう要求した」数を数えると定義されます。 「より高い層」のこの意味は:
(1) A forwarding module, at the same protocol layer, which
transmits packets/frames/octets that were received on an
different interface. For example, for the purposes of this
definition, the forwarding module of a MAC-layer bridge is
considered as a "higher-layer" to the MAC-layer of each port on
the bridge.
(1) 同じプロトコル層の推進モジュール。(それは、異なったインタフェースで受けられたパケット/フレーム/八重奏を伝えます)。 例えば、この定義の目的のために、MAC-層のブリッジの推進モジュールはブリッジの上のそれぞれのポートのMAC-層への「より高い層」であるとみなされます。
(2) The next higher sub-layer within an interface stack. For
example, for the purposes of this definition, if a PPP module
operated directly over a serial interface, the PPP module would
be a "higher layer" to the serial interface.
(2) インタフェーススタックの中の次の、より高い副層。 例えば、この定義の目的のために、PPPモジュールがシリアルインタフェースの上で直営するなら、PPPモジュールはシリアルインタフェースへの「より高い層」でしょうに。
McCloghrie & Kastenholz Standards Track [Page 6] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[6ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
(3) For sub-layers that are "at the top of" the interface stack, a
higher element in the network protocol stack. For example, for
the purposes of this definition, the local IP module would be
considered the higher layer to an Ethernet interface.
副層のための(3)、「」 インタフェーススタックの先端では、ネットワーク・プロトコルにおける、より高い要素に、積み重ねてください。 例えば、この定義の目的のために、ローカルアイピーモジュールはイーサネットインタフェースへの、より高い層であると考えられるでしょう。
3.1.2. Guidance on Defining Sub-layers
3.1.2. 副層を定義するときの指導
The designer of a media-specific MIB must decide whether to divide the interface into sub-layers or not, and if so, how to make the divisions. The following guidance is offered to assist the media- specific MIB designer in these decisions.
メディア特有のMIBのデザイナーは、インタフェースを副層に分割するかどうかと、そうだとすれば、どのように分割をするかを決めなければなりません。 メディアの特定のMIBデザイナーをこれらの決定に助けるために以下の指導を提供します。
In general, the number of entries in the ifTable should be kept to the minimum required for network management. In particular, a group of related interfaces should be treated as a single interface with one entry in the ifTable providing that:
一般に、ifTableのエントリーの数はネットワークマネージメントに必要である最小限に保たれるべきです。 特に、関連するインタフェースのグループがifTableの1つのエントリーとの単一のインタフェースとして扱われるべきである、:
(1) None of the group of interfaces performs multiplexing for any
other interface in the agent,
(1) インタフェースのグループのいずれもエージェントでいかなる他のインタフェースにもマルチプレクシングを実行しません。
(2) There is a meaningful and useful way for all of the ifTable's
information (e.g., the counters, and the status variables), and
all of the ifTable's capabilities (e.g., write access to
ifAdminStatus), to apply to the group of interfaces as a whole.
(2) 全体でインタフェースのグループに適用するために、ifTableの情報のすべて(例えば、カウンタ、および状態変数)、およびifTableの能力のすべて(例えば、ifAdminStatusへのアクセスを書く)のための重要で役に立つ方法があります。
Under these circumstances, there should be one entry in the ifTable for such a group of interfaces, and any internal structure which needs to be represented to network management should be captured in a MIB module specific to the particular type of interface.
こういう事情ですから、1つのエントリーがインタフェースのそのようなグループのためのifTableにあるべきです、そして、特定のタイプのインタフェースに特定のMIBモジュールでネットワークマネージメントに表される必要があるどんな内部の構造も得るべきです。
Note that application of bullet 2 above to the ifTable's ifType object requires that there is a meaningful media-specific MIB and a meaningful ifType value which apply to the group of interfaces as a whole. For example, it is not appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as a single ifTable entry when the media- specific MIBs and the ifType values for HDLC and RS-232 are separate (rather than combined).
ifTypeが全体でインタフェースのグループに適用される重要なメディア特有のMIBと重要なifType値があるのが必要であることを反対させるifTableのものに上で弾丸2のその塗布に注意してください。 メディアの特定のMIBsとHDLCとRS-232のためのifType値が別々であるときに(結合されているよりむしろ)、例えば、単一のifTableエントリーとしてHDLC副層とRS-232副層を扱うのは適切ではありません。
Subject to the above, it is appropriate to assign an ifIndex value to any interface that can occur in an interface stack (in the ifStackTable) where the bottom of the stack is a physical interface (ifConnectorPresent has the value 'true') and there is a layer-3 or other application that "points down" to the top of this stack. An example of an application that points down to the top of the stack is the Character MIB [21].
上記を条件として、スタックの下部が物理インターフェース(ifConnectorPresentは'本当'に値を持っている)であり、このスタックの先端には「ポイントは倒す」層-3か他の利用があるインタフェーススタック(ifStackTableの)に起こることができるどんなインタフェースにもifIndex値を割り当てるのが適切です。 スタックの先端まで向けられるアプリケーションに関する例はキャラクターMIB[21]です。
McCloghrie & Kastenholz Standards Track [Page 7] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[7ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
Note that the sub-layers of an interface on one device will sometimes be different from the sub-layers of the interconnected interface of another device; for example, for a frame-relay DTE interface connected a frameRelayService interface, the inter-connected DTE and DCE interfaces have different ifType values and media-specific MIBs.
1台のデバイスの上のインタフェースの副層が別のデバイスのインタコネクトされたインタフェースの副層と時々異なることに注意してください。 例えば、フレームリレーDTEインタフェースがframeRelayServiceインタフェースを接続したのでインタコネクトされたDTEとDCEインタフェースには、異なったifType値とメディア特有のMIBsがあります。
These guidelines are just that, guidelines. The designer of a media-specific MIB is free to lay out the MIB in whatever SMI conformant manner is desired. However, in doing so, the media- specific MIB MUST completely specify the sub-layering model used for the MIB, and provide the assumptions, reasoning, and rationale used to develop that model.
これらのガイドラインがまさしくそれである、ガイドライン。 メディア特有のMIBのデザイナーは望まれているどんなSMI conformant方法でも自由にMIBを広げることができます。 しかしながら、そうすることにおけるメディアの特定のMIB MUSTはMIBに使用されるサブレイヤリングモデルを完全に指定して、そのモデルを開発するのに使用される仮定、推理、および原理を提供します。
3.1.3. Virtual Circuits
3.1.3. 仮想の回路
Several of the sub-layers for which media-specific MIB modules have been defined are connection oriented (e.g., Frame Relay, X.25). Experience has shown that each effort to define such a MIB module revisits the question of whether separate conceptual rows in the ifTable are needed for each virtual circuit. Most, if not all, of these efforts to date have decided to have all virtual circuits reference a single conceptual row in the ifTable.
メディア特有のMIBモジュールが定義された副層の数個は適応する接続(例えば、Frame Relay、X.25)です。 経験は、そのようなMIBモジュールを定義する各取り組みがifTableの別々の概念的な行がそれぞれの仮想の回路に必要であるかどうかに関する質問を再訪させるのを示しました。 これまでのこれらの取り組みの大部分(すべてでなくても)は、すべての仮想の回路にifTableでただ一つの概念的な行に参照をつけさせると決めました。
This memo strongly recommends that connection-oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual rows, especially those which have considerable redundant information. (Note, as a comparison, that connection-less sub-layers do not have conceptual rows for each remote address.) There may, however, be circumstances under which it is appropriate for a virtual circuit of a connection- oriented sub-layer to have its own conceptual row in the ifTable; an example of this might be PPP over an X.25 virtual circuit. The MIB in section 6 of this memo supports such circumstances.
このメモは、接続指向の副層がそれぞれの仮想の回路へのifTableに概念的な行を持たないことを強く勧めます。 これは概念的な行、特にかなりの余分な情報を持っているものの増殖を避けます。 (比較として、コネクションレスな副層にはそれぞれのリモートアドレスのための概念的な行がないことに注意してください。) しかしながら、接続指向の副層の仮想の回路がifTableにそれ自身の概念的な行を持っているのが、適切である事情があるかもしれません。 この例はX.25の仮想の回路の上のPPPであるかもしれません。 このメモのセクション6のMIBはそのような事情をサポートします。
If a media-specific MIB wishes to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for this decision in the media-specific MIB's specification.
メディア特有のMIBがifTableでそれぞれの仮想の回路にエントリーを割り当てたいなら、MIBデザイナーはメディア特有のMIBの仕様に基づくこの決定のために原理を提示しなければなりません。
3.1.4. Bit, Character, and Fixed-Length Interfaces
3.1.4. ビット、キャラクター、および固定長インタフェース
RS-232 is an example of a character-oriented sub-layer over which (e.g., through use of PPP) IP datagrams can be sent. Due to the packet-based nature of many of the objects in the ifTable, experience has shown that it is not appropriate to have a character-oriented sub-layer represented by a whole conceptual row in the ifTable.
RS-232は(例えば、PPPの使用による)IPデータグラムを送ることができるキャラクタ指向の副層に関する例です。 ifTableのオブジェクトの多くのパケットベースの本質のため、経験は、ifTableの全体の概念的な行でキャラクタ指向の副層を表させるのが適切でないことを示しました。
McCloghrie & Kastenholz Standards Track [Page 8] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[8ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
Experience has also shown that it is sometimes desirable to have some management information for bit-oriented interfaces, which are similarly difficult to represent by a whole conceptual row in the ifTable. For example, to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data.
また、経験は、ビット指向のインタフェースのための何らかの経営情報を持っているのが時々望ましいのを示しました。インタフェースはifTableの全体の概念的な行で表すのが同様に難しいです。 例えば何人かのチャンネルだけがパケットベースのデータを運ぶDS1回路のチャンネルを管理するために。
A further complication is that some subnetwork technologies transmit data in fixed length transmission units. One example of such a technology is cell relay, and in particular Asynchronous Transfer Mode (ATM), which transmits data in fixed-length cells. Representing such a interface as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit (e.g., the size of a cell).
さらなる複雑さはいくつかのサブネットワーク技術が固定長トランスミッション単位のデータを送るということです。 そのような技術に関する1つの例が、セルリレーと、特にAsynchronous Transfer Mode(ATM)です。(そのAsynchronous Transfer Modeは固定長セルの中でデータを送ります)。 パケットベースのインタフェースのようなインタフェースを表すと、パケットの数とどちらかの方向への八重奏の数との関係がトランスミッションユニット(例えば、セルのサイズ)のサイズによって修理されているなら、余分なオブジェクトは作り出されます。
About half the objects in the ifTable are applicable to every type of interface: packet-oriented, character-oriented, and bit-oriented. Of the other half, two are applicable to both character-oriented and packet-oriented interfaces, and the rest are applicable only to packet-oriented interfaces. Thus, while it is desirable for consistency to be able to represent any/all types of interfaces in the ifTable, it is not possible to implement the full ifTable for bit- and character-oriented sub-layers.
ifTableのオブジェクトのおよそ半分がすべてのタイプのインタフェースに適切です: パケット指向で、キャラクタ指向で、ビット指向です。 もう片方の半分では、2はキャラクタ指向のものと同様にパケット指向のインタフェースに適切です、そして、残りはパケット指向のインタフェースだけに適切です。 したがって、一貫性がifTableにすべてがタイプするインタフェースのどんな/も表すことができるのが、望ましいのですが、ビットとキャラクタ指向の副層のために完全なifTableを実装するのは可能ではありません。
A rejected solution to this problem would be to split the ifTable into two (or more) new MIB tables, one of which would contain objects that are relevant only to packet-oriented interfaces (e.g., PPP), and another that may be used by all interfaces. This is highly undesirable since it would require changes in every agent implementing the ifTable (i.e., just about every existing SNMP agent).
この問題への2個(さらに)の新しいMIBテーブル、1つへのそれのifTableがパケット指向のインタフェース(例えば、PPP)だけに関連しているオブジェクト、およびすべてのインタフェースによって使用されるかもしれない別のものを含む拒絶された解決は分かれることになっているでしょう。 ifTable(すなわち、まさしくすべての既存のSNMPエージェントに関する)を実装しながら、すべてのエージェントに釣り銭がいるでしょう、したがって、これは非常に望ましくありません。
The solution adopted in this memo builds upon the fact that compliance statements in SMIv2 (in contrast to SMIv1) refer to object groups, where object groups are explicitly defined by listing the objects they contain. Thus, with SMIv2, multiple compliance statements can be specified, one for all interfaces and additional ones for specific types of interfaces. The separate compliance statements can be based on separate object groups, where the object group for all interfaces can contain only those objects from the ifTable which are appropriate for every type of interfaces. Using this solution, every sub-layer can have its own conceptual row in the ifTable.
このメモに採用されたソリューションはSMIv2(SMIv1と対照して)での承諾声明がオブジェクトグループがそれらが含むオブジェクトを記載することによって明らかに定義されるオブジェクトグループを参照するという事実を当てにします。 したがって、SMIv2と共に、複数の承諾声明を指定できて、すべてのための1つは、特定のタイプのインタフェースへのインタフェースと追加ものです。 別々の承諾声明は別々のオブジェクトグループに基づくことができます。そこでは、すべてのインタフェースへのオブジェクトグループがすべてのタイプのインタフェースに、適切なifTableからのそれらのオブジェクトしか含むことができません。 このソリューションを使用して、あらゆる副層がifTableにそれ自身の概念的な行を持つことができます。
Thus, section 6 of this memo contains definitions of the objects of
the existing 'interfaces' group of MIB-II, in a manner which is both
SNMPv2-compliant and semantically-equivalent to the existing MIB-II
definitions. With equivalent semantics, and with the BER ("on the
したがって、このメモのセクション6はMIB-IIの既存の'インタフェース'グループのオブジェクトの定義を含みます、既存のMIB-II定義にSNMPv2対応であって、かつ意味的に同等な方法で。 同等な意味論、およびBER、(「オンである、」
McCloghrie & Kastenholz Standards Track [Page 9] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[9ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
wire") encodings unchanged, these definitions retain the same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in general, no rewrite of existing agents which conform to MIB-II and the ifExtensions MIB is required.
「ワイヤ」) encodings変わりがなくて、これらの定義はMIB-IIによって割り当てられるのと同じOBJECT IDENTIFIER値を保有します。 このようにして、そして、一般に、MIB-IIとifExtensions MIBに従う既存のエージェントの書き直しは全く必要ではありません。
In addition, this memo defines several object groups for the purposes of defining which objects apply to which types of interface:
さらに、このメモはどのオブジェクトがどのタイプのインタフェースに適用されるかを定義する目的のためにいくつかのオブジェクトグループを定義します:
(1) the ifGeneralInformationGroup. This group contains those
objects applicable to all types of network interfaces,
including bit-oriented interfaces.
(1) ifGeneralInformationGroup。 このグループはビット指向のインタフェースを含むすべてのタイプのネットワーク・インターフェースに適切なそれらのオブジェクトを含みます。
(2) the ifPacketGroup. This group contains those objects
applicable to packet-oriented network interfaces.
(2) ifPacketGroup。 このグループはパケット指向のネットワーク・インターフェースに適切なそれらのオブジェクトを含みます。
(3) the ifFixedLengthGroup. This group contains the objects
applicable not only to character-oriented interfaces, such as
RS-232, but also to those subnetwork technologies, such as
cell-relay/ATM, which transmit data in fixed length
transmission units. As well as the octet counters, there are
also a few other counters (e.g., the error counters) which are
useful for this type of interface, but are currently defined as
being packet-oriented. To accommodate this, the definitions of
these counters are generalized to apply to character-oriented
interfaces and fixed-length-transmission interfaces.
(3) ifFixedLengthGroup。 このグループはRS-232などのキャラクタ指向のインタフェースだけではなく、それらのサブネットワーク技術に適切なオブジェクトを含みます、セルリレー/ATMなどのように。(ATMは固定長トランスミッション単位のデータを送ります)。 また、八重奏カウンタと同様に、このタイプのインタフェースの役に立ちますが、現在パケット指向であると定義される他のいくつかのカウンタ(例えば、誤りカウンタ)があります。 これを収容するなら、これらのカウンタの定義は、キャラクタ指向のインタフェースと固定長さの送信インタフェースに適用するために一般化されます。
It should be noted that the octet counters in the ifTable aggregate octet counts for unicast and non-unicast packets into a single octet counter per direction (received/transmitted). Thus, with the above definition of fixed-length-transmission interfaces, where such interfaces which support non-unicast packets, separate counts of unicast and multicast/broadcast transmissions can only be maintained in a media-specific MIB module.
ifTableの八重奏カウンタが方向(受け取るか、または伝える)あたり1台の単一の八重奏カウンタへのユニキャストと非ユニキャストパケットのための八重奏カウントに集められることに注意されるべきです。 したがって、固定長さの送信インタフェースの上の定義で、メディア特有のMIBモジュールでユニキャストとマルチキャスト/放送送信の別々のカウントを維持できるだけです。(そこでは、そのようなものがそのサポート非ユニキャストパケットを連結します)。
3.1.5. Interface Numbering
3.1.5. インタフェース付番
MIB-II defines an object, ifNumber, whose value represents:
MIB-IIはオブジェクト、値が以下を表すifNumberを定義します。
"The number of network interfaces (regardless of their
current state) present on this system."
「ネットワークの数はこのシステムにプレゼントを接続します(彼らの現状にかかわらず)。」
Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value as follows:
各インタフェースはifIndexオブジェクトのユニークな値によって特定されます、そして、ifIndexの記述は以下の値を抑制します:
"Its value ranges between 1 and the value of ifNumber. The
value for each interface must remain constant at least from
one re-initialization of the entity's network management
system to the next re-initialization."
「値はifNumberの1と値の間で及びます。」 「各インタフェースへの値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」
McCloghrie & Kastenholz Standards Track [Page 10] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[10ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. However, an increasing number of devices allow for the dynamic addition/removal of network interfaces. One example of this is a dynamic ability to configure the use of SLIP/PPP over a character-oriented port. For such dynamic additions/removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic.
能率的経営に、特定のインタフェースへのifIndexの値に関するこの不変性要件が必要です。 しかしながら、増加する数のデバイスがネットワーク・インターフェースのダイナミックな追加/取り外しを考慮します。 この1つの例がキャラクタ指向のポートの上でSLIP/PPPの使用を構成するダイナミックな能力です。 そのようなダイナミックな追加/取り外しにおいて、不変性要件の組み合わせとifIndexの値がifNumber以下であるという制限は問題が多いです。
Redefining ifNumber to be the largest value of ifIndex was rejected since it would not help. Such a re-definition would require ifNumber to be deprecated and the utility of the redefined object would be questionable. Alternatively, ifNumber could be deprecated and not replaced. However, the deprecation of ifNumber would require a change to that portion of ifIndex's definition which refers to ifNumber. So, since the definition of ifIndex must be changed anyway in order to solve the problem, changes to ifNumber do not benefit the solution.
助からないでしょう、したがって、ifIndexの最も大きい値になるようにifNumberを再定義するのは拒絶されました。 そのような再定義は、ifNumberが推奨しないのを必要とするでしょう、そして、再定義されたオブジェクトのユーティリティは疑わしいでしょう。 あるいはまた、ifNumberは推奨しなく取り替えることができませんでした。 しかしながら、ifNumberの不賛成はifNumberについて言及するifIndexの定義のその部分への変化を必要とするでしょう。 それで、問題を解決するためにとにかくifIndexの定義を変えなければならないので、ifNumberへの変化はソリューションのためになりません。
The solution adopted in this memo is just to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition. This is a minor change in the semantics of ifIndex; however, all existing agent implementations conform to this new definition, and in the interests of not requiring changes to existing agent implementations and to the many existing media-specific MIBs, this memo assumes that this change does not require ifIndex to be deprecated. Experience indicates that this assumption does "break" a few management applications, but this is considered preferable to breaking all agent implementations.
このメモに採用されたソリューションは、まさしく、ifIndexの値がifNumberの値以下でなければならないという要件を削除して、現在の定義があるifNumberを保有することです。 これはifIndexの意味論でマイナーチェンジです。 しかしながら、すべての既存のエージェント実装がこの新しい定義に従います、そして、既存のエージェント実装と、そして、多くの既存のメディア特有のMIBsへの変化を必要としないことのために、このメモはこの変化が、ifIndexが推奨しないのを必要としないと仮定します。 経験は、この仮定がいくつかの管理アプリケーションを「壊すこと」を示しますが、これはすべてのエージェント実装を壊すより望ましいと考えられます。
This solution also results in the possibility of "holes" in the ifTable, i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous, but SNMP's GetNext (and GetBulk) operation easily deals with such holes. The value of ifNumber still represents the number of conceptual rows, which increases/decreases as new interfaces are dynamically added/removed.
また、このソリューションはifTableの「穴」の可能性をもたらしますが、すなわち、ifTableの概念的な行のifIndex値は必ず隣接であるというわけではありませんが、SNMPのGetNext(そして、GetBulk)操作は容易にそのような穴に対処します。 ifNumberの値はまだ概念的な行の数を表しています。(ダイナミックに新しいインタフェースを加えるか、または取り除くのに従って、それは、増強するか、または減少します)。
The requirement for constancy (between re-initializations) of an interface's ifIndex value is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used by a *different* dynamically added interface until after the following re-initialization of the network management system. This avoids the need for assignment (in advance) of ifIndex values for all possible interfaces that might be added dynamically. The exact meaning of a "different" interface is hard to define, and there will be gray areas. Any firm definition in this document would likely turn out to be inadequate. Instead, implementors must choose what it means in their particular situation, subject to the following rules:
ダイナミックにインタフェースを取り除いた後にダイナミックに加えられた*異なった*インタフェースでネットワーク管理システムの以下の再初期化の後までifIndex値を再使用しないのを必要とすることによって、インタフェースのifIndex価値の不変性(再初期化処理の間の)のための必要条件は満たされます。 これはifIndex値の課題(あらかじめ)の必要性をダイナミックに加えられるかもしれないすべての可能なインタフェースとして避けます。 「異なった」インタフェースの正確な意味は定義しにくいです、そして、暗い領域があるでしょう。 どんな堅い定義も不十分であると本書ではおそらく判明するでしょう。 代わりに、作成者は、以下の規則を条件としてそれが彼らの特定の状況で何を意味するかを選ばなければなりません:
McCloghrie & Kastenholz Standards Track [Page 11] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[11ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
(1) a previously-unused value of ifIndex must be assigned to a
dynamically added interface if an agent has no knowledge of
whether the interface is the "same" or "different" to a
previously incarnated interface.
(1) エージェントにインタフェースが以前に肉体を与えられたインタフェースへの「同じである」か「異なる」であるのに関する知識が全くないなら、ifIndexの以前に未使用の値をダイナミックに加えられたインタフェースに割り当てなければなりません。
(2) a management station, not noticing that an interface has gone
away and another has come into existence, must not be confused
when calculating the difference between the counter values
retrieved on successive polls for a particular ifIndex value.
(2) 特定のifIndex値のための連続した投票のときに検索された対価の違いについて計算するとき、インタフェースが遠ざかって、別のものが生まれたのに気付くのではなく、管理局が混乱してはいけません。
When the new interface is the same as an old interface, but a discontinuity in the value of the interface's counters cannot be avoided, the ifTable has (until now) required that a new ifIndex value be assigned to the returning interface. That is, either all counter values have had to be retained during the absence of an interface in order to use the same ifIndex value on that interface's return, or else a new ifIndex value has had to be assigned to the returning interface. Both alternatives have proved to be burdensome to some implementations:
新しいインタフェースが古いインタフェースと同じですが、インタフェースのカウンタの値における不連続を避けることができないとき、ifTableは、新しいifIndex値が戻っているインタフェースに割り当てられるのを必要としました(現在まで)。 すなわち、値がそのインタフェースのリターンの同じifIndex値を使用するためにインタフェースの不在の間、保有されるために持っていたすべてのカウンタか新しいifIndex値のどちらかが戻っているインタフェースに割り当てられなければなりませんでした。 両方の代替手段はいくつかの実装に重荷になると判明しました:
(1) maintaining the counter values may not be possible (e.g., if
they are maintained on removable hardware),
(1) 対価を維持するのは可能でないかもしれません(例えば、それらが移動可能なハードウェアの上で維持されるなら)。
(2) using a new ifIndex value presents extra work for management
applications. While the potential need for such extra work is
unavoidable on agent re-initializations, it is desirable to
avoid it between re-initializations.
(2) 新しいifIndex値を使用すると、管理アプリケーションのための時間外労働は提示されます。 そのような時間外労働の潜在的必要性はエージェント再初期化処理のときに避けられないのですが、再初期化処理の間でそれを避けるのは望ましいです。
To address this, a new object, ifCounterDiscontinuityTime, has been defined to record the time of the last discontinuity in an interface's counters. By monitoring the value of this new object, a management application can now detect counter discontinuities without the ifIndex value of the interface being changed. Thus, an agent which implements this new object should, when a new interface is the same as an old interface, retain that interface's ifIndex value and update if necessary the interface's value of ifCounterDiscontinuityTime. With this new object, a management application must, when calculating differences between counter values retrieved on successive polls, discard any calculated difference for which the value of ifCounterDiscontinuityTime is different for the two polls. (Note that this test must be performed in addition to the normal checking of sysUpTime to detect an agent re-initialization.) Since such discards are a waste of network management processing and bandwidth, an agent should not update the value of ifCounterDiscontinuityTime unless absolutely necessary.
これを扱うなら、新しいオブジェクト(ifCounterDiscontinuityTime)は、インタフェースのカウンタの最後の不連続の時間を記録するために定義されました。 この新しいオブジェクトの値をモニターすることによって、管理アプリケーションは現在、変えられるインタフェースのifIndex値なしでカウンタ不連続を検出できます。 その結果、新しいインタフェースが古いインタフェースと同じであるときに、この新しいオブジェクトがそうするべきであるそれの道具がそのインタフェースのifIndex値を保有して、必要ならインタフェースのifCounterDiscontinuityTimeの値をアップデートするエージェント。 連続した投票のときに検索された対価の違いについて計算するとき、この新しいオブジェクトで、管理アプリケーションは2つの投票において、ifCounterDiscontinuityTimeの値が異なっているどんな計算された違いも捨てなければなりません。 (エージェント再初期化を検出するためにsysUpTimeの通常の点検に加えてこのテストを実行しなければならないことに注意してください。) そのような破棄がネットワークマネージメント処理と帯域幅の浪費であるので、絶対に必要でない場合、エージェントはifCounterDiscontinuityTimeの値をアップデートするべきではありません。
While defining this new object is a change in the semantics of the ifTable counter objects, it is impractical to deprecate and redefine
この新しいオブジェクトを定義するのは、ifTableカウンタオブジェクトの意味論で変化ですが、それは、非難して、再定義するために非実用的です。
McCloghrie & Kastenholz Standards Track [Page 12] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[12ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
all these counters because of their wide deployment and importance. Also, a survey of implementations indicates that many agents and management applications do not correctly implement this aspect of the current semantics (because of the burdensome issues mentioned above), such that the practical implications of such a change is small. Thus, this breach of the SMI's rules is considered to be acceptable.
それらの広い展開と重要性によるこれらのすべてのカウンタ。 また、実装の調査は、多くのエージェントと管理アプリケーションが正しく現在の意味論(前記のように重荷になっている問題による)のこの局面を実装しないのを示します、そのような変化の実用的な含意が小さいように。 したがって、SMIの規則のこの不履行が許容できると考えられます。
Note, however, that the addition of ifCounterDiscontinuityTime does not change the fact that:
しかしながら、ifCounterDiscontinuityTimeの追加が以下のことという事実を変えないことに注意してください。
it is necessary at certain times for the assignment of
ifIndex values to change on a re-initialization of the agent
(such as a reboot).
ある時に、ifIndex値の課題がエージェント(リブートなどの)の再初期化のときに変化するのが必要です。
The possibility of ifIndex value re-assignment must be accommodated by a management application whenever the value of sysUpTime is reset to zero.
sysUpTimeの値がゼロにリセットされるときはいつも、管理アプリケーションでifIndex値の再割当ての可能性を設備しなければなりません。
Note also that some agents support multiple "naming scopes", e.g., for an SNMPv1 agent, multiple values of the SNMPv1 community string. For such an agent (e.g., a CNM agent which supports a different subset of interfaces for different customers), there is no required relationship between the ifIndex values which identify interfaces in one naming scope and those which identify interfaces in another naming scope. It is the agent's choice as to whether the same or different ifIndex values identify the same or different interfaces in different naming scopes.
また、何人かのエージェントが、複数の「命名範囲」がSNMPv1共同体ストリングの例えば、SNMPv1エージェントにとって複数の値であるとサポートすることに注意してください。 そのようなエージェント(例えば、異なった顧客のためにインタフェースの異なった部分集合をサポートするCNMエージェント)のために、範囲と別の命名におけるインタフェースを特定するものを範囲と命名しながら1でインタフェースを特定するifIndex値の間のどんな必要な関係もありません。 それは同じであるか異なったifIndex値が異なった命名範囲で同じであるか異なったインタフェースを特定するかどうかに関するエージェントの選択です。
Because of the restriction of the value of ifIndex to be less than ifNumber, interfaces have been numbered with small integer values. This has led to the ability by humans to use the ifIndex values as (somewhat) user-friendly names for network interfaces (e.g., "interface number 3"). With the relaxation of the restriction on the value of ifIndex, there is now the possibility that ifIndex values could be assigned as very large numbers (e.g., memory addresses). Such numbers would be much less user-friendly. Therefore, this memo recommends that ifIndex values still be assigned as (relatively) small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous. (Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces)
ifNumberより少ないifIndexの価値の制限のために、インタフェースは小さい整数値で付番されました。 これがネットワーク・インターフェースに(いくらか)ユーザフレンドリーな名前としてifIndex値を使用する人間による能力に通じた、(例えば、「インタフェース数の3インチ)」 現在、ifIndexの値における制限の緩和と共に、非常に大きい数(例えば、メモリアドレス)としてifIndex値を割り当てることができた可能性があります。 そのような数はあまりそれほどユーザフレンドリーでないでしょう。 したがって、このメモが、ifIndex値がまだ割り当てられることを勧める、(比較的、)、わずかな整数は1時の始めを評価します、使用中の値がいかなる時も、必ず隣接であるというわけではありませんが。 (これでどの値を割り当ててあったかを覚えているのがエージェントにとって簡単になるという(ダイナミックに新しいインタフェースを加えます)メモ)
A new problem is introduced by representing each sub-layer as an ifTable entry. Previously, there usually was a simple, direct, mapping of interfaces to the physical ports on systems. This mapping would be based on the ifIndex value. However, by having an ifTable entry for each interface sub-layer, mapping from interfaces to physical ports becomes increasingly problematic.
新しい問題は、ifTableエントリーとして各副層を表すことによって、紹介されます。 以前、通常、システムの上の物理的なポートへのインタフェースの簡単で、ダイレクトなマッピングがありました。このマッピングはifIndex値に基づくでしょう。 しかしながら、それぞれのインタフェース副層のためのifTableエントリーを持っていることによって、インタフェースから物理的なポートまでのマッピングはますます問題が多くなります。
McCloghrie & Kastenholz Standards Track [Page 13] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[13ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
To address this issue, a new object, ifName, is added to the MIB. This object contains the device's local name (e.g., the name used at the device's local console) for the interface of which the relevant entry in the ifTable is a component. For example, consider a router having an interface composed of PPP running over an RS-232 port. If the router uses the name "wan1" for the (combined) interface, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would both have the value "wan1". On the other hand, if the router uses the name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 port, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would have the values "wan1.1" and "wan1.2", respectively. As an another example, consider an agent which responds to SNMP queries concerning an interface on some other (proxied) device: if such a proxied device associates a particular identifier with an interface, then it is appropriate to use this identifier as the value of the interface's ifName, since the local console in this case is that of the proxied device.
この問題を扱うために、新しいオブジェクト(ifName)はMIBに加えられます。 このオブジェクトはifTableの関連エントリーがコンポーネントであるインタフェースへのデバイスの地方名(例えばデバイスの地方のコンソールで使用される名前)を含んでいます。 例えば、RS-232ポートを中を走らせるPPPでインタフェースを構成するルータを考えてください。 ルータが名前を使用する、「(結合される)のインタフェースへのwan1"、そして、対応するPPPのためのifNameオブジェクトとifTableのRS-232エントリーには、値の"wan1""がともにあるでしょう。 そして、そして、他方では、ルータが名前を使用する、「PPPインタフェースへのwan1.1"、「RS-232ポートへのwan1.2"、次に、対応するPPPのためのifNameオブジェクトとifTableのRS-232エントリーには値があるだろう、「wan1.1"、「それぞれwan1.2"、」 別の例、SNMPに応じるエージェントがある他の(proxiedしました)デバイスの上のインタフェースに関して以下について質問すると考えてください。 そのようなproxiedデバイスが特定の識別子をインタフェースに関連づけるなら、インタフェースのifNameの値としてこの識別子を使用するのは適切です、この場合、地方のコンソールがproxiedデバイスのものであるので。
In contrast, the existing ifDescr object is intended to contain a description of an interface, whereas another new object, ifAlias, provides a location in which a network management application can store a non-volatile interface-naming value of its own choice. The ifAlias object allows a network manager to give one or more interfaces their own unique names, irrespective of any interface- stack relationship. Further, the ifAlias name is non-volatile, and thus an interface must retain its assigned ifAlias value across reboots, even if an agent chooses a new ifIndex value for the interface.
対照的に、既存のifDescrオブジェクトがインタフェースの記述を含むことを意図しますが、別の新しいオブジェクト(ifAlias)はネットワークマネージメントアプリケーションがそれ自身の選択の非揮発性のインタフェースを命名する値を保存できる位置を提供します。 ネットワークマネージャはifAliasオブジェクトでそれら自身のユニークな名前を1つ以上のインタフェースに与えることができます、どんなインタフェーススタック関係の如何にかかわらず。 さらに、ifAlias名は非不安定です、そして、その結果、インタフェースはリブートの向こう側に割り当てられたifAlias値を保有しなければなりません、エージェントがインタフェースへの新しいifIndex値を選んでも。
3.1.6. Counter Size
3.1.6. カウンタサイズ
As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, a 10Mbs stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that interfaces be polled frequently enough not to miss a counter wrap is increasingly problematic.
ネットワークメディア増加の速度、最小の時間として32ビットのカウンタが減少を包装する。 例えば、背中合わせのフルサイズパケットの10Mbsの流れはちょうど57分以上後に包装へのifInOctetsを引き起こします。 100Mbsでは、最小の包装時間は5.7分です、そして、1Gbsでは、最小限は34秒です。 インタフェースがカウンタ包装をなくすことができないくらいの頻繁に投票されるのが必要であるのはますます問題が多いです。
A rejected solution to this problem was to scale the counters; for example, ifInOctets could be changed to count received octets in, say, 1024 byte blocks. While it would provide acceptable functionality at high rates of the counted-events, at low rates it suffers. If there is little traffic on an interface, there might be a significant interval before enough of the counted-events occur to cause the scaled counter to be incremented. Traffic would then appear to be very bursty, leading to incorrect conclusions of the network's performance.
この問題への拒絶された解決はカウンタをスケーリングすることでした。 例えば、中、たとえば、1024年のバイトが妨げる容認された八重奏を数えるためにifInOctetsを変えることができました。 数えられたイベントの高い率で許容できる機能性を提供するでしょうが、低率では、それに苦しみます。 トラフィックがインタフェースにほとんどなければ、スケーリングされたカウンタが増加されることを引き起こすことができるくらい数えられたイベントが起こる前に重要な間隔があるかもしれません。 そして、ネットワークの性能の不正確な結末に通じて、トラフィックはまさしくそのburstyであるように見えるでしょう。
McCloghrie & Kastenholz Standards Track [Page 14] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[14ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
Instead, this memo adopts expanded, 64 bit, counters. These counters are provided in new "high capacity" groups. The old, 32-bit, counters have not been deprecated. The 64-bit counters are to be used only when the 32-bit counters do not provide enough capacity; that is, when the 32 bit counters could wrap too fast.
代わりに、このメモが採用する、広げられて、64は、噛み付いて、反対します。 新しい「高容量」グループにこれらのカウンタを提供します。 古くて、32ビットのカウンタは推奨しなくはありません。 32ビットのカウンタが十分な容量を提供しないときだけ、64ビットのカウンタは使用されていることになっています。 すなわち、32に噛み付いたとき、カウンタはあまりに速く包装されることができました。
For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported.
2000万で作動するインタフェースに関しては、(2000万)bpsか、より少なくて、32ビットのバイトとパケットカウンタをサポートしなければなりません。 2000万より速く6億5000万ビット/秒よりビット/2番目で、遅い状態で作動するインタフェースに関しては、32ビットのパケットカウンタをサポートしなければなりません、そして、64ビットの八重奏カウンタをサポートしなければなりません。 6億5000万ビット/秒か、より速く作動するインタフェースに関しては、64ビットのパケットカウンタと64ビットの八重奏カウンタをサポートしなければなりません。
These speed thresholds were chosen as reasonable compromises based on the following:
これらの速度敷居は以下に基づく妥当な感染として選ばれました:
(1) The cost of maintaining 64-bit counters is relatively high, so
minimizing the number of agents which must support them is
desirable. Common interfaces (such as 10Mbs Ethernet) should
not require them.
(1) 64ビットのカウンタを維持する費用が比較的高いので、彼らをサポートしなければならないエージェントの数を最小にするのは望ましいです。 一般的なインタフェース(10Mbsイーサネットなどの)はそれらを必要とするべきではありません。
(2) 64-bit counters are a new feature, introduced in the SMIv2. It
is reasonable to expect that support for them will be spotty
for the immediate future. Thus, we wish to limit them to as
few systems as possible. This, in effect, means that 64-bit
counters should be limited to higher speed interfaces.
Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are
fairly wide-spread so it seems reasonable to not require 64-bit
counters for these interfaces.
(2) 64ビットのカウンタはSMIv2で導入された新機能です。 それらのサポートが即座の未来にまだらになると予想するのは妥当です。 したがって、できるだけわずかしかそれらをシステムに制限したいと思いません。 有効なこれは、64ビットのカウンタが、より高い速度インタフェースに制限されるべきであることを意味します。 イーサネット(1000万ビーピーエス)とToken Ring(1600万ビーピーエス)がかなり広範囲であるので、64ビットのカウンタをこれらのインタフェースに必要としないのは妥当に思えます。
(3) The 32-bit octet counters will wrap in the following times, for
the following interfaces (when transmitting maximum-sized
packets back-to-back):
(3) カウンタが以下の時代に以下のために包装する32ビットの八重奏が連結する、(最大サイズのパケットを伝える、背中合わせである、)、:
- 10Mbs Ethernet: 57 minutes,
- 10mbのイーサネット: 57分
- 16Mbs Token Ring: 36 minutes,
- 16mbのトークンリング: 36分
- a US T3 line (45 megabits): 12 minutes,
- US T3系列(45のメガビット): 12分
- FDDI: 5.7 minutes
- FDDI: 5.7分
(4) The 32-bit packet counters wrap in about 57 minutes when 64-
byte packets are transmitted back-to-back on a 650,000,000
bit/second link.
(4) 32ビットのパケットは64バイトパケットが6億5000万ビット/秒のリンクの上に背中合わせの状態で伝えられるおよそ57分後に包装を打ち返します。
McCloghrie & Kastenholz Standards Track [Page 15] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[15ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit octet counter to wrap in just under 5 years. Conversely, an 81,000,000 terabit/second link is required to cause a 64-bit counter to wrap in 30 minutes. We believe that, while technology rapidly marches forward, this link speed will not be achieved for at least several years, leaving sufficient time to evaluate the introduction of 96 bit counters.
余談、2(1,000Gbs)番目のリンクが引き起こす1テラビット/として、a64はちょうど5年未満後に包装する八重奏カウンタに噛み付きました。 逆に、テラビット/第2リンクが64ビットを引き起こしていなければならない8100万は30分後に包装に反対します。 私たちは、このリンク速度が少なくとも数年間達成されないと技術が急速に前進している間、信じています、96ビットの挿入を評価できるくらいの時間をカウンタに発って。
When 64-bit counters are in use, the 32-bit counters MUST still be available. They will report the low 32-bits of the associated 64-bit count (e.g., ifInOctets will report the least significant 32 bits of ifHCInOctets). This enhances inter-operability with existing implementations at a very minimal cost to agents.
64ビットのカウンタが使用中であるときに、32ビットのカウンタはまだ利用可能でなければなりません。 彼らは関連64ビットのカウントの低32ビットを報告するでしょう(例えば、ifInOctetsはifHCInOctetsの最も重要でない32ビットを報告するでしょう)。 これはエージェントへの非常に最小量の費用における既存の実装で相互運用性を高めます。
The new "high capacity" groups are:
新しい「高容量」グループは以下の通りです。
(1) the ifHCFixedLengthGroup for character-oriented/fixed-length
interfaces, and the ifHCPacketGroup for packet-based
interfaces; both of these groups include 64 bit counters for
octets, and
(1) キャラクタ指向の、または、固定長さのインタフェースへのifHCFixedLengthGroup、およびパケットベースのインタフェースへのifHCPacketGroup。 そしてこれらのグループの両方が八重奏のための64ビットのカウンタを含んでいる。
(2) the ifVHCPacketGroup for packet-based interfaces; this group
includes 64 bit counters for octets and packets.
(2) パケットベースのインタフェースへのifVHCPacketGroup。 このグループは八重奏とパケットのための64ビットのカウンタを含んでいます。
3.1.7. Interface Speed
3.1.7. インタフェース速度
Network speeds are increasing. The range of ifSpeed is limited to reporting a maximum speed of (2**31)-1 bits/second, or approximately 2.2Gbs. SONET defines an OC-48 interface, which is defined at operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, and this memo defines an additional object: ifHighSpeed.
ネットワーク速度は上がっています。 ifSpeedの範囲は(2**31)の最高回転数に-1ビット/秒、またはおよそ2.2Gbsを報告するのに制限されます。 SonetはOC-48インタフェースを定義します。(それは、48掛ける51Mbsで作動すると定義されます)。(Mbsは2.4Gbsを超えた速度です)。 したがって、ifSpeedは未来に不十分です、そして、このメモは追加オブジェクトを定義します: ifHighSpeed。
The ifHighSpeed object reports the speed of the interface in 1,000,000 (1 million) bits/second units. Thus, the true speed of the interface will be the value reported by this object, plus or minus 500,000 bits/second.
ifHighSpeedオブジェクトは100万(100万)ビット/の2番目のユニットのインタフェースの速度を報告します。 したがって、インタフェースの真の速度はこのオブジェクト、または、50万ビット/秒およびを引いて報告された値になるでしょう。
Other alternatives considered (but rejected) were:
考えられた(しかし、拒絶されます)他の代替手段は以下の通りでした。
(1) Making the interface speed a 64-bit gauge. This was rejected
since the current SMI does not allow such a syntax.
(1) インタフェースを作って、64ビットのゲージを促進してください。 現在のSMIがそのような構文を許容しないので、これは拒絶されました。
Furthermore, even if 64-bit gauges were available, their use would
require additional complexity in agents due to an increased
requirement for 64-bit operations.
その上、64ビットのゲージが利用可能であったとしても、彼らの使用は64ビット演算のための増強された要件のためエージェントで追加複雑さを必要とするでしょうに。
McCloghrie & Kastenholz Standards Track [Page 16] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[16ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
(2) We also considered making "high-32 bit" and "low-32-bit"
objects which, when combined, would be a 64-bit value. This
simply seemed overly complex for what we are trying to do.
(2) また、私たちは、「高値-32ビット」と「低32ビット」を結合されると64ビットの値であるオブジェクトにすると考えました。 これは単に私たちがしようとしていることにひどく複雑に見えました。
Furthermore, a full 64-bits of precision does not seem necessary.
The value of ifHighSpeed will be the only report of interface
speed for interfaces that are faster than 4,294,967,295 bits per
second. At this speed, the granularity of ifHighSpeed will be
1,000,000 bits per second, thus the error will be 1/4294, or about
0.02%. This seems reasonable.
その上、精度の完全な64ビットは必要に見えません。 ifHighSpeedの値は42億9496万7295のbpsより速いインタフェースへのインタフェース速度の唯一のレポートになるでしょう。 この速度では、ifHighSpeedの粒状が100万のbpsになる、その結果、誤りは、1/4294か、およそ0.02%になるでしょう。 これは妥当に思えます。
(3) Adding a "scale" object, which would define the units which
ifSpeed's value is.
(3) 「スケール」オブジェクトを加えること。(それは、ifSpeedの値がそうであるユニットを定義するでしょう)。
This would require two additional objects; one for the scaling
object, and one to replace the current ifSpeed. This later object
is required since the semantics of ifSpeed would be significantly
altered, and manager stations which do not understand the new
semantics would be confused.
これは2個の追加オブジェクトを必要とするでしょう。 スケーリングオブジェクト、および現在のifSpeedを取り替える1のためのもの。 ifSpeedの意味論はかなり変更されるでしょう、そして、新しい意味論を理解していないマネージャステーションが混乱するでしょう、したがって、この後のオブジェクトが必要です。
3.1.8. Multicast/Broadcast Counters
3.1.8. マルチキャスト/放送カウンタ
In MIB-II, the ifTable counters for multicast and broadcast packets are combined as counters of non-unicast packets. In contrast, the ifExtensions MIB [19] defined one set of counters for multicast, and a separate set for broadcast packets. With the separate counters, the original combined counters become redundant. To avoid this redundancy, the non-unicast counters are deprecated.
MIB-IIでは、マルチキャストと放送パケットのためのifTableカウンタは非ユニキャストパケットのカウンタとして結合されます。 対照的に、ifExtensions MIB[19]はマルチキャストのための1セットのカウンタ、および放送パケットのための別々のセットを定義しました。 別々のカウンタで、元の結合したカウンタは余分になります。 この冗長を避けるために、非ユニキャストカウンタは推奨しないです。
For the output broadcast and multicast counters defined in RFC 1229, their definitions varied slightly from the packet counters in the ifTable, in that they did not count errors/discarded packets. Thus, this memo defines new objects with better aligned definitions. Counters with 64 bits of range are also needed, as explained above.
RFC1229で定義された出力放送とマルチキャストカウンタに関しては、彼らの定義はifTableのパケットカウンタからわずかに変わりました、彼らが誤り/捨てられたパケットを数えなかったので。 したがって、このメモは、よりよく並べられた定義で新しいオブジェクトを定義します。 また、範囲の64ビットがあるカウンタが上で説明されるように必要です。
3.1.9. Trap Enable
3.1.9. 罠は可能にします。
In the multi-layer interface model, each sub-layer for which there is an entry in the ifTable can generate linkUp/linkDown Traps. Since interface state changes would tend to propagate through the interface (from top to bottom, or bottom to top), it is likely that several traps would be generated for each linkUp/linkDown occurrence.
マルチ層のインタフェースモデルでは、エントリーがifTableにある各副層はlinkUp/linkDown Trapsを生成することができます。 界面準位変化は、インタフェース(付ける下部、または先端から下部までの)を通して伝播する傾向があるでしょう、したがって、いくつかの罠がそれぞれのlinkUp/linkDown発生のために生成されそうでしょう。
It is desirable to provide a mechanism for manager stations to control the generation of these traps. To this end, the ifLinkUpDownTrapEnable object has been added. This object allows managers to limit generation of traps to just the sub-layers of interest.
マネージャステーションがこれらの罠の世代を制御するようにメカニズムを提供するのは望ましいです。 このために、ifLinkUpDownTrapEnableオブジェクトは加えられます。 このオブジェクトで、マネージャは罠の世代をまさしく興味がある副層に制限できます。
McCloghrie & Kastenholz Standards Track [Page 17] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[17ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
The default setting should limit the number of traps generated to one per interface per linkUp/linkDown event. Furthermore, it seems that the state changes of most interest to network managers occur at the lowest level of an interface stack. Therefore we specify that by default, only the lowest sub-layer of the interface generate traps.
既定の設定はlinkUp/linkDownイベント単位で1インタフェースあたり1つに生成された罠の数を制限するはずです。 その上、ほとんどの関心のネットワークマネージャへの州の変化がインタフェーススタックの最も低いレベルで起こるように思えます。 したがって、私たちは、デフォルトで、インタフェースの最も低い副層だけが罠を生成すると指定します。
3.1.10. Addition of New ifType values
3.1.10. New ifType値の追加
Over time, there is the need to add new ifType enumerated values for new interface types. If the syntax of ifType were defined in the MIB in section 6, then a new version of this MIB would have to be re- issued in order to define new values. In the past, re-issuing of a MIB has occurred only after several years.
時間がたつにつれて、新しいifTypeが新しいインターフェース型のために値を列挙したと言い足す必要があります。 セクション6のMIBでifTypeの構文を定義するなら、新しい値を定義するためにこのMIBの新しいバージョンを再発行しなければならないでしょうに。 過去に、MIBの再発行は数年後にだけ起こりました。
Therefore, the syntax of ifType is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention, IANAifType, defined in a different document. This allows additional values to be documented without having to re-issue a new version of this document. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new ifType values.
したがって、原文のコンベンションになるようにifTypeの構文を変えます、列挙された整数値が現在原文のコンベンション、異なったドキュメントで定義されたIANAifTypeで定義されるように。 これは、加算値がこのドキュメントの新しいバージョンを再発行する必要はなくて記録されるのを許容します。 ISOCの機関の一つで(IANA)はすべてのインターネット番号の課題に責任があります、様々なSNMP関連の数、および明確に新しいifType値を含んでいて。
3.1.11. InterfaceIndex Textual Convention
3.1.11. InterfaceIndexの原文のコンベンション
A new textual convention, InterfaceIndex, has been defined. This textual convention "contains" all of the semantics of the ifIndex object. This allows other MIB modules to easily import the semantics of ifIndex.
新しい原文のコンベンション(InterfaceIndex)は定義されました。 この原文のコンベンションはifIndexオブジェクトの意味論のすべてを「含みます」。 これで、他のMIBモジュールは容易にifIndexの意味論を意味できます。
3.1.12. New states for IfOperStatus
3.1.12. IfOperStatusのための新しい州
Three new states have been added to ifOperStatus: 'dormant', 'notPresent', and 'lowerLayerDown'.
3つの新しい州がifOperStatusに加えられます: '眠っている'、'notPresent'、および'lowerLayerDown'。
The dormant state indicates that the relevant interface is not actually in a condition to pass packets (i.e., it is not 'up') but is in a "pending" state, waiting for some external event. For "on- demand" interfaces, this new state identifies the situation where the interface is waiting for events to place it in the up state. Examples of such events might be:
休止状態の州は、関連インタフェースがパケット(すなわち、それは'up'でない)を通過する実際に状態でありませんが、「未定」の状態にあるのを示します、何らかの外部のイベントを待っていて。 「オンである、」 インタフェースであり、この新しい州がインタフェースが待っている状況を特定するのを要求して、イベントは上の状態にそれを置いてください。 そのようなイベントに関する例は以下の通りです。
(1) having packets to transmit before establishing a connection to
a remote system;
(1) リモートシステムに取引関係を築く前に伝えるパケットを持っています。
(2) having a remote system establish a connection to the interface
(e.g. dialing up to a slip-server).
(2) リモートシステムを持っていて、インタフェース(例えば、メモ用紙サーバまでのダイヤルする)に取引関係を築いてください。
McCloghrie & Kastenholz Standards Track [Page 18] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[18ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
The notPresent state is a refinement on the down state which indicates that the relevant interface is down specifically because some component (typically, a hardware component) is not present in the managed system. Examples of use of the notPresent state are:
notPresent状態は特に何らかのコンポーネント(通常ハードウェアの部品)が管理されたシステムに存在していないので関連インタフェースが下がっているのを示す下に州における気品です。 notPresent状態で役に立つ例は以下の通りです。
(1) to allow an interface's conceptual row including its counter
values to be retained across a "hot swap" of a card/module,
and/or
そして/または対価を含むインタフェースの概念的な行がカード/モジュールの「ホットスワップ」の向こう側に保有されるのを許容する(1)。
(2) to allow an interface's conceptual row to be created, and
thereby enable interfaces to be pre-configured prior to
installation of the hardware needed to make the interface
operational.
(2) インタフェースの概念的な行が作成されるのを許容して、その結果、インタフェースを可能にするために、ハードウェアのインストールの前にあらかじめ設定されるのは、インタフェースを操作上にする必要がありました。
Agents are not required to support interfaces in the notPresent state. However, from a conceptual viewpoint, when a row in the ifTable is created, it first enters the notPresent state and then subsequently transitions into the down state; similarly, when a row in the ifTable is deleted, it first enters the notPresent state and then subsequently the object instances are deleted. For an agent with no support for notPresent, both of these transitions (from the notPresent state to the down state, and from the notPresent state to the instances being removed) are immediate, i.e., the transition does not last long enough to be recorded by ifOperStatus. Even for those agents which do support interfaces in the notPresent state, the length of time and conditions under which an interface stays in the notPresent state is implementation-specific.
エージェントはnotPresent状態でインタフェースをサポートする必要はありません。 しかしながら、概念的な観点から、ifTableの行が作成されるとき、最初に、州と次に、次に下への変遷が述べるnotPresentに入ります。 ifTableの行が削除されるとき、同様に、最初にnotPresent状態に入れます、そして、次に、次にオブジェクトインスタンスは削除されます。 notPresentのサポートのないエージェントにとって、これらの変遷(notPresent状態から下に州までnotPresent状態から取り除かれるインスタンスまでの)の両方が即座である、すなわち、変遷はifOperStatusが記録できるくらいの長い間、続きません。 notPresent状態でインタフェースをサポートするそれらのエージェントにとってさえ、インタフェースがnotPresent状態にいる時間と状態の長さは実装特有です。
The lowerLayerDown state is also a refinement on the down state. This new state indicates that this interface runs "on top of" one or more other interfaces (see ifStackTable) and that this interface is down specifically because one or more of these lower-layer interfaces are down.
また、lowerLayerDown状態は下に状態における気品です。 この新しい州はこのインタフェースが他の1つ以上のインタフェース「上」で稼働していて(ifStackTableを見てください)、特にこれらの下層インタフェースの1つ以上が下がっているのでこのインタフェースが下がっているのを示します。
3.1.13. IfAdminStatus and IfOperStatus
3.1.13. IfAdminStatusとIfOperStatus
The down state of ifOperStatus now has two meanings, depending on the value of ifAdminStatus.
ifOperStatusの下に州には、ifAdminStatusの値によって、現在、2つの意味があります。
(1) if ifAdminStatus is not down and ifOperStatus is down then a
fault condition is presumed to exist on the interface.
(1) ifAdminStatusが下がっていなくて、ifOperStatusが下がっているなら、欠点状態はあえてインタフェースに存在しています。
(2) if ifAdminStatus is down, then ifOperStatus will normally also
be down (or notPresent) i.e., there is not (necessarily) a
fault condition on the interface.
また、(2) ifAdminStatusが下がっていると、通常、ifOperStatusも下がるでしょう(または、notPresent)、すなわち、(必ず)欠点状態がインタフェースにありません。
Note that when ifAdminStatus transitions to down, ifOperStatus will normally also transition to down. In this situation, it is possible
また、ifAdminStatusがダウンするように移行するとき通常、ifOperStatusがダウンするように移行することに注意してください。 この状況で、それは可能です。
McCloghrie & Kastenholz Standards Track [Page 19] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[19ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
that ifOperStatus's transition will not occur immediately, but rather after a small time lag to complete certain operations before going "down"; for example, it might need to finish transmitting a packet. If a manager station finds that ifAdminStatus is down and ifOperStatus is not down for a particular interface, the manager station should wait a short while and check again. If the condition still exists, only then should it raise an error indication. Naturally, it should also ensure that ifLastChange has not changed during this interval.
そのifOperStatusの変遷はすぐに、しかし、むしろ小さいタイムラグの後に現在の“down"の前で、ある操作を完了するために起こらないでしょう。 例えば、それは、パケットを伝え終える必要があるかもしれません。 マネージャステーションが、ifAdminStatusが下がっているのがわかって、特定のインタフェースにifOperStatusがないなら、マネージャステーションは、少しの間待っていて、再びチェックするべきです。 状態がまだ存在しているなら、それは誤り表示を上げるだけであるべきです。 また、当然、それは、ifLastChangeがこの間隔の間変化していないのを確実にします。
Whenever an interface table entry is created (usually as a result of system initialization), the relevant instance of ifAdminStatus is set to down, and ifOperStatus will be down or notPresent.
ifOperStatusはインタフェーステーブルエントリーが作成される(通常システム初期化の結果、)ときはいつも、ifAdminStatusの関連インスタンスがダウンするように設定されて、下にかnotPresentになるでしょう。
An interface may be enabled in two ways: either as a result of explicit management action (e.g. setting ifAdminStatus to up) or as a result of the managed system's initialization process. When ifAdminStatus changes to the up state, the related ifOperStatus should do one of the following:
インタフェースは2つの方法で可能にされるかもしれません: 明白な管理活動(例えば、ifAdminStatusに上昇するように設定する)の結果、管理されたシステムの初期化の結果、処理してください。 上がることへの変化が述べるifAdminStatus、関連するifOperStatusがそうするべきであるとき、以下の1つをしてください:
(1) Change to the up state if and only if the interface is able to
send and receive packets.
そして、(1) 上の状態に変えてください、インタフェースがパケットを送って、受けることができる場合にだけ。
(2) Change to the lowerLayerDown state if and only if the interface
is prevented from entering the up state because of the state of
one or more of the interfaces beneath it in the interface
stack.
そして、(2) lowerLayerDown状態に変えてください、インタフェースがインタフェースの1つ以上の状態のためにインタフェースでそれの下で上の状態に入るのが防がれる場合にだけ、積み重ねてください。
(3) Change to the dormant state if and only if the interface is
found to be operable, but the interface is waiting for other,
external, events to occur before it can transmit or receive
packets. Presumably when the expected events occur, the
interface will then change to the up state.
(3) 休止状態の状態に変化してください、単に、インタフェースは手術可能であることがわかっていますが、インタフェースはもう一方、外部(パケットを伝えるか、または受けることができる前に起こるイベント)を待っています。 おそらく、予想されたイベントが起こると、インタフェースは上がることへの変化が述べるその時が起こるでしょう。
(4) Remain in the down state if an error or other fault condition
is detected on the interface.
(4) 誤りか他の欠点状態がインタフェースに検出されるなら、下に州に残ってください。
(5) Change to the unknown state if, for some reason, the state of
the interface can not be ascertained.
(5) ある理由で、インタフェースの状態を確かめることができないかどうかを未知の状態に変えてください。
(6) Change to the testing state if some test(s) must be performed
on the interface. Presumably after completion of the test, the
interface's state will change to up, dormant, or down, as
appropriate.
(6) インタフェースに何らかのテストを実行しなければならないかどうかをテスト状態に変えてください。 おそらくテストの完成の後に、州が変化するインタフェースは、上がる、眠る、または下がっていて、適切です。
(7) Remain in the notPresent state if interface components are
missing.
(7) インタフェースコンポーネントがなくなるなら、notPresent州に残ってください。
McCloghrie & Kastenholz Standards Track [Page 20] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[20ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
3.1.14. IfOperStatus in an Interface Stack
3.1.14. インタフェーススタックのIfOperStatus
When an interface is a part of an interface-stack, but is not the lowest interface in the stack, then:
次に、インタフェースがインタフェーススタックの一部ですが、スタックで最も低いインタフェースでないときに:
(1) ifOperStatus has the value 'up' if it is able to pass packets
due to one or more interfaces below it in the stack being 'up',
irrespective of whether other interfaces below it are 'down', '
dormant', 'notPresent', 'lowerLayerDown', 'unknown' or '
testing'.
(1) ifOperStatusには、1つ以上のインタフェースのためそれの下の他のインタフェースが'down'であるかどうかの如何にかかわらず'眠っている''up'、'notPresent'、'lowerLayerDown'、'未知'または'テストであり'ながらスタックでそれの下にパケットを通過できるなら、値の'up'があります。
(2) ifOperStatus may have the value 'up' or 'dormant' if one or
more interfaces below it in the stack are 'dormant', and all
others below it are either 'down', 'dormant', 'notPresent', '
lowerLayerDown', 'unknown' or 'testing'.
(2) スタックのそれの下の1つ以上のインタフェースが'眠ってい'て、それの下のすべての他のものが'down'、'眠っている''notPresent'、'lowerLayerDown''未知'であるか'テストする'なら、ifOperStatusは'up'か'眠ること'に値を持っているかもしれません。
(3) ifOperStatus has the value 'lowerLayerDown' while all
interfaces below it in the stack are either 'down', '
notPresent', 'lowerLayerDown', or 'testing'.
(3) ifOperStatusには、スタックのそれの下のすべてのインタフェースが、'down'、'notPresent'、'lowerLayerDown'、または'テスト'ですが、値の'lowerLayerDown'があります。
3.1.15. Traps
3.1.15. 罠
The exact definition of when linkUp and linkDown traps are generated has been changed to reflect the changes to ifAdminStatus and ifOperStatus. Operational experience indicates that management stations are most concerned with an interface being in the down state and the fact that this state may indicate a failure. Thus, it is most useful to instrument transitions into/out of either the up state or the down state.
ifAdminStatusとifOperStatusへの変化を反映するためにlinkUpとlinkDown罠が発生している時に関する正確な定義を変えました。 運用経験は、管理局は下に状態にあるインタフェースとこの州が失敗を示すかもしれないという事実に最も関係があるのを示します。 したがって、それは上がるのが述べるどちらかからの/への変遷か下であるのが述べる器具の最も役に立ちます。
Instrumenting transitions into or out of the up state was rejected since it would have the drawback that a demand interface might have many transitions between up and dormant, leading to many linkUp traps and no linkDown traps. Furthermore, if a node's only interface is the demand interface, then a transition to dormant would entail generation of a linkDown trap, necessitating bringing the link to the up state (and a linkUp trap)!!
それには、要求インタフェースが間に上がって眠っていた状態で移行して、多くのlinkUp罠にもかかわらず、どんなlinkDown罠にも通じないことで多くにするかもしれない欠点があるでしょう、したがって、状態の中、または、上の状態から変遷に器具を取り付けるのは拒絶されました。 その上、眠っていることへの変遷はノードの唯一のインタフェースが要求インタフェースであるならlinkDown罠の世代を伴うでしょう、状態(そして、linkUp罠)を上がることへのリンクに持って来るのを必要として!
On the other hand, instrumenting transitions into or out of the down state (to/from all other states except notPresent) has the advantages:
他方では、州(notPresent以外の他のすべての州からの/への)には、下に中、または、下であるから変遷に器具を取り付けて、利点があります:
(1) A transition into the down state (from a state other than
notPresent) will occur when an error is detected on an
interface. Error conditions are presumably of great interest
to network managers.
(1) 誤りがインタフェースに検出されるとき、下に状態(notPresent以外の状態からの)への変遷は起こるでしょう。 おそらく、エラー条件はすごくネットワークマネージャにおもしろいです。
McCloghrie & Kastenholz Standards Track [Page 21] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[21ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
(2) Departing the down state (to a state other than the notPresent
state) generally indicates that the interface is going to
either up or dormant, both of which are considered "healthy"
states.
(2) 一般に、どれが「健康な」州であるとともに考えられるかについて下に状態(notPresent状態以外の状態への)を退職するのは、インタフェースが上がるか、または眠っていた状態でそうするのを示します。
Furthermore, it is believed that generating traps on transitions into or out of the down state (except to/from the notPresent state) is generally consistent with current usage and interpretation of these traps by manager stations.
その上、変遷のときに下に中、または、下であるから罠を生成して、一般に、状態(notPresent状態からの/を除いた)がマネージャステーションによるこれらの罠の現在の用法と解釈と一致していると信じられています。
Transitions to/from the notPresent state are concerned with the insertion and removal of hardware, and are outside the scope of these traps.
notPresent状態からの/への変遷は、ハードウェアの挿入と取り外しに関係があって、これらの罠の範囲の外にあります。
Therefore, this memo defines that LinkUp and linkDown traps are generated just after ifOperStatus leaves, or just before it enters, the down state, respectively; except that LinkUp and linkDown traps are never generated on transitions to/from the notPresent state. For the purpose of deciding when these traps occur, the lowerLayerDown state and the down state are considered to be equivalent, i.e., there is no trap on transition from lowerLayerDown into down, and there is a trap on transition from any other state except down (and notPresent) into lowerLayerDown.
したがって、このメモはそのLinkUpを定義します、そして、ifOperStatusがいなくなるか、ちょうど以前入って、または下であるのが状態になったすぐ後にlinkDown罠はそれぞれ発生しています。 そのLinkUpとlinkDown以外に、罠はnotPresent状態からの/への変遷のときに決して生成されません。 すなわち、罠は全くlowerLayerDownから変遷で下に来ていません、そして、これらの罠がいつ起こるかを決める目的のために、lowerLayerDown州と下に状態を相当させていると考えられて、罠は下にであること以外のいかなる他の状態(そして、notPresent)からも変遷でlowerLayerDownに来ています。
Note that this definition allows a node with only one interface to transmit a linkDown trap before that interface goes down. (Of course, when the interface is going down because of a failure condition, the linkDown trap probably cannot be successfully transmitted anyway.)
そのインタフェースが落ちる前に1つのインタフェースだけがあるノードがこの定義でlinkDown罠を伝えることができることに注意してください。 (もちろん、インタフェースが失敗状態のために落ちる予定であるとき、たぶん首尾よくとにかくlinkDown罠を伝えることができません。)
Some interfaces perform a link "training" function when trying to bring the interface up. In the event that such an interface were defective, then the training function would fail and the interface would remain down, and the training function might be repeated at appropriate intervals. If the interface, while performing this training function, were considered to the in the testing state, then linkUp and linkDown traps would be generated for each start and end of the training function. This is not the intent of the linkUp and linkDown traps, and therefore, while performing such a training function, the interface's state should be represented as down.
インタフェースを持って来ようとするとき、いくつかのインタフェースがリンク「トレーニング」機能を実行します。 そのようなインタフェースは欠陥がある場合、次に、トレーニング機能が失敗するでしょうに、そして、インタフェースは下にのままで残っているでしょう、そして、トレーニング機能は適切な間隔で、繰り返されるかもしれません。 インタフェースがこのトレーニング機能を実行している間、コネと考えられるなら、テスト状態、当時のlinkUp、およびlinkDown罠はトレーニング機能の各始めと終わりに生成されるでしょうに。 これはlinkUpとlinkDown罠の意図ではありません、そして、したがって、そのようなトレーニング機能を実行している間、インタフェースの状態は下にとして表されるべきです。
An exception to the above generation of linkUp/linkDown traps on changes in ifOperStatus, occurs when an interface is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps.
linkUp/linkDownの上の世代への例外は、ifOperStatusにおける変化の上で捕らえて、インタフェースが「ばたついている」とき、起こります、すなわち、急速に上下の州の間を揺れているとき。 罠がそのような各振動のために生成されるなら、ネットワークとネットワーク管理システムは不要な罠で水につかっているでしょうに。 そのような状況で、エージェントはそれが罠を生成するレートを制限するべきです。
McCloghrie & Kastenholz Standards Track [Page 22] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[22ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
3.1.16. ifSpecific
3.1.16. ifSpecific
The original definition of the OBJECT IDENTIFIER value of ifSpecific
was not sufficiently clear. As a result, different implementors used
it differently, and confusion resulted. Some implementations set the
value of ifSpecific to the OBJECT IDENTIFIER that defines the media-
specific MIB, i.e., the "foo" of:
foo OBJECT IDENTIFIER ::= { transmission xxx }
ifSpecificのOBJECT IDENTIFIER価値のオリジナルの定義は十分明確ではありませんでした。 その結果、異なった作成者はそれを異なって使用しました、そして、混乱は結果として生じました。 いくつかの実装が以下のメディアすなわち、特定のMIB、"foo"を定義するOBJECT IDENTIFIERにifSpecificの値を設定します。 foo OBJECT IDENTIFIER:、:= トランスミッションxxx
while others set it to be OBJECT IDENTIFIER of the specific table or entry in the appropriate media-specific MIB (i.e., fooTable or fooEntry), while still others set it be the OBJECT IDENTIFIER of the index object of the table's row, including instance identifier, (i.e., fooIfIndex.ifIndex). A definition based on the latter would not be sufficient unless it also allowed for media-specific MIBs which include several tables, where each table has its own (different) indexing.
他のものは、適切なメディア特有のMIB(すなわち、fooTableかfooEntry)にそれに特定のテーブルかエントリーのOBJECT IDENTIFIERであるように設定しますが、それでも、他のものがそれを設定する間のテーブルの行のインデックスオブジェクトのOBJECT IDENTIFIERになってください、インスタンス識別子(すなわち、fooIfIndex.ifIndex)を含んでいて また、各テーブルがそれ自身の(異なる)のインデックスを持っている数個のテーブルを含んでいるメディア特有のMIBsを考慮しない場合、後者に基づく定義は十分でないでしょうに。
The only definition that can both be made explicit and can cover all the useful situations is to have ifSpecific be the most general value for the media-specific MIB module (the first example given above). This effectively makes it redundant because it contains no more information than is provided by ifType. Thus, ifSpecific has been deprecated.
明白に作ることができて、すべての役に立つ状況をカバーできる唯一の定義はifSpecificがメディア特有のMIBモジュール(上に出された最初の例)のための最も一般的な値であることを持つことです。 これで、ifTypeによって提供されるより多くの情報を含んでいないので、事実上、それは余分になります。 したがって、ifSpecificは推奨しないです。
3.1.17. Creation/Deletion of Interfaces
3.1.17. インタフェースの作成/削除
While some interfaces, for example, most physical interfaces, cannot be created via network management, other interfaces such as logical interfaces sometimes can be. The ifTable contains only generic information about an interface. Almost all 'create-able' interfaces have other, media-specific, information through which configuration parameters may be supplied prior to creating such an interface. Thus, the ifTable does not itself support the creation or deletion of an interface (specifically, it has no RowStatus [6] column). Rather, if a particular interface type supports the dynamic creation and/or deletion of an interface of that type, then that media-specific MIB should include an appropriate RowStatus object (see the ATM LAN- Emulation Client MIB [20] for an example of a MIB which does this). Typically, when such a RowStatus object is created/deleted, then the conceptual row in the ifTable appears/disappears as a by-product, and an ifIndex value (chosen by the agent) is stored in an appropriate object in the media-specific MIB.
ネットワークマネージメントでいくつかのインタフェース(例えば、ほとんどの物理インターフェース)を作成できませんが、論理的なインタフェースなどの他のインタフェースは時々作成できます。 ifTableはインタフェースのジェネリック情報だけを含んでいます。 ほとんどすべての'作成できる'インタフェースには、そのようなインタフェースを作成する前に設定パラメータが提供されるかもしれない他の、そして、メディア特有の情報があります。 したがって、ifTableはインタフェースの作成か削除をどんなサポート自体にもしません(明確に、それには、RowStatus[6]コラムが全くありません)。 むしろ、特定のインターフェース型がそのタイプのインタフェースのダイナミックな作成、そして/または、削除をサポートするなら、そのメディア特有のMIBは適切なRowStatusオブジェクトを含んでいるはずです(これをするMIBの例に関してATM LANエミュレーションClient MIB[20]を見てください)。 通常、作成されるか削除されています、次に、ifTableの概念的な行が/に見えるというそのようなRowStatusが、反対することであるいつが副産物として見えなくなるか、そして、ifIndex値(エージェントによって選ばれている)はメディア特有のMIBの適切なオブジェクトに保存されます。
McCloghrie & Kastenholz Standards Track [Page 23] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[23ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
3.1.18. All Values Must be Known
3.1.18. すべてのValues Must、Knownになってください。
There are a number of situations where an agent does not know the value of one or more objects for a particular interface. In all such circumstances, an agent MUST NOT instantiate an object with an incorrect value; rather, it MUST respond with the appropriate error/exception condition (e.g., noSuchInstance or noSuchName).
多くの状況がエージェントが1個以上のオブジェクトの値を特定のインタフェースに知らないところにあります。 そのようなすべての事情では、エージェントは不正確な値でオブジェクトを例示してはいけません。 むしろ、それは適切な誤り/例外条件(例えば、noSuchInstanceかnoSuchName)で応じなければなりません。
One example is where an agent is unable to count the occurrences defined by one (or more) of the ifTable counters. In this circumstance, the agent MUST NOT instantiate the particular counter with a value of, say, zero. To do so would be to provide mis- information to a network management application reading the zero value, and thereby assuming that there have been no occurrences of the event (e.g., no input errors because ifInErrors is always zero).
1つの例がエージェントがifTableカウンタの1つ(さらに)によって定義された発生を数えることができないところです。 この状況では、エージェントはたとえば、ゼロの値で特定のカウンタを例示してはいけません。 そうするのは、ゼロが評価するネットワークマネージメントアプリケーションの読みに誤情報を提供して、その結果、イベントの発生が全くなかったと仮定して、提供するだろう(いつもifInErrorsがゼロであるので、いいえは例えば、誤りを入力しました)ことです。
Sometimes the lack of knowledge of an object's value is temporary. For example, when the MTU of an interface is a configured value and a device dynamically learns the configured value through (after) exchanging messages over the interface (e.g., ATM LAN-Emulation [20]). In such a case, the value is not known until after the ifTable entry has already been created. In such a case, the ifTable entry should be created without an instance of the object whose value is unknown; later, when the value becomes known, the missing object can then be instantiated (e.g., the instance of ifMtu is only instantiated once the interface's MTU becomes known).
時々、オブジェクトの価値の知識不足は一時的です。 例えば、いつインタフェースのMTUが構成された値であるか、そして、デバイスはインタフェースの上とメッセージを交換する(after)を通してダイナミックに構成された値を学びます。(例えば、ATM LAN-エミュレーション[20])。 このような場合には、既にifTableエントリーを作成してある後まで値は知られていません。 このような場合には、ifTableエントリーは値が未知であるオブジェクトのインスタンスなしで作成されるべきです。 そして、値がその後知られるようになるとき、なくなったオブジェクトを例示できます(インタフェースのMTUがいったん知られるようになると、例えばifMtuのインスタンスは例示されるだけです)。
As a result of this "known values" rule, management applications MUST be able to cope with the responses to retrieving the object instances within a conceptual row of the ifTable revealing that some of the row's columnar objects are missing/not available.
この規則、管理アプリケーションが応答に対処できなければならない「知られている値」検索の結果、行のいくつかの円柱状のオブジェクトが利用可能でないなくなった/であることを明らかにするifTableの概念的な行の中のオブジェクトインスタンス。
4. Media-Specific MIB Applicability
4. メディア特有のMIBの適用性
The exact use and semantics of many objects in this MIB are open to some interpretation. This is a result of the generic nature of this MIB. It is not always possible to come up with specific, unambiguous, text that covers all cases and yet preserves the generic nature of the MIB.
このMIBの多くのオブジェクトの正確な使用と意味論は何らかの解釈に開かれています。 これはこのMIBのジェネリック自然の結果です。 特定に思いつくのはいつも可能であるというわけではありません、明白です、すべてのケースをカバーしていますが、MIBのジェネリック自然を保持するテキスト。
Therefore, it is incumbent upon a media-specific MIB designer to, wherever necessary, clarify the use of the objects in this MIB with respect to the media-specific MIB.
したがって、メディア特有のMIBデザイナーでは、どこでも、必要であるところでメディア特有のMIBに関してこのMIBにおけるオブジェクトの使用をはっきりさせるのは義務です。
McCloghrie & Kastenholz Standards Track [Page 24] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[24ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
Specific areas of clarification include
明確化インクルードの特定の領域
Layering Model
The media-specific MIB designer MUST completely and unambiguously
specify the layering model used. Each individual sub-layer must
be identified, as must the ifStackTable's portrayal of the
relationship(s) between the sub-layers.
Modelを層にして、メディア特有のMIBデザイナーは完全に明白に使用されるレイヤリングモデルを指定しなければなりません。 ifStackTableの副層の間の関係の描写でなければならないののようにそれぞれの個々の副層を特定しなければなりません。
Virtual Circuits
The media-specific MIB designer MUST specify whether virtual
circuits are assigned entries in the ifTable or not. If they are,
compelling rationale must be presented.
メディア特有のMIBデザイナーの仮想のCircuitsは、エントリーがifTableで仮想の回路に割り当てられるかどうか指定しなければなりません。 それらがそうなら、無視できない原理を提示しなければなりません。
ifRcvAddressTable
The media-specific MIB designer MUST specify the applicability of
the ifRcvAddressTable.
メディア特有のMIBデザイナーのifRcvAddressTableはifRcvAddressTableの適用性を指定しなければなりません。
ifType
For each of the ifType values to which the media-specific MIB
applies, it must specify the mapping of ifType values to media-
specific MIB module(s) and instances of MIB objects within those
modules.
それぞれそれが、メディア特有のMIBが適用すると指定しなければならないifType値のifType Forはそれらのモジュールの中でMIBのメディアの特定のMIBモジュールとインスタンスに反対しますifTypeに関するマッピングが、評価する。
ifXxxOctets
The definitions of ifInOctets and ifOutOctets (and similarly,
ifHCInOctets and ifHCOutOctets) specify that their values include
framing characters. The media-specific MIB designer MUST specify
any special conditions of the media concerning the inclusion of
framing characters, especially with respect to frames with errors.
そして、ifXxxOctets、ifInOctetsとifOutOctetsの定義、(同様である、ifHCInOctetsとifHCOutOctets) 彼らの値が、キャラクタを罪に陥れるのを含んでいると指定してください。 メディア特有のMIBデザイナーは縁どりキャラクタの包含に関してメディアのどんな特別な状態も指定しなければなりません、特に誤りがあるフレームに関して。
However, wherever this interface MIB is specific in the semantics, DESCRIPTION, or applicability of objects, the media-specific MIB designer MUST NOT change said semantics, DESCRIPTION, or applicability.
しかしながら、どこでも、このインタフェースMIBがオブジェクトの意味論、記述、または適用性で特定であるところでは、メディア特有のMIBデザイナーが前述の意味論、記述、または適用性を変えてはいけません。
5. Overview
5. 概要
This MIB consists of 4 tables:
このMIBは4個のテーブルから成ります:
ifTable
This table is the ifTable from MIB-II.
ifTable ThisテーブルはMIB-IIからのifTableです。
ifXTable
This table contains objects that have been added to the Interface
MIB as a result of the Interface Evolution effort, or replacements
for objects of the original (MIB-II) ifTable that were deprecated
ifXTable ThisテーブルはInterface Evolution取り組みの結果、Interface MIBに加えられるオブジェクト、またはオリジナル(MIB-II)のifTableのオブジェクトとの推奨しなかった交換を含んでいます。
McCloghrie & Kastenholz Standards Track [Page 25] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[25ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
because the semantics of said objects have significantly changed.
This table also contains objects that were previously in the
ifExtnsTable.
前述のオブジェクトの意味論がかなり変化したので。 また、このテーブルは以前に、ifExtnsTableにあったオブジェクトを含んでいます。
ifStackTable
This table contains objects that define the relationships among
the sub-layers of an interface.
ifStackTable Thisテーブルはインタフェースの副層の中で関係を定義するオブジェクトを含んでいます。
ifRcvAddressTable
This table contains objects that are used to define the media-
level addresses which this interface will receive. This table is
a generic table. The designers of media-specific MIBs must define
exactly how this table applies to their specific MIB.
ifRcvAddressTable Thisテーブルはこのインタフェースが受け取るメディアの平らなアドレスを定義するのに使用されるオブジェクトを含んでいます。 このテーブルはジェネリックテーブルです。 メディア特有のMIBsのデザイナーはこのテーブルがちょうどどう彼らの特定のMIBに適用されるかを定義しなければなりません。
6. Interfaces Group Definitions
6. グループ定義を連結します。
IF-MIB DEFINITIONS ::= BEGIN
-、MIB、定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64,
Integer32, TimeTicks, mib-2,
NOTIFICATION-TYPE FROM SNMPv2-SMI
TEXTUAL-CONVENTION, DisplayString,
PhysAddress, TruthValue, RowStatus,
TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP FROM SNMPv2-CONF
snmpTraps FROM SNMPv2-MIB
IANAifType FROM IANAifType-MIB;
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、Counter32、Gauge32、Counter64、Integer32、TimeTicks、mib-2、NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION、DisplayString、PhysAddress、TruthValue、RowStatus、TimeStamp、AutonomousType、TestAndIncr FROM SNMPv2-TC MODULE-COMPLIANCE、OBJECT-GROUP、NOTIFICATION-GROUP FROM SNMPv2-CONF snmpTraps FROM SNMPv2-MIB IANAifType FROM IANAifType-MIB。
ifMIB MODULE-IDENTITY
LAST-UPDATED "200006140000Z"
ORGANIZATION "IETF Interfaces MIB Working Group"
CONTACT-INFO
" Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
ifMIBモジュールアイデンティティ最終更新日の"200006140000Z"組織「IETFインタフェースMIB作業部会」コンタクトインフォメーション「西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)」
408-526-5260
kzm@cisco.com"
DESCRIPTION
"The MIB module to describe generic objects for network
interface sub-layers. This MIB is an updated version of
MIB-II's ifTable, and incorporates the extensions defined in
RFC 1229."
「408-526-5260 kzm@cisco.com 」記述、「ネットワーク・インターフェース副層のためにジェネリックオブジェクトについて説明するMIBモジュール。」 「このMIBはMIB-IIのifTableのアップデートされたバージョンであり、RFC1229で定義された拡大を取り入れます。」
McCloghrie & Kastenholz Standards Track [Page 26] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[26ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
REVISION "200006140000Z"
DESCRIPTION
"Clarifications agreed upon by the Interfaces MIB WG, and
published as RFC 2863."
REVISION "199602282155Z"
DESCRIPTION
"Revisions made by the Interfaces MIB WG, and published in
RFC 2233."
REVISION "199311082155Z"
DESCRIPTION
"Initial revision, published as part of RFC 1573."
::= { mib-2 31 }
「明確化はMIB WGであって、RFC2863として発行されたインタフェースのそばで同意した」REVISION"200006140000Z"記述。 「改正はMIB WGであって、RFC2233で発行されたインタフェースのそばで作った」REVISION"199602282155Z"記述。 「初期の改正であって、RFC1573の一部として発行された」REVISION"199311082155Z"記述。 ::= mib-2 31
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
ifMIBObjectsオブジェクト識別子:、:= ifMIB1
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
インタフェースOBJECT IDENTIFIER:、:= mib-2 2
-- -- Textual Conventions --
-- -- 原文のコンベンション--
-- OwnerString has the same semantics as used in RFC 1271
-- OwnerStringには、RFC1271で同じくらい中古の同じ意味論があります。
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS deprecated
DESCRIPTION
"This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
OwnerString:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの"255a"STATUSの推奨しない記述、「このデータ型はリソースの所有者の行政上割り当てられた名前をモデル化するのに使用されます」。 NVT ASCII文字の組からこの情報を取ります。 この名前が以下の1つ以上を含むことが提案されます: ネットワークマネージメント人員のマネージャステーションの輸送アドレス、管理局名(例えば、ドメイン名)、名前、位置、または電話番号のASCIIフォーム。 いくつかの場合、エージェント自身はエントリーの所有者になるでしょう。 「これらの場合では、このストリングは'エージェント'から始まるストリングに設定されるものとします。」 構文八重奏ストリング(サイズ(0 .255))
-- InterfaceIndex contains the semantics of ifIndex and should be used -- for any objects defined in other MIB modules that need these semantics.
-- InterfaceIndexはifIndexの意味論を含んでいて、これらの意味論を必要とする他のMIBモジュールで定義されたどんなオブジェクトにおいても、使用されているべきです。
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
InterfaceIndex:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述
McCloghrie & Kastenholz Standards Track [Page 27] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[27ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"A unique value, greater than zero, for each interface or
interface sub-layer in the managed system. It is
recommended that values are assigned contiguously starting
from 1. The value for each interface sub-layer must remain
constant at least from one re-initialization of the entity's
network management system to the next re-initialization."
SYNTAX Integer32 (1..2147483647)
「ユニークな値、各インタフェースあたりゼロ以上または管理されたシステムのインタフェース副層。」 近接して1から始めて、値が割り当てられるのは、お勧めです。 「それぞれのインタフェース副層のための値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」 構文Integer32(1..2147483647)
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
InterfaceIndexOrZero:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述、「この原文のコンベンションはInterfaceIndexコンベンションの拡大です」。 後者は管理されたシステムでどんな値も以前はよくインタフェースかインタフェースを特定していなかったよりすばらしい副層を定義します。 この拡大はゼロの加算値を可能にします。値ゼロをオブジェクト特有であり、したがって、この構文を使用するどんなオブジェクトの記述の一部とも定義しなければなりません。 「インタフェースが未知であった、またはなにもかすべてのインタフェースが、参照をつけられる必要があるとき、ゼロの用法に関する例は状況を含むかもしれません。」 構文Integer32(0..2147483647)
ifNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their
current state) present on this system."
::= { interfaces 1 }
「ネットワーク・インターフェース(彼らの現状にかかわらず)の数はこのシステムの上に示す」ifNumber OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= インタフェース1
ifTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last creation or
deletion of an entry in the ifTable. If the number of
entries has been unchanged since the last re-initialization
of the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 5 }
ifTableLastChange OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「最後の作成時点のsysUpTimeの値かifTableでのエントリーの削除。」 「企業内情報通信網管理サブシステムの最後の再初期化以来エントリーの数が変わりがないなら、このオブジェクトはaゼロ値を含んでいます。」 ::= ifMIBObjects5
-- the Interfaces table
-- Interfacesテーブル
-- The Interfaces table contains information on the entity's
-- Interfacesテーブルは実体の情報を含んでいます。
McCloghrie & Kastenholz Standards Track [Page 28] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[28ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
-- interfaces. Each sub-layer below the internetwork-layer -- of a network interface is considered to be an interface.
-- インタフェース。 ネットワーク・インターフェースのインターネットワーク層の下の各副層はそうです。インタフェースであると考えられます。
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber."
::= { interfaces 2 }
「Aはインタフェースエントリーについて記載する」ifTable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「ifNumberの値でエントリーの数を与えます。」 ::= インタフェース2
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable to a
particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
ifEntry OBJECT-TYPE SYNTAX IfEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のインタフェースに適切な経営情報を含むエントリー。」 ifIndexに索引をつけてください:、:= ifTable1
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex,
ifDescr DisplayString,
ifType IANAifType,
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, -- deprecated
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, -- deprecated
ifSpecific OBJECT IDENTIFIER -- deprecated
}
IfEntry:、:= 系列{ ifIndex InterfaceIndex、ifDescr DisplayString、ifType IANAifType、ifMtu Integer32、ifSpeed Gauge32、ifPhysAddress PhysAddress、ifAdminStatus整数、ifOperStatus整数、ifLastChange TimeTicks、ifInOctets Counter32; IfInUcastPkts Counter32、ifInNUcastPkts Counter32--推奨しないifInDiscards Counter32、ifInErrors Counter32、ifInUnknownProtos Counter32、ifOutOctets Counter32、ifOutUcastPkts Counter32、ifOutNUcastPkts Counter32--ifOutErrors Counter32の、そして、ifOutQLen Gauge32(推奨しないifSpecific OBJECT IDENTIFIER)推奨しない推奨しないifOutDiscards Counter32; }
McCloghrie & Kastenholz Standards Track [Page 29] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[29ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization."
::= { ifEntry 1 }
「各インタフェースあたりゼロよりユニークな値で、すばらしい」ifIndex OBJECT-TYPE SYNTAX InterfaceIndexマックス-ACCESS書き込み禁止STATUS現在の記述。 近接して1から始めて、値が割り当てられるのは、お勧めです。 「それぞれのインタフェース副層のための値は少なくとも実体のネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままで残らなければなりません。」 ::= ifEntry1
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of the
manufacturer, the product name and the version of the
interface hardware/software."
::= { ifEntry 2 }
ifDescr OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .255))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースの情報を含む原文のストリング。」 「このストリングはメーカーの名前、製品名、およびインタフェースハードウェア/ソフトウェアのバージョンを含んでいるはずです。」 ::= ifEntry2
ifType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of interface. Additional values for ifType are
assigned by the Internet Assigned Numbers Authority (IANA),
through updating the syntax of the IANAifType textual
convention."
::= { ifEntry 3 }
ifType OBJECT-TYPE SYNTAX IANAifTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースのタイプ。」 「ifTypeのための加算値はインターネットAssigned民数記Authority(IANA)によって割り当てられます、IANAifTypeの原文のコンベンションの構文をアップデートすることで。」 ::= ifEntry3
ifMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The size of the largest packet which can be sent/received
on the interface, specified in octets. For interfaces that
are used for transmitting network datagrams, this is the
size of the largest network datagram that can be sent on the
interface."
::= { ifEntry 4 }
ifMtu OBJECT-TYPE SYNTAX Integer32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「八重奏で指定されたインタフェースに送るか、または受け取ることができる中で最も大きいパケットのサイズ。」 「ネットワークデータグラムを送るのに使用されるインタフェースに関して、これはインタフェースで送ることができる中で最も大きいネットワークデータグラムのサイズです。」 ::= ifEntry4
ifSpeed OBJECT-TYPE
オブジェクト・タイプをifSpeedしました。
McCloghrie & Kastenholz Standards Track [Page 30] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[30ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in bits
per second. For interfaces which do not vary in bandwidth
or for those where no accurate estimation can be made, this
object should contain the nominal bandwidth. If the
bandwidth of the interface is greater than the maximum value
reportable by this object then this object should report its
maximum value (4,294,967,295) and ifHighSpeed must be used
to report the interace's speed. For a sub-layer which has
no concept of bandwidth, this object should be zero."
::= { ifEntry 5 }
SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「bpsにおけるインタフェースの現在の帯域幅の見積り。」 帯域幅で異ならないインタフェースかどんな正確な見積りもすることができないところのそれらに関しては、このオブジェクトは呼び帯域幅を含むはずです。 インタフェースの帯域幅が最大値報告可能よりこのオブジェクトで大きいなら、このオブジェクトは、interaceの速度を報告するのにその最大値(4,294,967,295)とifHighSpeedを使用しなければならないと報告するはずです。 「帯域幅の概念を全く持っていない副層のために、このオブジェクトはゼロであるべきです。」 ::= ifEntry5
ifPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a MAC address. The interface's media-specific MIB
must define the bit and byte ordering and the format of the
value of this object. For interfaces which do not have such
an address (e.g., a serial line), this object should contain
an octet string of zero length."
::= { ifEntry 6 }
ifPhysAddress OBJECT-TYPE SYNTAX PhysAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「プロトコル副層のインタフェースのアドレス。」 例えば、802.xインタフェースに関して、通常、このオブジェクトはMACアドレスを含んでいます。 インタフェースのメディア特有のMIBはこのオブジェクトの値のビット、バイト順、および書式を定義しなければなりません。 「そのようなアドレス(例えば、シリアル・ライン)を持っていないインタフェースに関して、このオブジェクトはゼロ・レングスの八重奏ストリングを含むはずです。」 ::= ifEntry6
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3) state
indicates that no operational packets can be passed. When a
managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state. As a result of either
explicit management action or per configuration information
retained by the managed system, ifAdminStatus is then
changed to either the up(1) or testing(3) states (or remains
in the down(2) state)."
::= { ifEntry 7 }
ifAdminStatus OBJECT-TYPE SYNTAX INTEGERはいくつかのパケット下に(2)、テスト(3)を通過する準備ができている(1)にモードをテストします。マックス-ACCESSは「インタフェースの必要な状態」をSTATUSの現在の記述に読書して書きます。 テスト(3)州は、どんな操作上のパケットも通過できないのを示します。 いつ、管理されたシステムが初期化するか、すべてのインタフェースが下に(2)状態でifAdminStatusから始まります。 「そして、明白な管理活動の結果、管理されたシステムによって保有された設定情報に従って、ifAdminStatusは上がるのに(1)かテスト(3)が述べる(または、下に(2)州では、残っています)変わります。」 ::= ifEntry7
McCloghrie & Kastenholz Standards Track [Page 31] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[31ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3), -- in some test mode
unknown(4), -- status can not be determined
-- for some reason.
dormant(5),
notPresent(6), -- some component is missing
lowerLayerDown(7) -- down due to state of
-- lower-layer interface(s)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets can
be passed. If ifAdminStatus is down(2) then ifOperStatus
should be down(2). If ifAdminStatus is changed to up(1)
then ifOperStatus should change to up(1) if the interface is
ready to transmit and receive network traffic; it should
change to dormant(5) if the interface is waiting for
external actions (such as a serial line waiting for an
incoming connection); it should remain in the down(2) state
if and only if there is a fault that prevents it from going
to the up(1) state; it should remain in the notPresent(6)
state if the interface has missing (typically, hardware)
components."
::= { ifEntry 8 }
いくつかのための(2)でパケットを通過する準備ができています、何らかのテスト・モード未知(4)における(3)をテストして、状態が決定できないという(1)に推論してください。ifOperStatus OBJECT-TYPE SYNTAX INTEGERの{眠っている(5)、何らかのコンポーネントがなくなったlowerLayerDown(7)であるというnotPresent(6)は述べるのにおいて当然の状態でダウンします--下層インタフェース}というマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースの現在の操作上の状態。」 テスト(3)州は、どんな操作上のパケットも通過できないのを示します。 ifAdminStatusが下(2)であるなら、ifOperStatusは下(2)であるべきである。 ifAdminStatusがそうなら、インタフェースが送受信する準備ができているなら(1)で(1) ifOperStatusが変化するはずであるその時に変えて、トラフィックをネットワークでつないでください。 それは、インタフェースが外部の動き(接続要求を待つシリアル・ラインなどの)を待っているかどうかを眠っている(5)に変えるべきです。 そして、下に(2)州に残るべきである、欠点がある場合にだけ、それは、それが上(1)状態に行くのを防ぎます。 「インタフェースでなくなった(通常ハードウェア)コンポーネントがあるかどうかがnotPresent(6)州に残るべきです。」 ::= ifEntry8
ifLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the interface entered
its current operational state. If the current state was
entered prior to the last re-initialization of the local
network management subsystem, then this object contains a
zero value."
::= { ifEntry 9 }
ifLastChange OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「インタフェースが現在の操作上の状態に入った時のsysUpTimeの値。」 「現状が企業内情報通信網管理サブシステムの最後の再初期化の前に入られたなら、このオブジェクトはaゼロ値を含んでいます。」 ::= ifEntry9
ifInOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
「八重奏の総数はインタフェースで受けた」ifInOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
McCloghrie & Kastenholz Standards Track [Page 32] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[32ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
including framing characters.
キャラクタを罪に陥れるのを含んでいます。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 10 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry10
ifInUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were not addressed to a multicast
or broadcast address at this sub-layer.
ifInUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストか放送演説に扱われませんでした)。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 11 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry11
ifInNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were addressed to a multicast or
broadcast address at this sub-layer.
ifInNUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストか放送演説に扱われました)。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime.
このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。
This object is deprecated in favour of ifInMulticastPkts and
ifInBroadcastPkts."
::= { ifEntry 12 }
「このオブジェクトはifInMulticastPktsとifInBroadcastPktsを支持して推奨しないです。」 ::= ifEntry12
ifInDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of inbound packets which were chosen to be
discarded even though no errors had been detected to prevent
ifInDiscards OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「誤りが全く検出されていませんでしたが、捨てられるために選ばれた本国行きのパケットの数、防ぐ、」
McCloghrie & Kastenholz Standards Track [Page 33] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[33ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
their being deliverable to a higher-layer protocol. One
possible reason for discarding such a packet could be to
free up buffer space.
それらは上位層プロトコルへの提出物です。 そのようなパケットを捨てる1つの可能な理由はバッファ領域を開けることであることができました。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 13 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry13
ifInErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of inbound
packets that contained errors preventing them from being
deliverable to a higher-layer protocol. For character-
oriented or fixed-length interfaces, the number of inbound
transmission units that contained errors preventing them
from being deliverable to a higher-layer protocol.
「パケット指向のインタフェース、それらが提出物であることを上位層プロトコルに防ぐ誤りを含んだ本国行きのパケットの数」のためのifInErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 キャラクタ指向の、または、固定長さのインタフェースに関しては、それらが提出物であることをより高い層に防ぐ誤りを含んだ本国行きのトランスミッションユニットの数は議定書を作ります。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 14 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry14
ifInUnknownProtos OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of packets
received via the interface which were discarded because of
an unknown or unsupported protocol. For character-oriented
or fixed-length interfaces that support protocol
multiplexing the number of transmission units received via
the interface which were discarded because of an unknown or
unsupported protocol. For any interface that does not
support protocol multiplexing, this counter will always be
0.
「パケット指向のインタフェース、未知の、または、サポートされないプロトコルのために捨てられたインタフェースを通して受け取られたパケットの数」のためのifInUnknownProtos OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 キャラクタ指向の、または、固定長さのインタフェースに関しては、トランスミッションユニットの数を多重送信するそのサポートプロトコルが未知の、または、サポートされないプロトコルのために捨てられたインタフェースを通して受信されました。 このカウンタはいつもプロトコルマルチプレクシングをサポートしないどんなインタフェースに関しては0にもなるでしょう。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 15 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry15
McCloghrie & Kastenholz Standards Track [Page 34] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[34ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifOutOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters.
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースから伝えた」ifOutOctets OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 16 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry16
ifOutUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were not addressed to a
multicast or broadcast address at this sub-layer, including
those that were discarded or not sent.
ifOutUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われなかったか、」
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 17 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry17
ifOutNUcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were addressed to a
multicast or broadcast address at this sub-layer, including
those that were discarded or not sent.
ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われたか、」
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime.
このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。
This object is deprecated in favour of ifOutMulticastPkts
and ifOutBroadcastPkts."
::= { ifEntry 18 }
「このオブジェクトはifOutMulticastPktsとifOutBroadcastPktsを支持して推奨しないです。」 ::= ifEntry18
McCloghrie & Kastenholz Standards Track [Page 35] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[35ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifOutDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of outbound packets which were chosen to be
discarded even though no errors had been detected to prevent
their being transmitted. One possible reason for discarding
such a packet could be to free up buffer space.
ifOutDiscards OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「誤りが全くそれらがあるのを伝えられた状態で防ぐために検出されていませんでしたが、捨てられるために選ばれた外国行きのパケットの数。」 そのようなパケットを捨てる1つの可能な理由はバッファ領域を開けることであることができました。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 19 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry19
ifOutErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"For packet-oriented interfaces, the number of outbound
packets that could not be transmitted because of errors.
For character-oriented or fixed-length interfaces, the
number of outbound transmission units that could not be
transmitted because of errors.
「パケット指向のインタフェース、誤りのために伝えることができなかった外国行きのパケットの数」のためのifOutErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 キャラクタ指向の、または、固定長さのインタフェース、誤りのために送ることができなかった外国行きのトランスミッションユニットの数のために。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 20 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifEntry20
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }
「出力パケットの長さは列に並ばせ(パケットで)」ifOutQLen OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述。 ::= ifEntry21
ifSpecific OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"A reference to MIB definitions specific to the particular
media being used to realize the interface. It is
「Aはインタフェースがわかるのに使用される特定のメディアに特定のMIB定義に参照をつける」ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述。 それはそうです。
McCloghrie & Kastenholz Standards Track [Page 36] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[36ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
recommended that this value point to an instance of a MIB
object in the media-specific MIB, i.e., that this object
have the semantics associated with the InstancePointer
textual convention defined in RFC 2579. In fact, it is
recommended that the media-specific MIB specify what value
ifSpecific should/can take for values of ifType. If no MIB
definitions specific to the particular media are available,
the value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }
この値がメディア特有のMIBにMIBオブジェクトのインスタンスを示して、すなわち、このオブジェクトにはRFC2579で定義されるInstancePointerの原文のコンベンションに関連している意味論があることを勧めました。 事実上、メディア特有のMIBが、/がifTypeの値に取ることができるなら何がifSpecificを評価するかを指定するのは、お勧めです。 「特定のメディアに特定のどんなMIB定義も利用可能でないなら、値はOBJECT IDENTIFIER0 0に設定されるべきです。」 ::= ifEntry22
-- -- Extension to the interface table -- -- This table replaces the ifExtnsTable table. --
-- -- インタフェーステーブルへの拡大----このテーブルはifExtnsTableテーブルを取り替えます。 --
ifXTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber. This table contains
additional objects for the interface table."
::= { ifMIBObjects 1 }
「Aはインタフェースエントリーについて記載する」ifXTable OBJECT-TYPE SYNTAX SEQUENCE OF IfXEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ifNumberの値でエントリーの数を与えます。 「このテーブルはインタフェーステーブルのための追加オブジェクトを含んでいます。」 ::= ifMIBObjects1
ifXEntry OBJECT-TYPE
SYNTAX IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional management information
applicable to a particular interface."
AUGMENTS { ifEntry }
::= { ifXTable 1 }
ifXEntry OBJECT-TYPE SYNTAX IfXEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のインタフェースに適切な追加経営情報を含むエントリー。」 ifEntryを増大させます:、:= ifXTable1
IfXEntry ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
IfXEntry:、:= 系列、ifName DisplayString、ifInMulticastPkts Counter32、ifInBroadcastPkts Counter32、ifOutMulticastPkts Counter32、ifOutBroadcastPkts Counter32、ifHCInOctets Counter64、ifHCInUcastPkts Counter64、ifHCInMulticastPkts Counter64
McCloghrie & Kastenholz Standards Track [Page 37] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[37ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifHCInBroadcastPkts Counter64,
ifHCOutOctets Counter64,
ifHCOutUcastPkts Counter64,
ifHCOutMulticastPkts Counter64,
ifHCOutBroadcastPkts Counter64,
ifLinkUpDownTrapEnable INTEGER,
ifHighSpeed Gauge32,
ifPromiscuousMode TruthValue,
ifConnectorPresent TruthValue,
ifAlias DisplayString,
ifCounterDiscontinuityTime TimeStamp
}
ifHCInBroadcastPkts Counter64、ifHCOutOctets Counter64、ifHCOutUcastPkts Counter64、ifHCOutMulticastPkts Counter64、ifHCOutBroadcastPkts Counter64、ifLinkUpDownTrapEnable整数、ifHighSpeed Gauge32、ifPromiscuousMode TruthValue、ifConnectorPresent TruthValue、ifAlias DisplayString、ifCounterDiscontinuityTimeタイムスタンプ
ifName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The textual name of the interface. The value of this
object should be the name of the interface as assigned by
the local device and should be suitable for use in commands
entered at the device's `console'. This might be a text
name, such as `le0' or a simple port number, such as `1',
depending on the interface naming syntax of the device. If
several entries in the ifTable together represent a single
interface as named by the device, then each will have the
same value of ifName. Note that for an agent which responds
to SNMP queries concerning an interface on some other
(proxied) device, then the value of ifName for such an
interface is the proxied device's local name for it.
「原文はインタフェースについて命名する」ifName OBJECT-TYPE SYNTAX DisplayStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このオブジェクトの値は、ローカル装置によって割り当てられるようにインタフェースの名前であるべきであり、デバイスの'コンソール'に入力されたコマンドにおける使用に適しているべきです。 これは原文名であるかもしれません、'le0'や簡単なポートナンバーのように、'1などのように'、デバイスのインタフェース命名構文によって。 一緒にifTableのいくつかのエントリーがデバイスによって命名されるように単一のインタフェースを表すと、それぞれには、ifNameの同じ値があるでしょう。 次に、ある他の(proxiedしました)デバイスでインタフェースに関してSNMP質問に応じるエージェントにとってそのようなインタフェースへのifNameの値がそれのためのproxiedデバイスの地方名であることに注意してください。
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string."
::= { ifXEntry 1 }
「地方名が全くないか、またはそうでなければ、このオブジェクトが適切でないなら、このオブジェクトはゼロ長ストリングを含んでいます。」 ::= ifXEntry1
ifInMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were addressed to a multicast
address at this sub-layer. For a MAC layer protocol, this
includes both Group and Functional addresses.
ifInMulticastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストアドレスに扱われました)。 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
このカウンタの値における不連続はマネージメントシステムの再初期化において他に起こることができます。
McCloghrie & Kastenholz Standards Track [Page 38] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[38ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 2 }
「ifCounterDiscontinuityTimeの値によって示される回。」 ::= ifXEntry2
ifInBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were addressed to a broadcast
address at this sub-layer.
ifInBroadcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層の放送演説に扱われました)。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 3 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry3
ifOutMulticastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were addressed to a
multicast address at this sub-layer, including those that
were discarded or not sent. For a MAC layer protocol, this
includes both Group and Functional addresses.
ifOutMulticastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層のaマルチキャストアドレスに扱われたか、」 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 4 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry4
ifOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were addressed to a
broadcast address at this sub-layer, including those that
were discarded or not sent.
ifOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層の放送のアドレスに扱われたか、」
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
このカウンタの値における不連続はマネージメントシステムの再初期化において他に起こることができます。
McCloghrie & Kastenholz Standards Track [Page 39] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[39ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 5 }
「ifCounterDiscontinuityTimeの値によって示される回。」 ::= ifXEntry5
-- -- High Capacity Counter objects. These objects are all -- 64 bit versions of the "basic" ifTable counters. These -- objects all have the same basic semantics as their 32-bit -- counterparts, however, their syntax has been extended -- to 64 bits. --
-- -- 高いCapacity Counterは反対します。 これらのオブジェクトはすべてです--「基本的な」ifTableカウンタの64ビットのバージョン。 これら--オブジェクトにはすべて、対応者、しかしながら、彼らの構文を広げてあるというそれらの32ビットと同じ基本的な意味論が64ビットまであります。 --
ifHCInOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets received on the interface,
including framing characters. This object is a 64-bit
version of ifInOctets.
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースで受けた」ifHCInOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このオブジェクトはifInOctetsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 6 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry6
ifHCInUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were not addressed to a multicast
or broadcast address at this sub-layer. This object is a
64-bit version of ifInUcastPkts.
ifHCInUcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストか放送演説に扱われませんでした)。 このオブジェクトはifInUcastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 7 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry7
ifHCInMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
ifHCInMulticastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
McCloghrie & Kastenholz Standards Track [Page 40] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[40ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were addressed to a multicast
address at this sub-layer. For a MAC layer protocol, this
includes both Group and Functional addresses. This object
is a 64-bit version of ifInMulticastPkts.
「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層のマルチキャストアドレスに扱われました)。 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。 このオブジェクトはifInMulticastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 8 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry8
ifHCInBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of packets, delivered by this sub-layer to a
higher (sub-)layer, which were addressed to a broadcast
address at this sub-layer. This object is a 64-bit version
of ifInBroadcastPkts.
ifHCInBroadcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この副層でaにより高く提供されたパケットの数、(サブ、)、層、」。(それは、この副層の放送演説に扱われました)。 このオブジェクトはifInBroadcastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 9 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry9
ifHCOutOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of octets transmitted out of the
interface, including framing characters. This object is a
64-bit version of ifOutOctets.
「キャラクタを罪に陥れるのを含んでいて、八重奏の総数はインタフェースから伝えた」ifHCOutOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このオブジェクトはifOutOctetsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 10 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry10
ifHCOutUcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
ifHCOutUcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
McCloghrie & Kastenholz Standards Track [Page 41] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[41ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"The total number of packets that higher-level protocols
requested be transmitted, and which were not addressed to a
multicast or broadcast address at this sub-layer, including
those that were discarded or not sent. This object is a
64-bit version of ifOutUcastPkts.
「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層でマルチキャストか放送のアドレスに扱われなかったか、」 このオブジェクトはifOutUcastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 11 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry11
ifHCOutMulticastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were addressed to a
multicast address at this sub-layer, including those that
were discarded or not sent. For a MAC layer protocol, this
includes both Group and Functional addresses. This object
is a 64-bit version of ifOutMulticastPkts.
ifHCOutMulticastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層のaマルチキャストアドレスに扱われたか、」 MAC層のプロトコルのために、これはGroupとFunctionalアドレスの両方を含んでいます。 このオブジェクトはifOutMulticastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 12 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry12
ifHCOutBroadcastPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of packets that higher-level protocols
requested be transmitted, and which were addressed to a
broadcast address at this sub-layer, including those that
were discarded or not sent. This object is a 64-bit version
of ifOutBroadcastPkts.
ifHCOutBroadcastPkts OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「伝えられた状態で要求された上位レベル・プロトコルがあるパケットの数を合計してください、捨てられたか、または送られなかったものを含んでいて、どれがこの副層の放送のアドレスに扱われたか、」 このオブジェクトはifOutBroadcastPktsの64ビットのバージョンです。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 13 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= ifXEntry13
ifLinkUpDownTrapEnable OBJECT-TYPE
ifLinkUpDownTrapEnableオブジェクト・タイプ
McCloghrie & Kastenholz Standards Track [Page 42] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[42ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether linkUp/linkDown traps should be generated
for this interface.
(1)を可能にして、(2)であることが無効にされたマックス-ACCESSが「linkUp/linkDown罠がこのインタフェースに生成されるべきであるかどうかを示す」とSTATUSの現在の記述に読書して書くSYNTAX INTEGER。
By default, this object should have the value enabled(1) for
interfaces which do not operate on 'top' of any other
interface (as defined in the ifStackTable), and disabled(2)
otherwise."
::= { ifXEntry 14 }
「(1) (2) そうでなければ、するインタフェースがいかなる他のインタフェースの'先端'(ifStackTableで定義されるように)、および身体障害者も手術しないので、デフォルトで、このオブジェクトは値を可能にするはずです。」 ::= ifXEntry14
ifHighSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in units
of 1,000,000 bits per second. If this object reports a
value of `n' then the speed of the interface is somewhere in
the range of `n-500,000' to `n+499,999'. For interfaces
which do not vary in bandwidth or for those where no
accurate estimation can be made, this object should contain
the nominal bandwidth. For a sub-layer which has no concept
of bandwidth, this object should be zero."
::= { ifXEntry 15 }
ifHighSpeed OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「100万のbpsのユニットにおけるインタフェースの現在の帯域幅の見積り。」 'このオブジェクトが値を報告する、'インタフェースの速度が範囲のどこかにあるその時、-50万、'、+499,999' 帯域幅で異ならないインタフェースかどんな正確な見積りもすることができないところのそれらに関しては、このオブジェクトは呼び帯域幅を含むはずです。 「帯域幅の概念を全く持っていない副層のために、このオブジェクトはゼロであるべきです。」 ::= ifXEntry15
ifPromiscuousMode OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object has a value of false(2) if this interface only
accepts packets/frames that are addressed to this station.
This object has a value of true(1) when the station accepts
all packets/frames transmitted on the media. The value
true(1) is only legal on certain types of media. If legal,
setting this object to a value of true(1) may require the
interface to be reset before becoming effective.
ifPromiscuousMode OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「このオブジェクトには、このインタフェースがこのステーションに扱われるパケット/フレームを受け入れるだけであるなら、誤った(2)の値があること」をSTATUSの現在の記述に読書して書きます。 ステーションがメディアで伝えられたすべてのパケット/フレームを受け入れるとき、このオブジェクトには、本当の(1)の値があります。 値の本当の(1)は単にあるタイプのメディアで法的です。 法的であるなら、本当の(1)の値にこのオブジェクトを設定するのは、インタフェースが有効になる前にリセットされるのを必要とするかもしれません。
The value of ifPromiscuousMode does not affect the reception
of broadcast and multicast packets/frames by the interface."
::= { ifXEntry 16 }
「ifPromiscuousModeの値はインタフェースのそばで放送とマルチキャストパケット/フレームのレセプションに影響しません。」 ::= ifXEntry16
ifConnectorPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
ifConnectorPresent OBJECT-TYPE SYNTAX TruthValueマックス-ACCESS書き込み禁止
McCloghrie & Kastenholz Standards Track [Page 43] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[43ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
STATUS current
DESCRIPTION
"This object has the value 'true(1)' if the interface
sublayer has a physical connector and the value 'false(2)'
otherwise."
::= { ifXEntry 17 }
(1) '(2) 'そうでなければ、インタフェース副層には、物理的なコネクタと値が'虚偽である」なら、STATUSの現在の記述は本当に「値を持これが反対するしています'。 ::= ifXEntry17
ifAlias OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..64))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is an 'alias' name for the interface as
specified by a network manager, and provides a non-volatile
'handle' for the interface.
ifAlias OBJECT-TYPE SYNTAX DisplayString(SIZE(0 .64))マックス-ACCESSは「このオブジェクトは、指定されるとしてのネットワークマネージャによるインタフェースへの'別名'名であり、非揮発性の'ハンドル'をインタフェースに提供すること」をSTATUSの現在の記述に読書して書きます。
On the first instantiation of an interface, the value of
ifAlias associated with that interface is the zero-length
string. As and when a value is written into an instance of
ifAlias through a network management set operation, then the
agent must retain the supplied value in the ifAlias instance
associated with the same interface for as long as that
interface remains instantiated, including across all re-
initializations/reboots of the network management system,
including those which result in a change of the interface's
ifIndex value.
インタフェースの最初の具体化では、そのインタフェースに関連しているifAliasの値はゼロ長ストリングです。 値がネットワークマネージメント集合演算でifAliasのインスタンスに書かれると、次に、そのインタフェースが例示されたままで残っている限り、エージェントは同じインタフェースに関連しているifAliasインスタンスにおける供給値を保有しなければなりません、同じくらいそして横切ってインタフェースのifIndex価値の変化をもたらすものを含むネットワーク管理システムのすべての再初期化処理/リブートを含んでいて
An example of the value which a network manager might store
in this object for a WAN interface is the (Telco's) circuit
number/identifier of the interface.
ネットワークマネージャがこのオブジェクトにWANインタフェースとして保存するかもしれない価値に関する例はインタフェースに関する(通信業者のもの)回路番号/識別子です。
Some agents may support write-access only for interfaces
having particular values of ifType. An agent which supports
write access to this object is required to keep the value in
non-volatile storage, but it may limit the length of new
values depending on how much storage is already occupied by
the current values for other interfaces."
::= { ifXEntry 18 }
エージェントの中にはインタフェースだけにアクセスを書いている有がifTypeの特定の値であるとサポートする人もいるかもしれません。 「それのサポートがこのオブジェクトへのアクセスを書くエージェントが非揮発性記憶装置で値を保つのに必要ですが、どのくらいのストレージが現行価値で既に他のインタフェースに占領されるかに依存する新しい値の長さを制限するかもしれません。」 ::= ifXEntry18
ifCounterDiscontinuityTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime on the most recent occasion at which
any one or more of this interface's counters suffered a
discontinuity. The relevant counters are the specific
instances associated with this interface of any Counter32 or
ifCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「いくらかものかこの一層のインタフェースのカウンタが不連続を受けた最新の時のsysUpTimeの値。」 または関連カウンタがどんなCounter32のこのインタフェースにも関連している特定のインスタンスである。
McCloghrie & Kastenholz Standards Track [Page 44] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[44ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
Counter64 object contained in the ifTable or ifXTable. If
no such discontinuities have occurred since the last re-
initialization of the local management subsystem, then this
object contains a zero value."
::= { ifXEntry 19 }
Counter64はifTableかifXTableに含まれた状態で反対します。 「現地管理職者サブシステムの最後の再初期化以来どれかそのような不連続が起こっていないなら、このオブジェクトはaゼロ値を含んでいます。」 ::= ifXEntry19
-- The Interface Stack Group -- -- Implementation of this group is optional, but strongly recommended -- for all systems --
-- Interface Stack Group----このグループの実装は、任意ですが、すべてのシステムに、強くお勧めです--
ifStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table containing information on the relationships
between the multiple sub-layers of network interfaces. In
particular, it contains information on which sub-layers run
'on top of' which other sub-layers, where each sub-layer
corresponds to a conceptual row in the ifTable. For
example, when the sub-layer with ifIndex value x runs over
the sub-layer with ifIndex value y, then this table
contains:
「ネットワークの複数の副層の間の関係のテーブルの含んでいる情報は連結する」ifStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfStackEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 特に、それは副層が各副層がifTableの概念的な行に対応するその他の副層'上'を動く情報を含んでいます。 例えば、そして、ifIndex値xがある副層がifIndex値yで副層をひくとき、このテーブルは以下を含んでいます。
ifStackStatus.x.y=active
ifStackStatus.x. y=アクティブです。
For each ifIndex value, I, which identifies an active
interface, there are always at least two instantiated rows
in this table associated with I. For one of these rows, I
is the value of ifStackHigherLayer; for the other, I is the
value of ifStackLowerLayer. (If I is not involved in
multiplexing, then these are the only two rows associated
with I.)
それぞれのifIndex値、アクティブなインタフェースを特定するIのために、少なくとも2つの例示された行がこれらの行のI.For1に関連しているこのテーブルにいつもあって、IはifStackHigherLayerの値です。 もう片方のために、私はifStackLowerLayerの値です。 (私がマルチプレクシングにかかわらないなら、これらはI.に関連している唯一の2つの行です)
For example, two rows exist even for an interface which has
no others stacked on top or below it:
例えば、2つの行が先端の上、または、それの下で他のものを全く積み重ねないインタフェースにさえ存在しています:
ifStackStatus.0.x=active
ifStackStatus.x.0=active "
::= { ifMIBObjects 2 }
=アクティブなifStackStatus.0.x ifStackStatus.x.0=アクティブである、「:、:、」= ifMIBObjects2
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
ifStackEntry OBJECT-TYPE SYNTAX IfStackEntryのマックス-ACCESSのアクセスしやすくないSTATUS海流
McCloghrie & Kastenholz Standards Track [Page 45] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[45ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer runs on 'top' of the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
記述、「2つのサブ層の間の特定の関係に関する情報、1つの副層が走る指定'は'もう片方の副層」を付けます。 「各副層はifTableの概念的な行に対応しています。」 ifStackHigherLayer、ifStackLowerLayerに索引をつけてください:、:= ifStackTable1
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer InterfaceIndexOrZero,
ifStackLowerLayer InterfaceIndexOrZero,
ifStackStatus RowStatus
}
IfStackEntry:、:= 系列ifStackHigherLayer InterfaceIndexOrZero、ifStackLowerLayer InterfaceIndexOrZero、ifStackStatus RowStatus
ifStackHigherLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher sub-layer
of the relationship, i.e., the sub-layer which runs on 'top'
of the sub-layer identified by the corresponding instance of
ifStackLowerLayer. If there is no higher sub-layer (below
the internetwork layer), then this object has the value 0."
::= { ifStackEntry 1 }
「すなわち、関係の、より高い副層、'先端'で走る副層の副層に対応するifIndexの値はifStackLowerLayerの対応するインスタンスで特定した」ifStackHigherLayer OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「どんなより高い副層(インターネットワーク層の下における)もなければ、このオブジェクトには、値0があります。」 ::= ifStackEntry1
ifStackLowerLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-layer
of the relationship, i.e., the sub-layer which runs 'below'
the sub-layer identified by the corresponding instance of
ifStackHigherLayer. If there is no lower sub-layer, then
this object has the value 0."
::= { ifStackEntry 2 }
ifStackLowerLayer OBJECT-TYPE SYNTAX InterfaceIndexOrZeroのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「すなわち、関係の低級副層に対応するifIndexの値、副層がifStackHigherLayerの対応するインスタンスで特定した'below'を実行する副層。」 「どんな低級副層もなければ、このオブジェクトには、値0があります。」 ::= ifStackEntry2
ifStackStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
ifStackStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。
McCloghrie & Kastenholz Standards Track [Page 46] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[46ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"The status of the relationship between two sub-layers.
「2つの副層の間の関係の状態。」
Changing the value of this object from 'active' to
'notInService' or 'destroy' will likely have consequences up
and down the interface stack. Thus, write access to this
object is likely to be inappropriate for some types of
interfaces, and many implementations will choose not to
support write-access for any type of interface."
::= { ifStackEntry 3 }
このオブジェクトの値を'アクティブ'から'notInService'か'破壊'に変えると、結果はおそらく上下にインタフェーススタックに持たれるでしょう。 「その結果、おそらく不適当であることになっていこれが、反対するなるように何人かのタイプのインタフェースにアクセスを書いてください。そうすれば、多くの実装が、いずれのためにもアクセスを書いているタイプのインタフェースをサポートしないのを選ぶでしょう。」 ::= ifStackEntry3
ifStackLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last change of
the (whole) interface stack. A change of the interface
stack is defined to be any creation, deletion, or change in
value of any instance of ifStackStatus. If the interface
stack has been unchanged since the last re-initialization of
the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 6 }
「(全体)のインタフェースの最後の変化時点のsysUpTimeの値は積み重ねる」ifStackLastChange OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 インタフェーススタックの変化は、どんな作成、削除であるかifStackStatusのどんなインスタンスの値でも変化するようにも定義されます。 「企業内情報通信網管理サブシステムの最後の再初期化以来インタフェーススタックが変わりがないなら、このオブジェクトはaゼロ値を含んでいます。」 ::= ifMIBObjects6
-- Generic Receive Address Table -- -- This group of objects is mandatory for all types of -- interfaces which can receive packets/frames addressed to -- more than one address. -- -- This table replaces the ifExtnsRcvAddr table. The main -- difference is that this table makes use of the RowStatus -- textual convention, while ifExtnsRcvAddr did not.
-- ジェネリックReceive Address Table----オブジェクトのこのグループは--缶が扱われたパケット/フレームを受けるインタフェースより--1つ以上のアドレスのすべてのタイプに義務的です。 -- -- このテーブルはifExtnsRcvAddrテーブルを取り替えます。 メイン--違いはこのテーブルはRowStatusを利用します--ifExtnsRcvAddrがそうしなかった間の原文のコンベンションということです。
ifRcvAddressTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains an entry for each address (broadcast,
multicast, or uni-cast) for which the system will receive
packets/frames on a particular interface, except as follows:
ifRcvAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IfRcvAddressEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「このテーブルはシステムが特定のインタフェースでパケット/フレームを受ける各アドレス(放送、マルチキャスト、またはユニキャスト)のためのエントリーを含んでいます、以下の通りを除いて」
- for an interface operating in promiscuous mode, entries
are only required for those addresses for which the system
would receive frames were it not operating in promiscuous
mode.
- 無差別なモードで作動するインタフェースに関しては、エントリーが無差別なモードで作動していないならシステムがフレーム搬入するそれらのアドレスに必要であるだけです。
McCloghrie & Kastenholz Standards Track [Page 47] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[47ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
- for 802.5 functional addresses, only one entry is
required, for the address which has the functional address
bit ANDed with the bit mask of all functional addresses for
which the interface will accept frames.
- 802.5の機能アドレスに、1つのエントリーだけが必要です、インタフェースがフレームを受け入れるすべての機能アドレスの噛み付いているマスクがある機能アドレスビットANDedを持っているアドレスのために。
A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address."
::= { ifMIBObjects 4 }
「通常、システムはソースアドレスとしてこのテーブルでエントリーに一致しているどんなユニキャストアドレスも使用できます。」 ::= ifMIBObjects4
ifRcvAddressEntry OBJECT-TYPE
SYNTAX IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of objects identifying an address for which the
system will accept packets/frames on the particular
interface identified by the index value ifIndex."
INDEX { ifIndex, ifRcvAddressAddress }
::= { ifRcvAddressTable 1 }
「オブジェクトがシステムが特定のインタフェースでパケット/フレームを受け入れるアドレスを特定するリストはインデックス価値のifIndexで特定した」ifRcvAddressEntry OBJECT-TYPE SYNTAX IfRcvAddressEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 ifIndex、ifRcvAddressAddressに索引をつけてください:、:= ifRcvAddressTable1
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
IfRcvAddressEntry:、:= 系列ifRcvAddressAddress PhysAddress、ifRcvAddressStatus RowStatus、ifRcvAddressType整数
ifRcvAddressAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An address for which the system will accept packets/frames
on this entry's interface."
::= { ifRcvAddressEntry 1 }
ifRcvAddressAddress OBJECT-TYPE SYNTAX PhysAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「システムがこのエントリーのインタフェースでパケット/フレームを受け入れるアドレス。」 ::= ifRcvAddressEntry1
ifRcvAddressStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to create and delete rows in the
ifRcvAddressTable."
ifRcvAddressStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトはifRcvAddressTableの行を作成して、削除するのに使用されます」。
::= { ifRcvAddressEntry 2 }
::= ifRcvAddressEntry2
ifRcvAddressType OBJECT-TYPE
SYNTAX INTEGER {
ifRcvAddressTypeオブジェクト・タイプ構文整数
McCloghrie & Kastenholz Standards Track [Page 48] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[48ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
other(1),
volatile(2),
nonVolatile(3)
}
他の(1)、揮発性の(2)、nonVolatile(3)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object has the value nonVolatile(3) for those entries
in the table which are valid and will not be deleted by the
next restart of the managed system. Entries having the
value volatile(2) are valid and exist, but have not been
saved, so that will not exist after the next restart of the
managed system. Entries having the value other(1) are valid
and exist but are not classified as to whether they will
continue to exist after the next restart."
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトは、有効なテーブルにそれらのエントリーへの値のnonVolatile(3)を持って、管理されたシステムの次の再開で削除されないでしょう」。 値の揮発性の(2)を持っているエントリーが、有効であり、存在しますが、それが管理されたシステムの次の再開の後に存在しないように、貯蓄されないでください。 「値の他の(1)を持っているエントリーが、有効であり、存在していますが、それらが次の再開の後に存続するかどうかに関して分類されません。」
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }
DEFVAL、揮発性:、:= ifRcvAddressEntry3
-- definition of interface-related traps.
-- インタフェース関連の罠の定義。
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus."
::= { snmpTraps 3 }
linkDown NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「検出されて、linkDown罠が、エージェントの役割における代理のSNMP実体がそうしたのを意味する、通信リンクの1つのifOperStatusオブジェクトはある他の状態(しかし、いずれのnotPresent状態からも、そうしない)から下に状態に入ろうとしています」 「この他の状態はifOperStatusの含まれている値によって示されます。」 ::= snmpTraps3
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
linkUp NOTIFICATION-TYPE OBJECTS、ifIndex、ifAdminStatus、ifOperStatus、STATUSの現在の記述、「検出されて、linkUp罠が、エージェントの役割における代理のSNMP実体がそうしたのを意味する、通信リンクの1つのifOperStatusオブジェクトは、状態を低くして、ある他の状態に移行しました(しかし、いずれのnotPresent状態にもそうしません)」 「この他の状態はifOperStatusの含まれている値によって示されます。」 ::= snmpTraps4
-- conformance information
-- 順応情報
McCloghrie & Kastenholz Standards Track [Page 49] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[49ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifConformanceオブジェクト識別子:、:= ifMIB2
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
ifGroupsオブジェクト識別子:、:= ifConformance1ifCompliancesオブジェクト識別子:、:= ifConformance2
-- compliance statements
-- 承諾声明
ifCompliance3 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which have
network interfaces."
ifCompliance3 MODULE-COMPLIANCE STATUSの現在の記述、「ネットワークを持っているSNMP実体のための承諾声明は連結します」。
MODULE -- this module
MANDATORY-GROUPS { ifGeneralInformationGroup,
linkUpDownNotificationsGroup }
MODULE--このモジュールMANDATORY-GROUPSifGeneralInformationGroup、linkUpDownNotificationsGroup
-- The groups: -- ifFixedLengthGroup -- ifHCFixedLengthGroup -- ifPacketGroup -- ifHCPacketGroup -- ifVHCPacketGroup -- are mutually exclusive; at most one of these groups is implemented -- for a particular interface. When any of these groups is implemented -- for a particular interface, then ifCounterDiscontinuityGroup must -- also be implemented for that interface.
-- グループ: -- ifFixedLengthGroup--ifHCFixedLengthGroup--ifPacketGroup--ifHCPacketGroup(ifVHCPacketGroup)は互いに排他的です。 高々、これらのグループの1つは実装されます--特定のインタフェースに。 また、これらのグループのどれかが実装された(特定のインタフェースに関して、次に、ifCounterDiscontinuityGroupはそうしなければなりません)ら、そのインタフェースに実装されてください。
GROUP ifFixedLengthGroup
DESCRIPTION
"This group is mandatory for those network interfaces which
are character-oriented or transmit data in fixed-length
transmission units, and for which the value of the
corresponding instance of ifSpeed is less than or equal to
20,000,000 bits/second."
GROUP ifFixedLengthGroup記述、「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送って、ifSpeedの対応するインスタンスの値が2000万ビット/秒以下であるそれらのネットワーク・インターフェースに義務的です」。
GROUP ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory for those network interfaces which
are character-oriented or transmit data in fixed-length
transmission units, and for which the value of the
corresponding instance of ifSpeed is greater than 20,000,000
bits/second."
GROUP ifHCFixedLengthGroup記述、「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送って、ifSpeedの対応するインスタンスの値が2000万ビット/秒以上であるそれらのネットワーク・インターフェースに義務的です」。
GROUP ifPacketGroup
DESCRIPTION
グループifPacketGroup記述
McCloghrie & Kastenholz Standards Track [Page 50] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[50ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"This group is mandatory for those network interfaces which
are packet-oriented, and for which the value of the
corresponding instance of ifSpeed is less than or equal to
20,000,000 bits/second."
「このグループはパケット指向であり、ifSpeedの対応するインスタンスの値が2000万ビット/秒以下であるそれらのネットワーク・インターフェースに義務的です。」
GROUP ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are packet-oriented and for which the value of the
corresponding instance of ifSpeed is greater than 20,000,000
bits/second but less than or equal to 650,000,000
bits/second."
GROUP ifHCPacketGroup記述、「このグループはifSpeedの対応するインスタンスの値が2000万ビット以上/パケット指向であり、秒にもかかわらず、6億5000万ビット/秒以下であるそれらのネットワーク・インターフェースだけに義務的です」。
GROUP ifVHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are packet-oriented and for which the value of the
corresponding instance of ifSpeed is greater than
650,000,000 bits/second."
GROUP ifVHCPacketGroup記述、「このグループはパケット指向であり、ifSpeedの対応するインスタンスの値が6億5000万ビット/秒以上であるそれらのネットワーク・インターフェースだけに義務的です」。
GROUP ifCounterDiscontinuityGroup
DESCRIPTION
"This group is mandatory for those network interfaces that
are required to maintain counters (i.e., those for which one
of the ifFixedLengthGroup, ifHCFixedLengthGroup,
ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup is
mandatory)."
GROUP ifCounterDiscontinuityGroup記述、「このグループはカウンタ(すなわち、ifFixedLengthGroupでは、ifHCFixedLengthGroup、ifPacketGroup、ifHCPacketGroup、またはifVHCPacketGroupが義務的であるそれら)を維持するのに必要であるそれらのネットワーク・インターフェースに義務的です」。
GROUP ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by the
media-specific MIBs. Media-specific MIBs must define the
exact meaning, use, and semantics of the addresses in this
group."
GROUP ifRcvAddressGroup記述、「メディア特有のMIBsはこのグループの適用性を定義しなければなりません」。 「メディア特有のMIBsはこのグループでアドレスの正確な意味、使用、および意味論を定義しなければなりません。」
OBJECT ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifPromiscuousMode MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifAdminStatus
オブジェクトifAdminStatus
McCloghrie & Kastenholz Standards Track [Page 51] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[51ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the value
testing(3)."
(2)への(1)へのSYNTAX INTEGER、MIN-ACCESS書き込み禁止記述、「書く、アクセスが必要でなく、値のテスト(3)のサポートである、」
OBJECT ifAlias
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifAlias MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
::= { ifCompliances 3 }
::= ifCompliances3
-- units of conformance
-- ユニットの順応
ifGeneralInformationGroup OBJECT-GROUP
OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName, ifNumber, ifAlias,
ifTableLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information applicable to
all network interfaces."
::= { ifGroups 10 }
ifGeneralInformationGroup OBJECT-GROUP OBJECTS、ifIndex、ifDescr、ifType、ifSpeed、ifPhysAddress、ifAdminStatus、ifOperStatus、ifLastChange、ifLinkUpDownTrapEnable、ifConnectorPresent、ifHighSpeed、ifName、ifNumber、ifAlias、ifTableLastChange、「オブジェクトがすべてのネットワークに適切な情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups10
-- the following five groups are mutually exclusive; at most -- one of these groups is implemented for any interface
-- 以下の5つのグループが互いに排他的です。 高々、これらのグループの1つはどんなインタフェースにも実装されます。
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) character-oriented or fixed-length-transmission
network interfaces."
::= { ifGroups 2 }
ifFixedLengthGroup OBJECT-GROUP OBJECTS、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、STATUSの現在の記述、「キャラクタ指向の、または、長さの送電網を固定している非高速(非高速インタフェースは2000万ビット/秒以下の速度で送受信される)インタフェースに特定の情報を提供するオブジェクトの収集。」 ::= ifGroups2
ifHCFixedLengthGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
ifHCFixedLengthGroup OBJECT-GROUP OBJECTS、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、STATUSの現在の記述
McCloghrie & Kastenholz Standards Track [Page 52] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[52ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second) character-
oriented or fixed-length-transmission network interfaces."
::= { ifGroups 3 }
「キャラクタが適応させた高速(2000万ビット/秒以上)か固定長さの送電網に特定の情報を提供するオブジェクトの収集は連結します。」 ::= ifGroups3
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 4 }
ifPacketGroup OBJECT-GROUP OBJECTS、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode、「オブジェクトが非高速(非高速インタフェースは2000万ビット/秒以下の速度で送受信される)パケット指向のネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups4
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second but less
than or equal to 650,000,000 bits/second) packet-oriented
network interfaces."
::= { ifGroups 5 }
ifHCPacketGroupオブジェクト群対象、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts、ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode; 「オブジェクトが高速(2000万ビット以上/秒にもかかわらず、6億5000万ビット/秒以下)パケット指向のネットワークに特定の情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups5
ifVHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
ifHCInBroadcastPkts, ifHCOutUcastPkts,
ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifVHCPacketGroupオブジェクト群対象、ifHCInUcastPkts、ifHCInMulticastPkts、ifHCInBroadcastPkts、ifHCOutUcastPkts、ifHCOutMulticastPkts、ifHCOutBroadcastPkts、ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、ifInUnknownProtos、ifInErrors、ifOutErrors、ifMtu、ifInUcastPkts、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、ifOutUcastPkts、ifOutMulticastPkts
McCloghrie & Kastenholz Standards Track [Page 53] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[53ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
higher speed (greater than 650,000,000 bits/second) packet-
oriented network interfaces."
::= { ifGroups 6 }
ifOutBroadcastPkts、ifOutDiscards、ifPromiscuousMode STATUSの現在の記述、「より高い速度(6億5000万ビット/秒以上)パケットに特定の情報を提供するオブジェクトの収集はネットワーク・インターフェースを適応しました」。 ::= ifGroups6
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
ifRcvAddressGroup OBJECT-GROUP OBJECTS、ifRcvAddressStatus、ifRcvAddressType、「オブジェクトが倍数の情報を提供する収集はインタフェースが受けるものを扱う」STATUSの現在の記述。 ::= ifGroups7
ifStackGroup2 OBJECT-GROUP
OBJECTS { ifStackStatus, ifStackLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 11 }
ifStackGroup2 OBJECT-GROUP OBJECTS、ifStackStatus、ifStackLastChange、「オブジェクトがMIB-IIのレイヤリングの情報を提供する収集は連結する」STATUSの現在の記述。 ::= ifGroups11
ifCounterDiscontinuityGroup OBJECT-GROUP
OBJECTS { ifCounterDiscontinuityTime }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
interface counter discontinuities."
::= { ifGroups 13 }
ifCounterDiscontinuityGroup OBJECT-GROUP OBJECTS ifCounterDiscontinuityTime、STATUSの現在の記述、「カウンタ不連続を連結するように特定の情報を提供するオブジェクトの収集。」 ::= ifGroups13
linkUpDownNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { linkUp, linkDown }
STATUS current
DESCRIPTION
"The notifications which indicate specific changes in the
value of ifOperStatus."
::= { ifGroups 14 }
linkUpDownNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS、linkUp、linkDown、STATUSの現在の記述、「ifOperStatusの値における特定の変化を示す通知。」 ::= ifGroups14
-- Deprecated Definitions - Objects
-- 推奨しない定義--オブジェクト
-- -- The Interface Test Table -- -- This group of objects is optional. However, a media-specific
-- -- Interface Test Table----オブジェクトのこのグループは任意です。 しかしながら、メディア詳細
McCloghrie & Kastenholz Standards Track [Page 54] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[54ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
-- MIB may make implementation of this group mandatory. -- -- This table replaces the ifExtnsTestTable --
-- MIBはこのグループの実装を義務的にするかもしれません。 -- -- このテーブルはifExtnsTestTableを取り替えます--
ifTestTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfTestEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This table contains one entry per interface. It defines
objects which allow a network manager to instruct an agent
to test an interface for various faults. Tests for an
interface are defined in the media-specific MIB for that
interface. After invoking a test, the object ifTestResult
can be read to determine the outcome. If an agent can not
perform the test, ifTestResult is set to so indicate. The
object ifTestCode can be used to provide further test-
specific or interface-specific (or even enterprise-specific)
information concerning the outcome of the test. Only one
test can be in progress on each interface at any one time.
If one test is in progress when another test is invoked, the
second test is rejected. Some agents may reject a test when
a prior test is active on another interface.
「このテーブルは1インタフェースあたり1つのエントリーに含む」ifTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfTestEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述。 それはネットワークマネージャが様々な欠点がないかどうかインタフェースをテストするようエージェントに命令できるオブジェクトを定義します。 インタフェースのためのテストはメディア特有のMIBでそのインタフェースと定義されます。 テストを呼び出した後に、結果を決定するためにオブジェクトifTestResultを読むことができます。 エージェントが働くことができないなら、テスト、ifTestResultは用意ができています。そのように、示します。 テストの結果に関して試しにさらに特有の、または、インタフェース特有の、そして、(企業特有さえ)の情報を提供するのにオブジェクトifTestCodeを使用できます。 1つのテストしかいかなる時も、各インタフェースで進行できません。 別のテストが呼び出されるとき、1つのテストが進行しているなら、2番目のテストは拒絶されます。 先のテストが別のインタフェースで活発であるときにテストを拒絶するエージェントもいるかもしれません。
Before starting a test, a manager-station must first obtain
'ownership' of the entry in the ifTestTable for the
interface to be tested. This is accomplished with the
ifTestId and ifTestStatus objects as follows:
テストを始める前に、マネージャステーションは、最初に、インタフェースがテストされるためにifTestTableでエントリーの'所有権'を得なければなりません。 ifTestIdとifTestStatusオブジェクトは以下の通りでこれは達成されます:
try_again:
get (ifTestId, ifTestStatus)
while (ifTestStatus != notInUse)
/*
* Loop while a test is running or some other
* manager is configuring a test.
*/
short delay
get (ifTestId, ifTestStatus)
}
_もう一度試みてください: (ifTestStatus!はnotInUseと等しいです)/**輪がテストが稼働かある他の*マネージャである間、テストを構成している間、得てください(ifTestId、ifTestStatus)。 */ショート遅れは(ifTestId、ifTestStatus)を得ます。
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
/**はたった今、使用されていません--競争しましょう。*だれかに会うのはそれを得ます。 */錠_値はifTestIdと等しいです。
if ( set(ifTestId = lock_value, ifTestStatus = inUse,
セットしてください。((ifTestIdは錠_値と等しく、ifTestStatusはinUseと等しいです。
McCloghrie & Kastenholz Standards Track [Page 55] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[55ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
ifTestOwner='私のIPアドレス') == 失敗) 別のマネージャがifTestEntryを手に入れた/**--碁*は再び再び*/gotoトライ_を試みます。
/*
* I have the lock
*/
set up any test parameters.
私が錠*/にどんなテストパラメタにも設定させる/**。
/*
* This starts the test
*/
set(ifTestType = test_to_run);
/、**これはテスト*/セットを始動します(ifTestTypeは_走行へのテスト_と等しいです)。
wait for test completion by polling ifTestResult
世論調査ifTestResultによるテスト完成を待ってください。
when test completes, agent sets ifTestResult
agent also sets ifTestStatus = 'notInUse'
テストが完成するいつ、エージェントセットifTestResultエージェントセットもifTestStatus='notInUse'
retrieve any additional test results, and ifTestId
あらゆる追加試験の成績、およびifTestIdを検索してください。
if (ifTestId == lock_value+1) results are valid
(ifTestId=錠_価値+1)結果が有効であるなら
A manager station first retrieves the value of the
appropriate ifTestId and ifTestStatus objects, periodically
repeating the retrieval if necessary, until the value of
ifTestStatus is 'notInUse'. The manager station then tries
to set the same ifTestId object to the value it just
retrieved, the same ifTestStatus object to 'inUse', and the
corresponding ifTestOwner object to a value indicating
itself. If the set operation succeeds then the manager has
obtained ownership of the ifTestEntry, and the value of the
ifTestId object is incremented by the agent (per the
semantics of TestAndIncr). Failure of the set operation
indicates that some other manager has obtained ownership of
the ifTestEntry.
マネージャステーションは最初に適切なifTestIdとifTestStatusオブジェクトの値を検索します、必要なら、定期的に検索を繰り返して、ifTestStatusの値が'notInUse'になるまで。 そして、マネージャステーションはそれがただ検索した値、'inUse'への同じifTestStatusオブジェクト、およびそれ自体を示す値への対応するifTestOwnerオブジェクトに同じifTestIdオブジェクトを設定しようとします。 集合演算が成功するなら、マネージャはifTestEntryの所有権を得ました、そして、ifTestIdオブジェクトの値はエージェント(TestAndIncrの意味論あたりの)によって増加されます。 集合演算の失敗は、ある他のマネージャがifTestEntryの所有権を得たのを示します。
Once ownership is obtained, any test parameters can be
setup, and then the test is initiated by setting ifTestType.
On completion of the test, the agent sets ifTestStatus to
'notInUse'. Once this occurs, the manager can retrieve the
results. In the (rare) event that the invocation of tests
by two network managers were to overlap, then there would be
a possibility that the first test's results might be
overwritten by the second test's results prior to the first
いったん所有権を得ると、どんなテストパラメタもセットアップであるかもしれません、そして、次に、テストは、ifTestTypeを設定することによって、開始されます。 テストの完成のときに、エージェントは'notInUse'にifTestStatusを設定します。 これがいったん起こると、マネージャは結果を検索できます。 そして、2つのネットワークマネージャによるテストの実施が重ね合わせることになっていた(まれ)のイベントには、一次テストの結果が1日以前2番目のテストの結果によって上書きされるかもしれない可能性があるでしょう。
McCloghrie & Kastenholz Standards Track [Page 56] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[56ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
results being read. This unlikely circumstance can be
detected by a network manager retrieving ifTestId at the
same time as retrieving the test results, and ensuring that
the results are for the desired request.
読まれる結果。 試験の成績を検索することと同時にifTestIdを検索して、結果が必要な要求のためのものであることを確実にするネットワークマネージャはこのありそうもない状況を検出できます。
If ifTestType is not set within an abnormally long period of
time after ownership is obtained, the agent should time-out
the manager, and reset the value of the ifTestStatus object
back to 'notInUse'. It is suggested that this time-out
period be 5 minutes.
所有権を得た後にifTestTypeが時間の異常に長い期間以内に用意ができていないなら、エージェントが用意ができるべきである、タイムアウト、マネージャ、およびifTestStatusオブジェクトの値が'notInUse'に支持するリセット。 このタイムアウトの期間が5分であると示唆されます。
In general, a management station must not retransmit a
request to invoke a test for which it does not receive a
response; instead, it properly inspects an agent's MIB to
determine if the invocation was successful. Only if the
invocation was unsuccessful, is the invocation request
retransmitted.
一般に、管理局はそれが応答を受けないテストを呼び出すという要求を再送してはいけません。 代わりに、それは、実施がうまくいったかどうか決定するために適切にエージェントのMIBを点検します。 実施が失敗していた場合にだけ、実施の要求は再送されますか?
Some tests may require the interface to be taken off-line in
order to execute them, or may even require the agent to
reboot after completion of the test. In these
circumstances, communication with the management station
invoking the test may be lost until after completion of the
test. An agent is not required to support such tests.
However, if such tests are supported, then the agent should
make every effort to transmit a response to the request
which invoked the test prior to losing communication. When
the agent is restored to normal service, the results of the
test are properly made available in the appropriate objects.
Note that this requires that the ifIndex value assigned to
an interface must be unchanged even if the test causes a
reboot. An agent must reject any test for which it cannot,
perhaps due to resource constraints, make available at least
the minimum amount of information after that test
completes."
::= { ifMIBObjects 3 }
いくつかのテストが、それらを実行するのにインタフェースがオフラインで取られるのが必要である、またはエージェントがテストの完成の後にリブートするのを必要とさえするかもしれません。 こういう事情ですから、テストを呼び出す管理局とのコミュニケーションはテストの完成の後まで失われるかもしれません。 エージェントは、そのようなテストをサポートするのに必要ではありません。 しかしながら、そのようなテストがサポートされるなら、エージェントは、損をしているコミュニケーションの前にテストを呼び出した要求への応答を伝えるためにあらゆる努力するべきです。 エージェントが通常のサービスに回復するとき、適切なオブジェクトで適切にテストの結果を利用可能にします。 これが、テストがリブートを引き起こしてもインタフェースに割り当てられたifIndex値が変わりがないに違いないのを必要とすることに注意してください。 「エージェントはそれが恐らくリソース規制のためテストが完成するその後の情報の有効な最小の量を作ることができないどんなテストも拒絶しなければなりません。」 ::= ifMIBObjects3
ifTestEntry OBJECT-TYPE
SYNTAX IfTestEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry containing objects for invoking tests on an
interface."
AUGMENTS { ifEntry }
::= { ifTestTable 1 }
「エントリー含有はインタフェースのテストを呼び出すために反対させる」ifTestEntry OBJECT-TYPE SYNTAX IfTestEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述。 ifEntryを増大させます:、:= ifTestTable1
IfTestEntry ::=
IfTestEntry:、:=
McCloghrie & Kastenholz Standards Track [Page 57] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[57ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
ifTestOwner OwnerString
}
系列ifTestId TestAndIncr、ifTestStatus整数、ifTestType AutonomousType、ifTestResult整数、ifTestCodeオブジェクト識別子、ifTestOwner OwnerString
ifTestId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object identifies the current invocation of the
interface's test."
::= { ifTestEntry 1 }
ifTestId OBJECT-TYPE SYNTAX TestAndIncrマックス-ACCESSは「このオブジェクトはインタフェースのテストの現在の実施を特定すること」をSTATUSの推奨しない記述に読書して書きます。 ::= ifTestEntry1
ifTestStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object indicates whether or not some manager currently
has the necessary 'ownership' required to invoke a test on
this interface. A write to this object is only successful
when it changes its value from 'notInUse(1)' to 'inUse(2)'.
After completion of a test, the agent resets the value back
to 'notInUse(1)'."
::= { ifTestEntry 2 }
notInUse(1)、inUse(2)が「マネージャには必要が現在あるかどうかを示これが反対するする'というマックス-ACCESSが、STATUS推奨しない記述を読書して書くifTestStatus OBJECT-TYPE SYNTAX INTEGER所有権が'このインタフェースのテストを呼び出すのが必要です」。 Aが単に書く、値を'notInUse(1)'から'inUse(2)'に変えるとき、このオブジェクトはうまくいっています。 「テストの完成の後に、エージェントは'notInUse(1)'に値をリセットして戻します。」 ::= ifTestEntry2
ifTestType OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"A control variable used to start and stop operator-
initiated interface tests. Most OBJECT IDENTIFIER values
assigned to tests are defined elsewhere, in association with
specific types of interface. However, this document assigns
a value for a full-duplex loopback test, and defines the
special meanings of the subject identifier:
ifTestType OBJECT-TYPE SYNTAX AutonomousTypeマックス-ACCESSは「制御変数が以前はよく始まっていました、そして、停止オペレータはインタフェーステストを開始したこと」をSTATUSの推奨しない記述に読書して書きます。 テストに割り当てられたほとんどのOBJECT IDENTIFIER値がほかの場所で特定のタイプのインタフェースと関連して定義されます。 しかしながら、このドキュメントは、全二重折返しテストのために値を割り当てて、対象の識別子の特別な意味を定義します:
noTest OBJECT IDENTIFIER ::= { 0 0 }
最もnoTestなオブジェクト識別子:、:= { 0 0 }
When the value noTest is written to this object, no action
is taken unless a test is in progress, in which case the
test is aborted. Writing any other value to this object is
このオブジェクトに値のnoTestを書いて、テストが進行していない場合、行動を全く取りません、その場合、テストを中止します。 このオブジェクトにいかなる他の値も書くのは、そうです。
McCloghrie & Kastenholz Standards Track [Page 58] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[58ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
only valid when no test is currently in progress, in which
case the indicated test is initiated.
テストが全く現在進行していないと有効であるだけであることで、その場合、示されたテストは開始されます。
When read, this object always returns the most recent value
that ifTestType was set to. If it has not been set since
the last initialization of the network management subsystem
on the agent, a value of noTest is returned."
::= { ifTestEntry 3 }
読まれると、このオブジェクトはいつもifTestTypeが用意ができていた最新の値を返します。 「エージェントにおけるネットワークマネージメントサブシステムの最後の初期化以来それを設定していないなら、noTestの値を返します。」 ::= ifTestEntry3
ifTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object contains the result of the most recently
requested test, or the value none(1) if no tests have been
requested since the last reset. Note that this facility
provides no provision for saving the results of one test
when starting another, as could be required if used by
multiple managers concurrently."
::= { ifTestEntry 4 }
ifTestResult OBJECT-TYPE SYNTAX INTEGER、システムの事情への(1)(テストがないのにもかかわらず、要求された成功(2)、inProgress(3)、notSupported(4)、unAbleToRun(5))当然のなにも(6)を中止して、(7)を失敗しなかった、マックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述、「(1) どんなテストも含んでいないならこのオブジェクトがなにもに最も最近要求されたテストの結果、または値を含んでいる、最後のリセット以来要求されている、」 「この施設が同時に複数のマネージャによって使用されるなら必要であるかもしれないように別のものを始めるときの1つのテストの結果を節約することへの支給を全く提供しないことに注意してください。」 ::= ifTestEntry4
ifTestCode OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object contains a code which contains more specific
information on the test result, for example an error-code
after a failed test. Error codes and other values this
object may take are specific to the type of interface and/or
test. The value may have the semantics of either the
AutonomousType or InstancePointer textual conventions as
defined in RFC 2579. The identifier:
ifTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述は「失敗したテストの後にテスト結果の、より特定の情報を含むコード、例えばエラーコードを含これが反対するしています」。 インタフェース、そして/または、テストのタイプに、このオブジェクトが取るかもしれないエラーコードと他の値は特定です。 値には、AutonomousTypeかInstancePointerの原文のコンベンションの意味論がRFC2579で定義されるようにあるかもしれません。 識別子:
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
testCodeUnknownオブジェクト識別子:、:= { 0 0 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }
「使用のために、どんな追加結果コードも利用可能でないなら、定義されます。」 ::= ifTestEntry5
McCloghrie & Kastenholz Standards Track [Page 59] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[59ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
ifTestOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"The entity which currently has the 'ownership' required to
invoke a test on this interface."
::= { ifTestEntry 6 }
ifTestOwner OBJECT-TYPE SYNTAX OwnerStringマックス-ACCESSは「現在このインタフェースのテストを呼び出すために'所有権'を必要とする実体」をSTATUSの推奨しない記述に読書して書きます。 ::= ifTestEntry6
-- Deprecated Definitions - Groups
-- 推奨しない定義--グループ
ifGeneralGroup OBJECT-GROUP
OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName }
STATUS deprecated
DESCRIPTION
"A collection of objects deprecated in favour of
ifGeneralInformationGroup."
::= { ifGroups 1 }
ifGeneralGroup OBJECT-GROUP OBJECTS、ifDescr、ifType、ifSpeed、ifPhysAddress、ifAdminStatus、ifOperStatus、ifLastChange、ifLinkUpDownTrapEnable、ifConnectorPresent、ifHighSpeed、ifName、STATUSの推奨しない記述、「ifGeneralInformationGroupを支持して推奨しないオブジェクトの収集。」 ::= ifGroups1
ifTestGroup OBJECT-GROUP
OBJECTS { ifTestId, ifTestStatus, ifTestType,
ifTestResult, ifTestCode, ifTestOwner }
STATUS deprecated
DESCRIPTION
"A collection of objects providing the ability to invoke
tests on an interface."
::= { ifGroups 8 }
ifTestGroup OBJECT-GROUP OBJECTS、ifTestId、ifTestStatus、ifTestType、ifTestResult、ifTestCode、ifTestOwner、「オブジェクトが呼び出す能力を提供する収集はインタフェースでテストする」STATUSの推奨しない記述。 ::= ifGroups8
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS deprecated
DESCRIPTION
"The previous collection of objects providing information on
the layering of MIB-II interfaces."
::= { ifGroups 9 }
ifStackGroup OBJECT-GROUP OBJECTS ifStackStatus、「オブジェクトがMIB-IIのレイヤリングの情報を提供する前の収集は連結する」STATUSの推奨しない記述。 ::= ifGroups9
ifOldObjectsGroup OBJECT-GROUP
OBJECTS { ifInNUcastPkts, ifOutNUcastPkts,
ifOutQLen, ifSpecific }
STATUS deprecated
DESCRIPTION
ifOldObjectsGroup OBJECT-GROUP OBJECTS、ifInNUcastPkts、ifOutNUcastPkts、ifOutQLen、ifSpecific、STATUSの推奨しない記述
McCloghrie & Kastenholz Standards Track [Page 60] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[60ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"The collection of objects deprecated from the original MIB-
II interfaces group."
::= { ifGroups 12 }
「オリジナルのMIB IIから推奨しないオブジェクトの収集はグループを連結します。」 ::= ifGroups12
-- Deprecated Definitions - Compliance
-- 推奨しない定義--承諾
ifCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"A compliance statement defined in a previous version of
this MIB module, for SNMP entities which have network
interfaces."
「承諾声明はネットワーク・インターフェースを持っているSNMP実体のためにこのMIBモジュールの旧バージョンで定義した」ifCompliance MODULE-COMPLIANCE STATUSの推奨しない記述。
MODULE -- this module
MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
MODULE--このモジュールMANDATORY-GROUPSifGeneralGroup、ifStackGroup
GROUP ifFixedLengthGroup
DESCRIPTION
"This group is mandatory for all network interfaces which
are character-oriented or transmit data in fixed-length
transmission units."
GROUP ifFixedLengthGroup記述、「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送るすべてのネットワーク・インターフェースに義務的です」。
GROUP ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are character-oriented or transmit data in fixed-
length transmission units, and for which the value of the
corresponding instance of ifSpeed is greater than 20,000,000
bits/second."
「長さのトランスミッション単位が固定されて、このグループは、それらのキャラクタ指向であることのネットワーク・インターフェースだけに義務的であるか、またはデータを送って、ifSpeedの対応するインスタンスの値は2000万ビット/秒である」GROUP ifHCFixedLengthGroup記述。
GROUP ifPacketGroup
DESCRIPTION
"This group is mandatory for all network interfaces which
are packet-oriented."
GROUP ifPacketGroup記述、「このグループはすべてのパケット指向であることのネットワーク・インターフェースに義務的です」。
GROUP ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are packet-oriented and for which the value of the
corresponding instance of ifSpeed is greater than
650,000,000 bits/second."
GROUP ifHCPacketGroup記述、「このグループはパケット指向であり、ifSpeedの対応するインスタンスの値が6億5000万ビット/秒以上であるそれらのネットワーク・インターフェースだけに義務的です」。
GROUP ifTestGroup
DESCRIPTION
"This group is optional. Media-specific MIBs which require
interface tests are strongly encouraged to use this group
for invoking tests and reporting results. A medium specific
MIB which has mandatory tests may make implementation of
GROUP ifTestGroup記述、「このグループは任意です」。 インタフェーステストを必要とするメディア特有のMIBsがテストを呼び出して、結果を報告するのにこのグループを使用するよう強く奨励されます。 義務的なテストを持っている中型の特定のMIBは実装を作るかもしれません。
McCloghrie & Kastenholz Standards Track [Page 61] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[61ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
this group mandatory."
「これは義務的な状態で分類されます。」
GROUP ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by the
media-specific MIBs. Media-specific MIBs must define the
exact meaning, use, and semantics of the addresses in this
group."
GROUP ifRcvAddressGroup記述、「メディア特有のMIBsはこのグループの適用性を定義しなければなりません」。 「メディア特有のMIBsはこのグループでアドレスの正確な意味、使用、および意味論を定義しなければなりません。」
OBJECT ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifPromiscuousMode MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifStackStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention need
be supported, specifically: active(1)."
書いてください。OBJECT ifStackStatus SYNTAX INTEGERのアクティブな(1)--、RowStatus MIN-ACCESS書き込み禁止記述の部分集合、「アクセスは必要ではありません、そして、RowStatusの原文のコンベンションのための6つの列挙された値の1つだけが明確にサポートされなければなりません:、」 「アクティブな(1)。」
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the value
testing(3)."
::= { ifCompliances 1 }
(2)への(1)へのOBJECT ifAdminStatus SYNTAX INTEGER、MIN-ACCESS書き込み禁止記述、「書く、アクセスが必要でなく、値のテスト(3)のサポートである、」 ::= ifCompliances1
ifCompliance2 MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"A compliance statement defined in a previous version of
this MIB module, for SNMP entities which have network
interfaces."
「承諾声明はネットワーク・インターフェースを持っているSNMP実体のためにこのMIBモジュールの旧バージョンで定義した」ifCompliance2 MODULE-COMPLIANCE STATUSの推奨しない記述。
MODULE -- this module
MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2,
ifCounterDiscontinuityGroup }
MODULE--このモジュールMANDATORY-GROUPSifGeneralInformationGroup、ifStackGroup2、ifCounterDiscontinuityGroup
GROUP ifFixedLengthGroup
DESCRIPTION
グループifFixedLengthGroup記述
McCloghrie & Kastenholz Standards Track [Page 62] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[62ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
"This group is mandatory for all network interfaces which
are character-oriented or transmit data in fixed-length
transmission units."
「このグループはキャラクタ指向である、または固定長トランスミッション単位のデータを送るすべてのネットワーク・インターフェースに義務的です。」
GROUP ifHCFixedLengthGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are character-oriented or transmit data in fixed-
length transmission units, and for which the value of the
corresponding instance of ifSpeed is greater than 20,000,000
bits/second."
「長さのトランスミッション単位が固定されて、このグループは、それらのキャラクタ指向であることのネットワーク・インターフェースだけに義務的であるか、またはデータを送って、ifSpeedの対応するインスタンスの値は2000万ビット/秒である」GROUP ifHCFixedLengthGroup記述。
GROUP ifPacketGroup
DESCRIPTION
"This group is mandatory for all network interfaces which
are packet-oriented."
GROUP ifPacketGroup記述、「このグループはすべてのパケット指向であることのネットワーク・インターフェースに義務的です」。
GROUP ifHCPacketGroup
DESCRIPTION
"This group is mandatory only for those network interfaces
which are packet-oriented and for which the value of the
corresponding instance of ifSpeed is greater than
650,000,000 bits/second."
GROUP ifHCPacketGroup記述、「このグループはパケット指向であり、ifSpeedの対応するインスタンスの値が6億5000万ビット/秒以上であるそれらのネットワーク・インターフェースだけに義務的です」。
GROUP ifRcvAddressGroup
DESCRIPTION
"The applicability of this group MUST be defined by the
media-specific MIBs. Media-specific MIBs must define the
exact meaning, use, and semantics of the addresses in this
group."
GROUP ifRcvAddressGroup記述、「メディア特有のMIBsはこのグループの適用性を定義しなければなりません」。 「メディア特有のMIBsはこのグループでアドレスの正確な意味、使用、および意味論を定義しなければなりません。」
OBJECT ifLinkUpDownTrapEnable
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifPromiscuousMode
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifPromiscuousMode MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT ifStackStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention need
be supported, specifically: active(1)."
書いてください。OBJECT ifStackStatus SYNTAX INTEGERのアクティブな(1)--、RowStatus MIN-ACCESS書き込み禁止記述の部分集合、「アクセスは必要ではありません、そして、RowStatusの原文のコンベンションのための6つの列挙された値の1つだけが明確にサポートされなければなりません:、」 「アクティブな(1)。」
McCloghrie & Kastenholz Standards Track [Page 63] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[63ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the value
testing(3)."
(2)への(1)へのOBJECT ifAdminStatus SYNTAX INTEGER、MIN-ACCESS書き込み禁止記述、「書く、アクセスが必要でなく、値のテスト(3)のサポートである、」
OBJECT ifAlias
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT ifAlias MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
::= { ifCompliances 2 }
::= ifCompliances2
END
終わり
7. Acknowledgements
7. 承認
This memo has been produced by the IETF's Interfaces MIB working- group.
このメモはIETFのInterfaces MIBの働くグループによって製作されました。
The original proposal evolved from conversations and discussions with many people, including at least the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop.
起案は少なくとも以下を含む多くの人々との会話と議論から発展しました: フレッド・ベイカー、テッド・ブルンナー、チャック・デーヴィン、ジェレミー・グリーン、マーシャル・ローズ、カイTesink、およびディーンThroop。
8. References
8. 参照
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[2] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[4] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[6]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
McCloghrie & Kastenholz Standards Track [Page 64] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[64ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[7]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, January 1998.
[11]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1998年1月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, January 1998.
[12] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1998年1月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[13] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SMPv3 Applications", RFC
2573, January 1998.
[14] レビとD.とマイヤーとP.とB.スチュワート、「SMPv3アプリケーション」、RFC2573、1998年1月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, January 1998.
[15] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1998年1月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[16] ブラドナー、S.、「Indicate Requirements LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[17] McCloghrie, K. and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17.
RFC 1213, March 1991.
[17]McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地--、MIB-II、」、STD17 1991年3月のRFC1213。
[18] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[18] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[19] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC
1229, May 1991.
[19] McCloghrie(K.、「ジェネリックインタフェースMIBへの拡大」、RFC1229)は1991がそうするかもしれません。
McCloghrie & Kastenholz Standards Track [Page 65] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[65ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
[20] ATM Forum Technical Committee, "LAN Emulation Client Management:
Version 1.0 Specification", af-lane-0044.000, ATM Forum,
September 1995.
[20] 気圧フォーラム専門委員会、「LANエミュレーション顧客管理:」 「バージョン1.0Specification」、af車線0044.000、ATM Forum、1995年9月。
[21] Stewart, B., "Definitions of Managed Objects for Character
Stream Devices using SMIv2", RFC 1658, July 1994.
[21] スチュワート、B.、「1994年7月にSMIv2"、RFC1658を使用するキャラクターストリームデバイスのための管理オブジェクトの定義。」
[22] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[22] ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[23] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces
Group of MIB-II", RFC 1573, January 1994.
[23]McCloghrieとK.とF.Kastenholz、「MIB-IIのインタフェースグループの発展」、RFC1573、1994年1月。
[24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[24] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
9. Security Considerations
9. セキュリティ問題
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
aがあります。読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
In particular, write-able objects allow an administrator to control the interfaces and to perform tests on the interfaces, and unauthorized access to these could cause a denial of service, or in combination with other (e.g., physical) security breaches, could cause unauthorized connectivity to a device.
管理者は、書きできるオブジェクトで、インタフェースを制御して、特に、インタフェースのテストを実行します、そして、これらへの不正アクセスがサービスの否定を引き起こす場合がありましたか、または他の(例えば、身体検査)機密保護違反と組み合わせて権限のない接続性をデバイスに引き起こす場合がありました。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
それ自体でSNMPv1は安全な環境ではありません。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトがこのMIBに安全なネットワークにだれに許容されているかに関してコントロールが全くありません。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended.
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model RFC2574[12]とViewのベースのAccess Control Model RFC2575[15]の使用はお勧めです。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
そして、本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
McCloghrie & Kastenholz Standards Track [Page 66] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[66ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
10. Authors' Addresses
10. 作者のアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
西タスマン・Driveサンノゼ、キースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706
Phone: 408-526-5260 EMail: kzm@cisco.com"
以下に電話をしてください。 408-526-5260 メールしてください: " kzm@cisco.com "
Frank Kastenholz Argon Networks 25 Porter Rd Littleton Ma 01460
フランクKastenholz Argonは25ポーター第リトルトンマ01460をネットワークでつなぎます。
Phone: (508)685-4000 EMail: kasten@argon.com
以下に電話をしてください。 (508)685-4000 メールしてください: kasten@argon.com
11. Changes from RFC 2233
11. RFC2233からの変化
Added linkUpDownNotificationsGroup.
linkUpDownNotificationsGroupを加えました。
Changed the status of the definition of OwnerString in this MIB to be deprecated, because it is only used by ifTestOwner, which is now deprecated, and because other MIBs should import OwnerString from RFC 1757 or its successors.
それが現在推奨しないifTestOwnerによって使用されるだけであり、他のMIBsがRFC1757かその後継者からのOwnerStringをインポートするはずであるので、推奨しなくなるようにこのMIBとのOwnerStringの定義の状態を変えました。
Added ifCompliance3 as a replacement for ifCompliance2 to omit the ifStackGroup2 group, and add linkUpDownNotificationsGroup. Also, corrected the omission of ifVHCPacketGroup, and typos in the DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup. Obsoleted ifCompliance2.
ifCompliance2がifStackGroup2を省略する交換としての加えられたifCompliance3はlinkUpDownNotificationsGroupを分類して、加えます。 また、ifVHCPacketGroupの省略、およびifHCPacketGroupとifFixedLengthGroupのDESCRIPTIONsの誤植を修正しました。 ifCompliance2を時代遅れにしました。
Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be InterfaceIndexOrZero.
InterfaceIndexOrZeroになるようにifStackHigherLayerとifStackLowerLayerの構文を変更しました。
Added requirement that media-specific MIB designers specify any special conditions concerning the counting of framing characters in ifInOctets and ifOutOctets.
メディア特有のMIBデザイナーがifInOctetsとifOutOctetsでの縁どりキャラクタの勘定に関してどんな特別な状態も指定するという要件を加えました。
Corrected a typo in the DESCRIPTION of the linkUp notification.
linkUp通知の記述における誤植を修正しました。
Modified the introductory SNMP Network Management Framework boilerplate text.
紹介しているSNMP Network Management Framework決まり文句のテキストを変更しました。
McCloghrie & Kastenholz Standards Track [Page 67] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[67ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
12. Notice on Intellectual Property
12. 知的所有権に関する通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
McCloghrie & Kastenholz Standards Track [Page 68] RFC 2863 The Interfaces Group MIB June 2000
McCloghrie&Kastenholz標準化過程[68ページ]RFC2863インタフェースはMIB2000年6月に分類されます。
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
McCloghrie & Kastenholz Standards Track [Page 69]
McCloghrie&Kastenholz標準化過程[69ページ]
一覧
スポンサーリンク
