[要約] RFC 2233は、SMIv2を使用したインターフェースグループMIBに関する規格です。このRFCの目的は、ネットワークデバイスのインターフェース情報を管理するための標準的なデータモデルを提供することです。
Network Working Group K. McCloghrie
Request for Comments: 2233 Cisco Systems
Obsoletes: 1573 F. Kastenholz
Category: Standards Track FTP Software
November 1997
The Interfaces Group MIB using SMIv2
SMIv2を使用したインターフェースグループMIB
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
Table of Contents
目次
1 Introduction .............................................. 2
2 The SNMP Network Management Framework ..................... 2
2.1 Object Definitions ...................................... 3
3 Experience with the Interfaces Group ...................... 3
3.1 Clarifications/Revisions ................................ 3
3.1.1 Interface Sub-Layers .................................. 4
3.1.2 Guidance on Defining Sub-layers ....................... 6
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 ........................................... 18
3.1.10 Addition of New ifType values ........................ 18
3.1.11 InterfaceIndex Textual Convention .................... 18
3.1.12 New states for IfOperStatus .......................... 19
3.1.13 IfAdminStatus and IfOperStatus ....................... 20
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 ...................... 24
3.1.18 All Values Must be Known ............................. 24
4 Media-Specific MIB Applicability .......................... 25
5 Overview .................................................. 26
6 Interfaces Group Definitions .............................. 26
7 Acknowledgements .......................................... 64
8 References ................................................ 64
9 Security Considerations ................................... 65
10 Authors' Addresses ....................................... 65
11 Full Copyright Statement ................................. 66
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.
このメモは、インターネットコミュニティのネットワーク管理プロトコルで使用するための管理情報ベース（MIB）の一部を定義します。特に、ネットワークインターフェイスの管理に使用される管理対象オブジェクトについて説明します。
This memo discusses the 'interfaces' group of MIB-II, 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 previous model used for the 'interfaces' group.
このメモは、MIB-IIの「インターフェース」グループ、特に、インターネットワーク層の下のさまざまなサブレイヤーを管理するための「インターフェース」グループと組み合わせて使用するための多数のメディア固有のMIBモジュールの定義から得られた経験について説明します。これは、「インターフェース」グループに使用された以前のモデル内のアーキテクチャー問題の明確化と拡張を指定します。
This memo also includes a MIB module. As well as including new MIB definitions to support the architectural extensions, this MIB module also re-specifies the 'interfaces' group of MIB-II in a manner that is both compliant to the SNMPv2 SMI and semantically-identical to the existing SNMPv1-based definitions.
このメモにはMIBモジュールも含まれています。このMIBモジュールは、アーキテクチャの拡張をサポートする新しいMIB定義を含むだけでなく、SNMPv2 SMIに準拠し、既存のSNMPv1ベースと意味的に同一の方法で、MIB-IIの「インターフェース」グループを再指定します。定義。
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [10].
このドキュメントのキーワード「MUST」と「MUST NOT」は、RFC 2119 [10]で説明されているように解釈されます。
The SNMP Network Management Framework presently consists of three major components. They are:
SNMPネットワーク管理フレームワークは現在、3つの主要コンポーネントで構成されています。彼らです：
o RFC 1902 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management.
o 管理の目的でオブジェクトの記述と命名に使用されるメカニズムであるSMIを定義するRFC 1902。
o STD 17, RFC 1213 defines MIB-II, the core set of managed objects for the Internet suite of protocols.
o STD 17、RFC 1213は、インターネットプロトコルスイートの管理対象オブジェクトのコアセットであるMIB-IIを定義しています。
o STD 15, RFC 1157 and RFC 1905 which define two versions of the protocol used for network access to managed objects.
o 管理対象オブジェクトへのネットワークアクセスに使用されるプロトコルの2つのバージョンを定義するSTD 15、RFC 1157およびRFC 1905。
The Framework permits new objects to be defined for the purpose of experimentation and evaluation.
フレームワークでは、実験と評価の目的で新しいオブジェクトを定義できます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to refer to the object type.
管理対象オブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想情報ストアを介してアクセスされます。 MIB内のオブジェクトは、SMIで定義された抽象構文記法1（ASN.1）のサブセットを使用して定義されます。特に、各オブジェクトオブジェクトタイプは、管理上割り当てられた名前であるOBJECT IDENTIFIERによって名前が付けられます。オブジェクトタイプとオブジェクトインスタンスは、オブジェクトの特定のインスタンス化を一意に識別するのに役立ちます。人間の便宜のため、記述子と呼ばれるテキスト文字列を使用してオブジェクトタイプを参照することがよくあります。
One of the strengths of internetwork-layer protocols such as IP [6] 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 [6]などのインターネットワーク層プロトコルの長所の1つは、どのネットワークインターフェースでも実行できるように設計されていることです。これを実現する際、IPは、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 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 [7].
これらのメディア固有のMIBモジュールを定義した経験から、MIB-IIによって定義されたモデルは、一部のタイプのメディア固有の管理には単純化しすぎたり、静的すぎたりすることがわかっています。その結果、これらのメディア固有のMIBモジュールの一部は、モデルの進化または緩和を前提としています。このメモは、モデルのその進化を文書化して標準化し、その進化によって生じたギャップを埋めます。このメモには、RFC 1229 [7]で文書化されているインターフェイスグループ拡張も組み込まれています。
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モデルに精通しておらず、新しいモデルの背後にある理論的根拠に興味がない読者は、これらの段落をスキップすることをお勧めします。
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の1つの概念的な行で表されている場合、メディア固有のMIBの特定の組み合わせにマップする特定の組み合わせには、ifTypeの列挙値が必要です。さらに、そのようなモデルには、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, 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.
関連する問題は、サブレイヤーの上方および下方多重化の問題です。上向き多重化の例は、MLP（Multi-Link-Procedure）です。これは、上記のサブレイヤーへの単一のポイントツーポイントリンクとして表示されることにより、複数のシリアル回線で負荷分散を提供します。下方多重化の例としては、PPPのいくつかのインスタンスがあり、それぞれが個別のX.25仮想回線内でフレーム化され、それらすべてが1つのフラクショナルT1チャネル上で、他のT1リンクの使用と同時に実行されます。 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つは、インターフェイスのすべてのサブレイヤーの1つの概念的な行の概念を保持し、各メディア固有のMIBモジュールに、「オブジェクト識別子」「ポインター」を通じて「上位」および「下位」サブレイヤーを識別させることでした。このスキームにはいくつかの欠点があります。上位/下位のポインタがメディア固有のMIBモジュールに含まれることになります。したがって、マネージャは、異なるMIBモジュール内の複数のポインタを検査しないと、インターフェースの構造を学習できませんでした。これは過度に複雑であり、マネージャが関連するすべてのメディア固有のMIBモジュールの知識を持っている場合にのみ可能です。 MIBモジュールはすべて、これらの新しい「ポインタ」を組み込む必要があります。このスキームでは、上向きおよび下向きの多重化の問題に適切に対処できません。最後に、サブレイヤーの組み合わせごとにifTypeの列挙値が必要になります。別の拒否されたソリューションも、インターフェイスのすべてのサブレイヤーの1つの概念的な行の概念を保持しましたが、「上位」および「下位」サブレイヤーを識別し、OBJECT IDENTIFIERへのオブジェクトポインターを含めるための新しい個別のMIBテーブルがありました。各サブレイヤーのメディア固有のMIBモジュール。事実上、ifTableの1つの概念的な行は、インターネットワーク層とワイヤーの間のサブ層の各組み合わせを表します。この方式には欠点は少ないですが、PPP over MLPなどのダウンストリーム多重化はまだサポートされていません。MLPは2つ（またはそれ以上）のシリアル回線を単一の物理インターフェイスとして上の層に表示するため、PPP over MLPが表示されるはずです。単一のインターフェースとしてインターネットワーク層に。対照的に、このスキームでは、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 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.
このメモで採用された解決策は、各サブレイヤーを表すためにifTableに個別の概念的な行を持ち、「上位」および「下位」サブを識別するための新しい個別のMIBテーブル（ifStackTable、セクション6を参照）を持つことです。 -レイヤーは、INTTableの「ポインタ」を介して、ifTableの適切な概念的な行を指します。このソリューションは、上向きと下向きの両方の多重化をサポートし、IANAifTypeからメディア固有のMIBへのマッピングにより、そのサブレイヤーのメディア固有のMIBモジュールを識別できるため、新しいテーブルを参照するだけで、レイヤーに関する情報を取得できます。それらの組み合わせではなく、各サブレイヤーのifTypeの列挙値が必要です。ただし、ifTableの一部のオブジェクトの説明（具体的には、ifType、ifPhysAddress、ifInUcastPkts、およびifOutUcastPkts）を一般化して、（ネットワークのすぐ下のサブレイヤーだけでなく）サブレイヤーに適用する必要があります。以前のレイヤー）に加えて、一般化された定義が特定のサブレイヤーに適用されない場合に使用するために適切な値を特定する必要があるいくつか（特に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: (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.
さらに、この採用されたソリューションでは、サブテーブルがifTableの概念的な行によってインストルメント化されているデバイスが、インターネットワークプロトコルがそのサブの上で（つまり、その上のレイヤーで）実行されているかどうかを認識する必要はありません。 -層。実際、インターフェイスで受信したパケットのカウンタは、「上位層プロトコルに配信された」数を数えるものとして定義されています。この「上位層」の意味には、次のものが含まれます。（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）インターフェイススタックの「最上位」にあるサブレイヤーのパケット転送を行わない上位プロトコルレイヤーへの配信。たとえば、この定義では、ローカルIPモジュールは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モジュールはシリアルインターフェイスの「上位層」になります。
(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）インターフェイススタックの「最上位」にあるサブレイヤーの場合、ネットワークプロトコルスタックの上位要素。たとえば、この定義では、ローカルIPモジュールはイーサネットインターフェイスの上位層と見なされます。
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, (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.
（1）インターフェースのグループのいずれも、エージェント内の他のインターフェースの多重化を実行しません。（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.
このような状況では、そのようなインターフェイスのグループのifTableに1つのエントリがあり、ネットワーク管理に表す必要のある内部構造は、特定のタイプのインターフェイスに固有の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).
上記の箇条書き2をifTableのifTypeオブジェクトに適用するには、意味のあるメディア固有のMIBと、インターフェイスのグループ全体に適用される意味のあるifType値が必要です。たとえば、メディア固有のMIBとHDLCとRS-232のifType値が別々ではない場合（組み合わせではなく）、HDLCサブレイヤーとRS-232サブレイヤーを単一のifTableエントリとして扱うことは適切ではありません。 。
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 [9].
上記を前提として、スタックの最下部が物理インターフェースであり（ifConnectorPresentの値が「true」）、インターフェーススタック（ifStackTable内）で発生する可能性のあるインターフェースにifIndex値を割り当てることが適切です。レイヤー3またはこのスタックの最上位を「指す」他のアプリケーション。スタックの一番上を指すアプリケーションの例は、Character MIB [9]です。
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.
あるデバイスのインターフェースのサブレイヤーは、別のデバイスの相互接続されたインターフェースのサブレイヤーと異なる場合があることに注意してください。たとえば、frameRelayServiceインターフェイスに接続されたフレームリレーDTEインターフェイスの場合、相互接続されたDTEおよびDCEインターフェイスには、異なるifType値とメディア固有のMIBがあります。
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に準拠した方法でMIBを自由にレイアウトできます。ただし、そうすることで、メディア固有のMIBは、MIBに使用されるサブレイヤーモデルを完全に指定し、そのモデルの開発に使用される前提条件、推論、および理論的根拠を提供する必要があります。
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モジュールが定義されているサブレイヤーのいくつかは、接続指向です（フレームリレー、X.25など）。経験上、そのようなMIBモジュールを定義するための各取り組みは、各仮想回線にifTableの個別の概念的な行が必要かどうかという問題を再検討することが示されています。これまでのこれらの取り組みのすべてではありませんが、ほとんどの場合、すべての仮想回線でifTableの1つの概念的な行を参照することを決定しています。
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の仕様でこの決定の根拠を提示する必要があります。
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の概念的な行全体で表される文字指向のサブレイヤーを持つことは適切ではないことがわかっています。
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).
さらに複雑なのは、一部のサブネットワーク技術が固定長の送信ユニットでデータを送信することです。そのような技術の一例は、セルリレー、特に固定長セルでデータを送信する非同期転送モード（ATM）です。このようなインターフェイスをパケットベースのインターフェイスとして表すと、パケット数といずれかの方向のオクテット数の関係が伝送ユニットのサイズ（セルのサイズなど）によって固定されている場合、冗長オブジェクトが生成されます。
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).
この問題の拒否された解決策は、ifTableを2つ（またはそれ以上）の新しいMIBテーブルに分割することです。すべてのインターフェース。 ifTableを実装するすべてのエージェント（つまり、ほぼすべての既存のSNMPエージェント）で変更が必要になるため、これは非常に望ましくありません。
The solution adopted in this memo builds upon the fact that compliance statements in SNMPv2 (in contrast to SNMPv1) refer to object groups, where object groups are explicitly defined by listing the objects they contain. Thus, in SNMPv2, 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.
このメモで採用されたソリューションは、SNMPv2のコンプライアンスステートメント（SNMPv1とは対照的）がオブジェクトグループを参照するという事実に基づいています。オブジェクトグループは、オブジェクトグループに含まれるオブジェクトをリストすることによって明示的に定義されます。したがって、SNMPv2では、すべてのインターフェースに1つ、特定のタイプのインターフェースに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 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.
したがって、このメモのセクション6には、SNMPv2に準拠し、既存のMIB-II定義と意味的に同等の方法で、MIB-IIの既存の「インターフェース」グループのオブジェクトの定義が含まれています。同等のセマンティクスで、BER（ "オンザワイヤー"）エンコーディングが変更されていない場合、これらの定義は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などのサブネットワークテクノロジーにも適用できるオブジェクトが含まれています。オクテットカウンターの他に、このタイプのインターフェイスに役立つ他のいくつかのカウンター（エラーカウンターなど）もありますが、現在はパケット指向であると定義されています。これに対応するために、これらのカウンターの定義は、文字指向のインターフェースと固定長伝送インターフェースに適用されるように一般化されています。
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モジュールでのみ維持できます。
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."
「その値の範囲は1とifNumberの値の間です。各インターフェイスの値は、少なくともエンティティのネットワーク管理システムの1つの再初期化から次の再初期化まで一定のままである必要があります。」
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の値に対するこの不変の要件は、効率的な管理に不可欠です。ただし、デバイスの数が増えると、ネットワークインターフェイスの動的な追加/削除が可能になります。この一例は、文字指向のポートで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.
ifNumberをifIndexの最大値に再定義することは、役に立たないため拒否されました。このような再定義には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のセマンティクスの小さな変更です。ただし、既存のすべてのエージェント実装はこの新しい定義に準拠しており、既存のエージェント実装および多くの既存のメディア固有のMIBへの変更を必要としないため、このメモでは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 SNMPv2's 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（およびSNMPv2の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 to turn out to be inadequate. Instead, implementors must choose what it means in their particular situation, subject to the following rules: (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.
インターフェースのifIndex値の（再初期化の間の）不変性の要件は、インターフェースが動的に削除された後、次の再初期化の後まで、動的に追加された*別の*インターフェースによってそのifIndex値が再利用されないようにすることで満たされます。ネットワーク管理システムの。これにより、動的に追加される可能性のあるすべてのインターフェースにifIndex値を（事前に）割り当てる必要がなくなります。 「異なる」インターフェースの正確な意味を定義するのは難しく、灰色の領域があります。このドキュメントでの企業の定義は、不適切であることが判明する可能性があります。代わりに、実装者は次のルールに従って、特定の状況でそれが何を意味するかを選択する必要があります。（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の値を更新する必要があります。この新しいオブジェクトを使用すると、管理アプリケーションは、連続するポーリングで取得されたカウンター値間の差を計算するときに、ifCounterDiscontinuityTimeの値が2つのポーリングで異なる計算された差を破棄する必要があります。 （このテストは、エージェントの再初期化を検出するための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 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.
この新しいオブジェクトの定義はifTableカウンターオブジェクトのセマンティクスの変更ですが、その幅広い展開と重要性のため、これらすべてのカウンターを非推奨にして再定義することは実際的ではありません。また、実装の調査は、多くのエージェントと管理アプリケーションが現在のセマンティクスのこの側面を正しく実装していないことを示しており（前述の厄介な問題のため）、そのような変更の実際的な影響は小さいです。したがって、この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 reinitialization 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エージェント）の場合、あるネーミングスコープのインターフェースを識別するifIndex値と別のネーミングスコープのインターフェースを識別する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).
ifIndexの値はifNumber未満に制限されているため、インターフェイスは小さな整数値で番号付けされています。これにより、人間は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エントリを設定すると、インターフェイスから物理ポートへのマッピングがますます問題になります。
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」を使用する場合、ifTableの対応するPPPおよびRS-232エントリのifNameオブジェクトの値はどちらも「wan1」になります。一方、ルータがPPPインターフェイスに「wan1.1」、RS-232ポートに「wan1.2」という名前を使用している場合、ifTable内の対応するPPPおよびRS-232エントリのifNameオブジェクトは値はそれぞれ「wan1.1」と「wan1.2」です。別の例として、他のいくつかの（プロキシされた）デバイスのインターフェースに関するSNMPクエリに応答するエージェントを考えます。そのようなプロキシされたデバイスが特定の識別子をインターフェースに関連付ける場合、この識別子をの値として使用することが適切です。この場合のローカルコンソールはプロキシされたデバイスのコンソールであるため、インターフェースのifName。
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名は不揮発性であるため、エージェントがインターフェースの新しいifIndex値を選択した場合でも、再起動後もインターフェースは割り当てられたifAlias値を保持する必要があります。
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ストリームでは、ifInOctetsが57分強でラップします。 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.
この問題に対する拒否された解決策は、カウンターをスケーリングすることでした。たとえば、ifInOctetsを変更して、たとえば1024バイトブロックの受信オクテットをカウントできます。カウントされたイベントの高いレートでは許容できる機能を提供しますが、低いレートでは問題が発生します。インターフェイスにトラフィックがほとんどない場合は、十分な数のイベントが発生してからスケーリングされたカウンタが増加するまでに、かなりの間隔がある可能性があります。その後、トラフィックは非常にバースト的であるように見え、ネットワークのパフォーマンスの誤った結論につながります。
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ビットのカウンターは廃止されていません。 64ビットカウンターは、32ビットカウンターが十分な容量を提供しない場合にのみ使用されます。つまり、32ビットカウンタのラップが速すぎる場合です。
For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be used. 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 used and 64-bit octet counters MUST be used. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be used.
20,000,000（2,000万）ビット/秒以下で動作するインターフェイスの場合、32ビットバイトとパケットカウンターを使用する必要があります。 20,000,000ビット/秒より速く、650,000,000ビット/秒より遅く動作するインターフェイスの場合、32ビットパケットカウンターを使用する必要があり、64ビットオクテットカウンターを使用する必要があります。 650,000,000ビット/秒以上で動作するインターフェイスでは、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 SNMPv2. 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ビットカウンターは、SNMPv2で導入された新機能です。それらのサポートが当面の間むらになることを期待することは理にかなっています。したがって、それらをできるだけ少ないシステムに制限したいと考えています。これは、事実上、64ビットカウンターをより高速なインターフェイスに制限する必要があることを意味します。イーサネット（10,000,000 bps）とトークンリング（16,000,000 bps）はかなり広く普及しているため、これらのインターフェイスに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,
- 10 Mbsイーサネット：57分、
- 16Mbs Token Ring: 36 minutes,
- 16Mbsトークンリング：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）64ビットパケットが650,000,000ビット/秒のリンクでバックツーバックで送信される場合、32ビットパケットカウンターは約57分で折り返します。
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.
余談ですが、1テラビット/秒（1,000 Gbs）のリンクでは、64ビットのオクテットカウンターが5年弱でラップします。逆に、64ビットカウンターを30分でラップするには、81,000,000テラビット/秒のリンクが必要です。テクノロジーは急速に進歩していますが、このリンク速度は少なくとも数年間は達成されず、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ビットカウンタが含まれています。
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倍の51 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オブジェクトは、インターフェースの速度を1,000,000（100万）ビット/秒単位で報告します。したがって、インターフェイスの実際の速度は、このオブジェクトによって報告された値のプラスまたはマイナス500,000ビット/秒になります。
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ビットオペレーションの要件が増加するため、その使用にはエージェントの追加の複雑さが必要になります。
(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）また、組み合わせると64ビット値になる「高32ビット」オブジェクトと「低32ビット」オブジェクトの作成も検討しました。これは単に、私たちがやろうとしていることに対して、非常に複雑に思えました。
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の値は、4,294,967,295ビット/秒より速いインターフェースのインターフェース速度の唯一のレポートになります。この速度では、ifHighSpeedの粒度は1,000,000ビット/秒になるため、エラーは1/4294、つまり約0.02％になります。これは妥当なようです。
(3) Adding a "scale" object, which would define the units which ifSpeed's value is.
（3）ifScaleの値の単位を定義する「スケール」オブジェクトを追加します。
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つの追加オブジェクトが必要です。 1つはスケーリングオブジェクト用、もう1つは現在のifSpeedを置き換えるためのものです。 ifSpeedのセマンティクスが大幅に変更され、新しいセマンティクスを理解しないマネージャーステーションが混乱するため、この後者のオブジェクトが必要になります。
In MIB-II, the ifTable counters for multicast and broadcast packets are combined as counters of non-unicast packets. In contrast, the ifExtensions MIB [7] 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 [7]は、マルチキャスト用に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.
RFC 1229で定義された出力ブロードキャストおよびマルチキャストカウンターの場合、それらの定義は、エラー/破棄されたパケットをカウントしなかったという点で、ifTableのパケットカウンターとは少し異なりました。したがって、このメモはより適切に調整された定義で新しいオブジェクトを定義します。上記で説明したように、64ビットの範囲を持つカウンターも必要です。
In the multi-layer interface model, each sub-layer for which there is an entry in the ifTable can generate linkUp/Down 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/Down occurrence.
マルチレイヤインターフェイスモデルでは、ifTableにエントリがある各サブレイヤがlinkUp / Downトラップを生成できます。インターフェースの状態変化はインターフェース全体（上から下、または下から上）に伝搬する傾向があるため、linkUp / Downの発生ごとに複数のトラップが生成される可能性があります。
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オブジェクトが追加されました。このオブジェクトを使用すると、マネージャはトラップの生成を対象のサブレイヤだけに制限できます。
The default setting should limit the number of traps generated to one per interface per linkUp/Down 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 / Downイベントごとにインターフェイスごとに1つに制限する必要があります。さらに、ネットワーク管理者にとって最も重要な状態変化は、インターフェイススタックの最下位レベルで発生するようです。したがって、デフォルトでは、インターフェースの最下位のサブレイヤーのみがトラップを生成するように指定します。
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で定義されるようになりました。これにより、このドキュメントの新しいバージョンを再発行することなく、追加の値をドキュメント化できます。 Internet Assigned Number Authority（IANA）は、さまざまなSNMP関連の番号を含むすべてのインターネット番号、特に新しいifType値の割り当てを担当します。
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のセマンティクスを簡単にインポートできるようになります。
Three new states have been added to ifOperStatus: 'dormant', 'notPresent', and 'lowerLayerDown'.
3つの新しい状態がifOperStatusに追加されました：「dormant」、「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:
休止状態は、関連するインターフェイスが実際にはパケットを渡す状態ではない（つまり、「アップ」ではない）が、「保留中」の状態であり、外部イベントを待機していることを示します。 「オンデマンド」インターフェースの場合、この新しい状態は、インターフェースがイベントによって起動状態になるのをインターフェースが待っている状況を識別します。このようなイベントの例は次のとおりです。
(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）リモートシステムにインターフェースへの接続を確立させる（例：スリップサーバーにダイヤルアップする）。
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つ以上がダウンしているためにこのインターフェースがダウンしていることを示します。
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 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.
ifAdminStatusがダウンに移行すると、通常、ifOperStatusもダウンに移行することに注意してください。この状況では、ifOperStatusの遷移がすぐに発生せず、特定の操作が完了してから「ダウン」するまでにわずかなタイムラグが発生する可能性があります。たとえば、パケットの送信を完了する必要がある場合があります。マネージャーステーションが特定のインターフェイスで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 presumably ifOperStatus will be down or notPresent.
インターフェーステーブルエントリが作成されるたびに（通常はシステムの初期化の結果として）、ifAdminStatusの関連インスタンスがダウンに設定され、おそらくifOperStatusがダウンまたは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:
インターフェースは、明示的な管理アクション（ifAdminStatusをupに設定するなど）の結果として、または管理対象システムの初期化プロセスの結果として、2つの方法で有効にできます。 ifAdminStatusがアップ状態に変化すると、関連するifOperStatusは次のいずれかを実行する必要があります。
(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）インターフェイススタック内の1つ以上のインターフェイスの状態が原因で、インターフェイスがアップ状態にならない場合にのみ、lowerLayerDown状態に変更します。
(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）何らかの理由でインターフェースの状態が確認できない場合は、unknown状態に変更します。
(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状態のままにします。
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の値は「up」で、スタック内の1つ以上のインターフェースが「up」であるためにパケットを渡すことができる場合、その下にある他のインターフェースが「down」、「dormant」、「」であるかどうかは関係ありません。 notPresent」、「lowerLayerDown」、「unknown」、または「testing」。
(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つ以上のインターフェースが「休止」であり、その下にある他のすべてのインターフェースが「ダウン」、「休止」、「notPresent」、「」の場合、ifOperStatusの値は「up」または「dormant」になる場合があります。 lowerLayerDown '、' unknown 'または' testing '。
(3) ifOperStatus has the value 'lowerLayerDown' while all interfaces below it in the stack are either 'down', 'notPresent', 'lowerLayerDown', or 'testing'.
（3）ifOperStatusの値が「lowerLayerDown」であるのに対し、スタック内でその下にあるすべてのインターフェースが「down」、「notPresent」、「lowerLayerDown」、または「testing」のいずれかである。
The exact definition of when linkUp and linkDown traps are generated has been changed to reflect the changes to ifAdminStatus and ifOperStatus.
linkUpおよびlinkDownトラップが生成されるタイミングの正確な定義が変更され、ifAdminStatusおよび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.
運用上の経験から、管理ステーションはインターフェイスがダウン状態であることに最も関係していることがわかり、この状態は障害を示している可能性があります。したがって、アップ状態またはダウン状態のいずれかに遷移する/から遷移を計測することは最も有用です。
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)!!
up状態への遷移またはup状態からの遷移の計測は拒否されました。これは、デマンドインターフェイスがupとdormantの間に多くの遷移を持ち、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以外の状態から）ダウン状態に移行します。エラー状態はおそらくネットワーク管理者にとって大きな関心事です。
(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 on just after ifOperStatus leaves, or just before it enters, the down state, respectively; except that LinkUp and linkDown traps never generated on transitions to/from the notPresent state.
したがって、このメモでは、LinkUpトラップとlinkDownトラップは、それぞれifOperStatusが終了した直後、またはダウン状態になる直前に生成されると定義しています。ただし、notPresent状態への遷移またはnotPresent状態からの遷移でLinkUpトラップおよびlinkDownトラップが生成されることはありません。
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.) 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.
この定義では、インターフェイスが1つしかないノードが、そのインターフェイスがダウンする前にlinkDownトラップを送信できることに注意してください。 （もちろん、障害状態のためにインターフェースがダウンしている場合、おそらくlinkDownトラップを正常に送信することはできません。）一部のインターフェースは、インターフェースを起動しようとするときにリンク「トレーニング」機能を実行します。そのようなインターフェースに欠陥がある場合、トレーニング機能は失敗し、インターフェースはダウンしたままになり、トレーニング機能は適切な間隔で繰り返される可能性があります。このトレーニング機能の実行中に、インターフェースがテスト状態であると見なされた場合、トレーニング機能の開始と終了ごとに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 rate- limit its generation of traps.
上記のifOperStatusの変化に対するlinkUp / linkDownトラップの生成の例外は、インターフェイスが「フラッピング」しているとき、つまり、アップ状態とダウン状態の間で急速に振動しているときに発生します。このような振動ごとにトラップが生成された場合、ネットワークとネットワーク管理システムは不要なトラップでいっぱいになります。このような状況では、エージェントはトラップの生成をレート制限する必要があります。
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:
ifSpecificのOBJECT IDENTIFIER値の元の定義は十分に明確ではありませんでした。その結果、実装者によって使用方法が異なり、混乱が生じました。一部の実装では、メディア固有のMIBを定義するOBJECT IDENTIFIERにifSpecificの値を設定します。つまり、以下の「foo」です。
foo OBJECT IDENTIFIER ::= { transmission 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）。後者に基づく定義は、各テーブルが独自の（異なる）インデックスを持つ複数のテーブルを含むメディア固有のMIBを許可しない限り、十分ではありません。
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は非推奨になりました。
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 [2] 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 [8] 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 [2]列がありません）。むしろ、特定のインターフェイスタイプがそのタイプのインターフェイスの動的な作成および/または削除をサポートしている場合、そのメディア固有のMIBには適切なRowStatusオブジェクトを含める必要があります（ATM LANエミュレーションクライアントMIB [8]の例を参照）これを行うMIB）。通常、このようなRowStatusオブジェクトが作成/削除されると、ifTableの概念的な行が副産物として表示/非表示になり、ifIndex値（エージェントが選択）がメディア固有のMIBの適切なオブジェクトに格納されます。 。
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 for SNMPv2).
エージェントが特定のインターフェースの1つ以上のオブジェクトの値を知らない状況がいくつかあります。そのようなすべての状況で、エージェントは誤った値でオブジェクトをインスタンス化してはなりません（MUST NOT）。むしろ、適切なエラー/例外条件（SNMPv2のnoSuchInstanceなど）で応答する必要があります。
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つ（または複数）によって定義された発生をカウントできない場合です。この状況では、エージェントは特定のカウンターをゼロなどの値でインスタンス化してはなりません（MUST NOT）。これを行うには、ゼロ値を読み取るネットワーク管理アプリケーションに誤った情報を提供し、イベントが発生していない（たとえば、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 [8]). 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が設定された値であり、デバイスがインターフェイスを介してメッセージを交換した後（後）に、設定された値を動的に学習する場合（ATM LANエミュレーション[8]など）。このような場合、値はifTableエントリがすでに作成されるまでわかりません。このような場合、値が不明なオブジェクトのインスタンスなしでifTableエントリを作成する必要があります。その後、値が既知になったときに、欠落しているオブジェクトをインスタンス化できます（たとえば、ifMtuのインスタンスは、インターフェースのMTUが既知になったときにのみインスタンス化されます）。
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の概念的な行内のオブジェクトインスタンスを取得するための応答に対処して、行の一部の列オブジェクトが見つからない/利用できないことを明らかにできる必要があります。
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設計者の義務です。
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.
階層化モデルメディア固有の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設計者は、仮想回路にifTableのエントリを割り当てるかどうかを指定する必要があります。もしそうなら、説得力のある根拠を提示する必要があります。
ifRcvAddressTable The media-specific MIB designer MUST specify the applicability of the ifRcvAddressTable.
ifRcvAddressTableメディア固有のMIB設計者は、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.
ifTypeメディア固有のMIBが適用される各ifType値について、メディア固有のMIBモジュールおよびそれらのモジュール内のMIBオブジェクトのインスタンスへのifType値のマッピングを指定する必要があります。
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設計者は、セマンティクス、説明、または適用性を変更してはなりません。
This MIB consists of 4 tables:
このMIBは4つのテーブルで構成されています。
ifTable This table is the ifTable from MIB-II.
ifTableこのテーブルは、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 because the semantics of said objects have significantly changed. This table also contains objects that were previously in the ifExtnsTable.
ifXTableこのテーブルには、インターフェースエボリューションの結果としてインターフェースMIBに追加されたオブジェクト、または前述のオブジェクトのセマンティクスが大幅に変更されたために非推奨となった元の（MIB-II）ifTableのオブジェクトの置き換えが含まれます。このテーブルには、以前にifExtnsTableにあったオブジェクトも含まれています。
ifStackTable This table contains objects that define the relationships among the sub-layers of an interface.
ifStackTableこのテーブルには、インターフェイスのサブレイヤ間の関係を定義するオブジェクトが含まれています。
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このテーブルには、このインターフェイスが受信するメディアレベルのアドレスを定義するために使用されるオブジェクトが含まれています。このテーブルは一般的なテーブルです。メディア固有のMIBの設計者は、このテーブルが特定のMIBにどのように適用されるかを正確に定義する必要があります。
IF-MIB DEFINITIONS ::= BEGIN
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 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、SNMPv2-CONFからのOBJECT-GROUP、SNMPv2-MIBからのsnmpTraps、IANAifType-MIBからのIANAifType。
ifMIB MODULE-IDENTITY LAST-UPDATED "9611031355Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
ifMIB MODULE-IDENTITY LAST-UPDATED "9611031355Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO "Keith McCloghrie Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134-1706 US
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."
REVISION "9602282155Z"
DESCRIPTION
"Revisions made by the Interfaces MIB WG."
REVISION "9311082155Z"
DESCRIPTION
"Initial revision, published as part of RFC 1573."
::= { mib-2 31 }
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
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))
-- InterfaceIndex contains the semantics of ifIndex and -- should be used for any objects defined on other mib -- modules that need these semantics.
-InterfaceIndexにはifIndexのセマンティクスが含まれています-他のmibで定義されたオブジェクトには使用する必要があります-これらのセマンティクスを必要とするモジュール
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"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)
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)
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 }
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 }
-- the Interfaces table
-インターフェイステーブル
-- The Interfaces table contains information on the entity's -- interfaces. Each sub-layer below the internetwork-layer -- of a network interface is considered to be an interface.
-Interfacesテーブルには、エンティティに関する情報が含まれています-インターフェイス。ネットワークインターフェースのインターネットワークレイヤーの下の各サブレイヤーは、インターフェースと見なされます。
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 }
ifEntry OBJECT-TYPE SYNTAX IfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry containing management information applicable to a particular interface." INDEX { ifIndex }
ifEntry OBJECT-TYPE SYNTAX IfEntry MAX-ACCESS not-accessible現在の説明「特定のインターフェイスに適用可能な管理情報を含むエントリ」 INDEX {ifIndex}
::= { ifTable 1 }
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
}
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 }
ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only
ifDescr OBJECT-TYPE SYNTAX DisplayString（SIZE（0..255））MAX-ACCESS読み取り専用
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 }
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 }
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 }
ifSpeed OBJECT-TYPE
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 }
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 }
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 }
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 }
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 }
ifInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface, including framing characters.
ifInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current説明「フレーミング文字を含む、インターフェイスで受信されたオクテットの総数。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブアドレスでマルチキャストまたはブロードキャストアドレスにアドレス指定されなかったパケットの数層。
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 }
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 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブレイヤーでマルチキャストまたはブロードキャストアドレスにアドレス指定されたパケットの数。
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 }
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 their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
ifInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current Description "上位層プロトコルへの配信を妨げるエラーが検出されなかったにもかかわらず、破棄するように選択された着信パケットの数。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."
このカウンターの値の不連続性は、管理システムの再初期化時に発生する可能性があり、ifCounterDiscontinuityTimeの値によって示される他の時間に発生する可能性があります。」
::= { ifEntry 13 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "パケット指向のインターフェースの場合、エラーを含んでいたインバウンドパケットの数。上位層のプロトコルへの配信を妨げます。文字指向または固定長の場合インターフェース、エラーを含んでいたインバウンド伝送ユニットの数。上位層プロトコルへの配信を妨げます。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION「パケット指向のインターフェースの場合、不明またはサポートされていないプロトコルのために破棄された、インターフェースを介して受信されたパケットの数。文字指向または固定長のインターフェースの場合プロトコルの多重化をサポートするインターフェイスを介して受信した、不明またはサポートされていないプロトコルのために破棄された伝送ユニットの数。プロトコルの多重化をサポートしていないインターフェイスの場合、このカウンタは常に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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "フレーミング文字を含む、インターフェイスから送信されたオクテットの総数。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでマルチキャストまたはブロードキャストアドレスにアドレス指定されなかったパケットの合計数。廃棄されたか、送信されませんでした。
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 }
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 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでマルチキャストまたはブロードキャストアドレスにアドレス指定されたパケットの総数。破棄されるか送信されません。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "送信されたパケットを破棄するためのエラーが検出されなかったにもかかわらず、破棄されるように選択された送信パケットの数。バッファ領域を解放します。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "パケット指向のインターフェースの場合、エラーのために送信できなかった送信パケットの数。文字指向のインターフェースまたは固定長のインターフェースの場合、送信の数エラーのため送信できなかった送信ユニット。
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 }
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }
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 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
1903. 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 }
-- -- 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 }
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 ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
ifHCInBroadcastPkts Counter64,
ifHCOutOctets Counter64,
ifHCOutUcastPkts Counter64,
ifHCOutMulticastPkts Counter64,
ifHCOutBroadcastPkts Counter64,
ifLinkUpDownTrapEnable INTEGER,
ifHighSpeed Gauge32,
ifPromiscuousMode TruthValue,
ifConnectorPresent TruthValue,
ifAlias DisplayString,
ifCounterDiscontinuityTime TimeStamp
}
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 MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the interface。このオブジェクトの値は、ローカルデバイスによって割り当てられたインターフェイスの名前である必要があり、入力したコマンドでの使用に適している必要がありますデバイスの「コンソール」にあります。これは、デバイスのインターフェース命名構文に応じて、「le0」などのテキスト名または「1」などの単純なポート番号になる可能性があります。ifTableの複数のエントリが一緒にデバイスによって名前が付けられた単一のインターフェースの場合、各インターフェースはifNameの値が同じになります。他の（プロキシされた）デバイスのインターフェースに関するSNMPクエリに応答するエージェントの場合、そのようなインターフェースのifNameの値はプロキシされたデバイスのローカル名。
If there is no local name, or this object is otherwise
not applicable, then this object contains a zero-
length string."
::= { ifXEntry 1 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION「このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブレイヤーのマルチキャストアドレスにアドレス指定されたパケットの数。 MAC層プロトコル。これには、グループアドレスと機能アドレスの両方が含まれます。
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 2 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブレイヤーのブロードキャストアドレスにアドレス指定されたパケットの数。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "上位レベルのプロトコルが送信を要求し、このサブレイヤーでマルチキャストアドレスにアドレス指定されたパケットの総数。送信されません。MAC層プロトコルの場合、これにはグループアドレスと機能アドレスの両方が含まれます。
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の値によって示される他の時間に発生する可能性があります。」
::= { ifXEntry 4 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでブロードキャストアドレスにアドレス指定されたパケットの総数。送信されません。
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 5 }
-- -- 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. --
--大容量カウンターオブジェクト。これらのオブジェクトはすべて、「基本」のifTableカウンタの64ビットバージョンです。これら-オブジェクトはすべて、32ビットと同じ基本セマンティクスを持っています-対応するものですが、構文は64ビットに拡張されています。 -
ifHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current
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.
「インターフェイスで受信されたオクテットの総数（フレーミング文字を含む）。このオブジェクトは、64ビットバージョンのifInOctetsです。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブアドレスでマルチキャストまたはブロードキャストアドレスにアドレス指定されなかったパケットの数layer。このオブジェクトは、64ビットバージョンのifInUcastPktsです。
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 }
ifHCInMulticastPkts 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 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.
ifHCInMulticastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブレイヤーのマルチキャストアドレスにアドレス指定されたパケットの数。 MAC層プロトコル。これには、グループアドレスと機能アドレスの両方が含まれます。このオブジェクトは、64ビットバージョンのifInMulticastPktsです。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION「このサブレイヤーによって上位（サブ）レイヤーに配信され、このサブレイヤーのブロードキャストアドレスにアドレス指定されたパケットの数。これはオブジェクトは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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "フレーミング文字を含む、インターフェイスから送信されたオクテットの合計数。このオブジェクトは、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 }
ifHCOutUcastPkts 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 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.
ifHCOutUcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでマルチキャストまたはブロードキャストアドレスにアドレス指定されなかったパケットの総数。このオブジェクトは、64ビットバージョンのifOutUcastPktsです。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでマルチキャストアドレスにアドレス指定されたパケットの総数。送信されません。MAC層プロトコルの場合、これにはグループアドレスと機能アドレスの両方が含まれます。このオブジェクトは、64ビットバージョンのifOutMulticastPktsです。
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 }
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 MAX-ACCESS read-only STATUS current DESCRIPTION "高レベルのプロトコルが送信を要求し、このサブレイヤーでブロードキャストアドレスにアドレス指定されたパケットの総数。送信されません。このオブジェクトは、64ビットバージョンのifOutBroadcastPktsです。
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 }
ifLinkUpDownTrapEnable OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION
ifLinkUpDownTrapEnable OBJECT-TYPE SYNTAX INTEGER {enabled（1）、disabled（2）} MAX-ACCESS read-write STATUS現在の説明
"Indicates whether linkUp/linkDown traps should be generated for this interface.
「このインターフェイスに対してlinkUp / linkDownトラップを生成する必要があるかどうかを示します。
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 }
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 }
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 MAX-ACCESS read-write STATUS現在の説明「このインターフェイスがこのステーションにアドレス指定されたパケット/フレームのみを受け入れる場合、このオブジェクトの値はfalse（2）です。このオブジェクトの値はtrue（1 ）ステーションがメディア上で送信されたすべてのパケット/フレームを受け入れる場合。値true（1）は特定のタイプのメディアでのみ有効です。有効な場合、このオブジェクトをtrue（1）の値に設定するには、インターフェイスのリセットが必要になる場合があります有効になる前に。
The value of ifPromiscuousMode does not affect the
reception of broadcast and multicast packets/frames by
the interface."
::= { ifXEntry 16 }
ifConnectorPresent OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
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 }
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））MAX-ACCESS read-write STATUS current DESCRIPTION「このオブジェクトは、ネットワークマネージャーによって指定されたインターフェイスの「エイリアス」名であり、不揮発性を提供します」インターフェースのハンドル」。
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インターフェイスのこのオブジェクトに格納する可能性のある値の例は、（Telcoの）インターフェイスの回線番号/識別子です。
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 }
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 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 }
-- The Interface Stack Group -- -- Implementation of this group is mandatory for all systems --
-インターフェイススタックグループ--このグループの実装はすべてのシステムに必須です-
ifStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION
ifStackTableのOBJECT-TYPE構文シーケンスifStackEntry MAX-ACCESSにアクセスできませんステータス現在の説明
"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:
「ネットワークインターフェイスの複数のサブレイヤー間の関係に関する情報を含む表。特に、各サブレイヤーが概念に対応する他のサブレイヤーの「上」で実行されるサブレイヤーに関する情報が含まれています。 ifTableの行。たとえば、ifIndex値xのサブレイヤーがifIndex値yのサブレイヤーを超える場合、このテーブルには以下が含まれます。
ifStackStatus.x.y=active
ifStackStatus.x.y = active
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は、アクティブなインターフェイスを識別します。このテーブルには、Iに関連付けられたインスタンス化された行が常に少なくとも2つあります。これらの行の1つでは、IはifStackHigherLayerの値です。もう1つは、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 }
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
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 }
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer Integer32,
ifStackLowerLayer Integer32,
ifStackStatus RowStatus
}
ifStackHigherLayer OBJECT-TYPE
SYNTAX Integer32
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 }
ifStackLowerLayer OBJECT-TYPE
SYNTAX Integer32
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 }
ifStackStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of the relationship between two sub-layers.
ifStackStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "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 }
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 }
-- 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.
-汎用受信アドレステーブル--このオブジェクトのグループはすべてのタイプに必須です-アドレス指定されたパケット/フレームを受信できるインターフェイス-複数のアドレス。 --このテーブルは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 MAX-ACCESS not-accessibleステータス現在の説明「このテーブルには、システムが特定のインターフェイスでパケット/フレームを受信する各アドレス（ブロードキャスト、マルチキャスト、またはユニキャスト）のエントリが含まれています。以下を除く：
- 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.
- 無差別モードで動作しているインターフェイスの場合、エントリは、無差別モードで動作していない場合にシステムがフレームを受信するアドレスに対してのみ必要です。
- 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機能アドレスの場合、インターフェースがフレームを受け入れるすべての機能アドレスのビットマスクとANDされた機能アドレスビットを持つアドレスに対して、1つのエントリのみが必要です。
A system is normally able to use any unicast address
which corresponds to an entry in this table as a
source address."
::= { ifMIBObjects 4 }
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 }
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
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."
ifRcvAddressAddress OBJECT-TYPE SYNTAX PhysAddress MAX-ACCESS not-accessible現在の説明「システムがこのエントリのインターフェイスでパケット/フレームを受け入れるアドレス」
::= { ifRcvAddressEntry 1 }
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 MAX-ACCESS read-create STATUS現在の説明「このオブジェクトは、ifRcvAddressTableで行を作成および削除するために使用されます。」
::= { ifRcvAddressEntry 2 }
ifRcvAddressType OBJECT-TYPE
SYNTAX INTEGER {
other(1),
volatile(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."
MAX-ACCESS read-create STATUS current DESCRIPTION "このオブジェクトには、テーブル内の有効なエントリの値nonVolatile（3）があり、管理対象システムの次の再起動では削除されません。値volatile（2）を持つエントリは有効で存在しますが、保存されていないため、管理対象システムの次の再起動後には存在しません。値other（1）のエントリは有効で存在しますが、その後も存在し続けるかどうかに関して分類されません次の再起動。」
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }
-- definition of interface-related traps.
-インターフェース関連のトラップの定義。
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 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 }
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMPv2 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 }
-- conformance information
-適合情報
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
-- compliance statements
-コンプライアンスステートメント
ifCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMPv2 entities which have network interfaces."
ifCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION「ネットワークインターフェイスを持つSNMPv2エンティティのコンプライアンスステートメント」
MODULE -- this module MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, ifCounterDiscontinuityGroup }
MODULE-このモジュールMANDATORY-GROUPS {ifGeneralInformationGroup、ifStackGroup2、ifCounterDiscontinuityGroup}
GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units."
グループ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."
グループifHCFixedLengthGroup説明「このグループは、文字指向であるか、固定長の伝送単位でデータを伝送し、ifSpeedの対応するインスタンスの値が20,000,000ビット/秒より大きいネットワークインターフェースに対してのみ必須です。」
GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented."
グループ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."
グループifHCPacketGroup説明「このグループは、パケット指向で、ifSpeedの対応するインスタンスの値が650,000,000ビット/秒より大きいネットワークインターフェースに対してのみ必須です。」
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."
グループifRcvAddressGroup説明「このグループの適用可能性は、メディア固有のMIBによって定義される必要があります。メディア固有のMIBは、このグループ内のアドレスの正確な意味、使用、およびセマンティクスを定義する必要があります。」
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトifLinkUpDownTrapEnable MIN-ACCESS読み取り専用説明「書き込みアクセスは必要となりません。」
OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクト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 {active（1）}-RowStatus MIN-ACCESSのサブセット読み取り専用説明「書き込みアクセスは不要であり、RowStatusテキスト表記法の6つの列挙値のうち1つだけをサポートする必要があります。具体的には：active（ 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)."
OBJECT ifAdminStatus SYNTAX INTEGER {up（1）、down（2）} MIN-ACCESS読み取り専用説明「書き込みアクセスは必要ありません、また値Testing（3）のサポートもありません。」
OBJECT ifAlias MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトifAlias MIN-ACCESS読み取り専用説明「書き込みアクセスは必要ありません。」
::= { ifCompliances 2 }
-- 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 }
-- the following five groups are mutually exclusive; at most
-- one of these groups is implemented for any interface
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 }
ifHCFixedLengthGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"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 }
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 }
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 }
ifVHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts,
ifHCInBroadcastPkts, ifHCOutUcastPkts,
ifHCOutMulticastPkts, ifHCOutBroadcastPkts,
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 higher speed (greater than 650,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 6 }
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 }
ifStackGroup2 OBJECT-GROUP
OBJECTS { ifStackStatus, ifStackLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 11 }
ifCounterDiscontinuityGroup OBJECT-GROUP
OBJECTS { ifCounterDiscontinuityTime }
STATUS current
DESCRIPTION
"A collection of objects providing information
specific to interface counter discontinuities."
::= { ifGroups 13 }
-- Deprecated Definitions - Objects
-非推奨の定義-オブジェクト
-- -- The Interface Test Table -- -- This group of objects is optional. However, a media-specific -- 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.
ifTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfTestEntry MAX-ACCESS not-accessible説明「このテーブルには、インターフェイスごとに1つのエントリが含まれています。これは、ネットワークマネージャがエージェントにインターフェイスにさまざまな障害をテストするように指示できるようにするオブジェクトを定義します。インターフェイスのテストは、そのインターフェイスのメディア固有のMIBで定義されています。テストを呼び出した後、オブジェクトifTestResultを読み取って結果を判断できます。エージェントがテストを実行できない場合は、ifTestResultがそのように示されます。オブジェクトifTestCodeを使用できますテストの結果に関するテスト固有またはインターフェイス固有（またはエンタープライズ固有）の詳細情報を提供するため。各インターフェイスで同時に実行できるテストは1つだけです。別のテストが実行されているときに1つのテストが進行中の場合一部のエージェントは、前のテストが別のインターフェースでアクティブな場合、テストを拒否する場合があります。
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) /*
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) }
*テストの実行中、または他の*マネージャーがテストを構成しているときにループします。 * /短い遅延get（ifTestId、ifTestStatus）}
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
if ( set(ifTestId = lock_value, ifTestStatus = inUse,
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
/*
* I have the lock
*/
set up any test parameters.
/*
* This starts the test
*/
set(ifTestType = test_to_run);
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
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」になるまで、必要に応じて定期的に取得を繰り返します。次に、マネージャステーションは、同じifTestIdオブジェクトを取得した値に、同じifTestStatusオブジェクトを 'inUse'に、対応するifTestOwnerオブジェクトをそれ自体を示す値に設定しようとします。設定操作が成功した場合、マネージャーは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 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.
所有権を取得したら、テストパラメータを設定し、ifTestTypeを設定してテストを開始します。テストが完了すると、エージェントはifTestStatusを「notInUse」に設定します。これが発生すると、マネージャーは結果を取得できます。 2つのネットワークマネージャーによるテストの呼び出しが重複する（まれな）イベントでは、最初の結果が読み取られる前に、最初のテストの結果が2番目のテストの結果によって上書きされる可能性があります。このまれな状況は、テスト結果を取得すると同時に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 }
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 ::=
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
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 }
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 }
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 MAX-ACCESS read-write STATUS deprecated DESCRIPTION "オペレーターが開始したインターフェーステストの開始と停止に使用される制御変数。テストに割り当てられるほとんどのOBJECT IDENTIFIER値は、特定のタイプのインターフェースに関連して他の場所で定義されます。ただし、 、このドキュメントでは、全二重ループバックテストの値を割り当て、サブジェクト識別子の特別な意味を定義しています。
noTest OBJECT IDENTIFIER ::= { 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 only valid when no test is currently in progress, in which case the indicated test is initiated.
値noTestがこのオブジェクトに書き込まれると、テストが進行中でない限りアクションは実行されません。その場合、テストは中止されます。このオブジェクトへの他の値の書き込みは、現在進行中のテストがない場合にのみ有効です。この場合、示されたテストが開始されます。
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 }
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 }
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 1903. The identifier:
ifTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION「このオブジェクトには、テスト結果に関するより具体的な情報を含むコードが含まれています。たとえば、失敗したテスト後のエラーコード。エラーコードとその他の値値は、インターフェイスやテストのタイプによって異なります。値には、RFC 1903で定義されているAutonomousTypeまたはInstancePointerのテキスト表記規則のセマンティクスが含まれる場合があります。識別子：
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }
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 }
-- 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 }
ifTestGroup OBJECT-GROUP OBJECTS { ifTestId, ifTestStatus, ifTestType,
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 }
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS deprecated
DESCRIPTION
"The previous collection of objects providing
information on the layering of MIB-II interfaces."
::= { ifGroups 9 }
ifOldObjectsGroup OBJECT-GROUP
OBJECTS { ifInNUcastPkts, ifOutNUcastPkts,
ifOutQLen, ifSpecific }
STATUS deprecated
DESCRIPTION
"The collection of objects deprecated from the
original MIB-II interfaces group."
::= { ifGroups 12 }
-- Deprecated Definitions - Compliance
-非推奨の定義-コンプライアンス
ifCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "The previous compliance statement for SNMPv2 entities which have network interfaces."
ifCompliance MODULE-COMPLIANCE STATUSは非推奨の説明「ネットワークインターフェイスを持つSNMPv2エンティティの以前のコンプライアンスステートメント」
MODULE -- this module MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
MODULE-このモジュールMANDATORY-GROUPS {ifGeneralGroup、ifStackGroup}
GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units."
グループ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."
グループifHCFixedLengthGroup説明「このグループは、文字指向であるか、固定長の伝送単位でデータを伝送し、ifSpeedの対応するインスタンスの値が20,000,000ビット/秒より大きいネットワークインターフェースに対してのみ必須です。」
GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented."
グループ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."
グループifHCPacketGroup説明「このグループは、パケット指向で、ifSpeedの対応するインスタンスの値が650,000,000ビット/秒より大きいネットワークインターフェースに対してのみ必須です。」
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 this group mandatory."
グループifTestGroup DESCRIPTION「このグループはオプションです。インターフェイステストを必要とするメディア固有のMIBでは、テストの呼び出しと結果のレポートにこのグループを使用することを強くお勧めします。必須テストを持つメディア固有のMIBは、このグループの実装を必須にする場合があります。」
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."
グループifRcvAddressGroup説明「このグループの適用可能性は、メディア固有のMIBによって定義される必要があります。メディア固有のMIBは、このグループ内のアドレスの正確な意味、使用、およびセマンティクスを定義する必要があります。」
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクトifLinkUpDownTrapEnable MIN-ACCESS読み取り専用説明「書き込みアクセスは必要となりません。」
OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required."
オブジェクト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 {active（1）}-RowStatus MIN-ACCESSのサブセット読み取り専用説明「書き込みアクセスは不要であり、RowStatusテキスト表記法の6つの列挙値のうち1つだけをサポートする必要があります。具体的には：active（ 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 }
END
終わり
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.
最初の提案は、少なくとも次のようなフレッドベイカー、テッドブルナー、チャックダビン、ジェレミーグリーン、マーシャルローズ、カイテシンク、ディーンスロープなど、多くの人々との会話と議論から発展しました。
[1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January 1996.
[1] Case、J.、McCloghrie、K.、Rose、M.、and S. Waldbusser、 "Structure of Management Information for version 2 for the Simple Network Management Protocol（SNMPv2）"、RFC 1902、1996年1月。
[2] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[2] Case、J.、McCloghrie、K.、Rose、M.、and S. Waldbusser、 "Textual Conventions for version 2 for the Simple Network Management Protocol（SNMPv2）"、RFC 1903、January 1996。
[3] 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.
[3] Case、J.、McCloghrie、K.、Rose、M.、and S. Waldbusser、 "Protocol Operations for version 2 for the Simple Network Management Protocol（SNMPv2）"、RFC 1905、January 1996。
[4] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17, RFC 1213, March 1991.
[4] McCloghrie、K。、およびM. Rose、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース-MIB-II」、STD 17、RFC 1213、1991年3月。
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[5] Case、J.、Fedor、M.、Schoffstall、M.、and J. Davin、 "Simple Network Management Protocol"、STD 15、RFC 1157、May 1990。
[6] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[6] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[7] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, May 1991.
[7] McCloghrie、K。、「Extensions to the Generic-Interface MIB」、RFC 1229、May 1991。
[8] ATM Forum Technical Committee, "LAN Emulation Client Management: Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 1995.
[8] ATMフォーラム技術委員会、「LANエミュレーションクライアント管理：バージョン1.0仕様」、af-lane-0044.000、ATMフォーラム、1995年9月。
[9] Stewart, B., "Definitions of Managed Objects for Character Stream Devices using SMIv2", RFC 1658, July 1994.
[9] Stewart、B。、「SMIv2を使用した文字ストリームデバイスの管理対象オブジェクトの定義」、RFC 1658、1994年7月。
[10] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, March 1997.
[10] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
This MIB contains both readable objects whose values provide the number and status of a device's network interfaces, and write-able objects which allow an administrator to control the interfaces and to perform tests on the interfaces. Unauthorized access to the readable objects is relatively innocuous. Unauthorized access to the write-able objects could cause a denial of service, or in combination with other (e.g., physical) security breaches, could cause unauthorized connectivity to a device.
このMIBには、デバイスのネットワークインターフェイスの数とステータスを提供する値を持つ読み取り可能なオブジェクトと、管理者がインターフェイスを制御し、インターフェイスでテストを実行できる書き込み可能なオブジェクトの両方が含まれています。読み取り可能なオブジェクトへの不正アクセスは比較的無害です。書き込み可能なオブジェクトへの不正アクセスは、サービス拒否を引き起こしたり、他の（物理的な）セキュリティ違反と組み合わせて、デバイスへの不正な接続を引き起こしたりする可能性があります。
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Keith McCloghrie Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134-1706
Phone: 408-526-5260 EMail: kzm@cisco.com
電話：408-526-5260メール：kzm@cisco.com
Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845
Frank Kastenholz FTP Software 2 High Street North Andover、MA。アメリカ01845
Phone: 508-685-4000 EMail: kasten@ftp.com
電話：508-685-4000メール：kasten@ftp.com
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。