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