RFC2665 日本語訳
2665 Definitions of Managed Objects for the Ethernet-like InterfaceTypes. J. Flick, J. Johnson. August 1999. (Format: TXT=110038 bytes) (Obsoletes RFC2358) (Obsoleted by RFC3635) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Flick
Request for Comments: 2665 Hewlett-Packard Company
Obsoletes: 2358 J. Johnson
Category: Standards Track RedBack Networks
August 1999
コメントを求めるワーキンググループJ.軽打要求をネットワークでつないでください: 2665 ヒューレット・パッカード会社は以下を時代遅れにします。 2358年のJ.ペニスカテゴリ: 規格は1999年8月に20ドル紙幣ネットワークを追跡します。
Definitions of Managed Objects for
the Ethernet-like Interface Types
イーサネットのようなインターフェース型のための管理オブジェクトの定義
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 (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 2358, "Definitions of Managed Objects for the Ethernet-like Interface Types". This memo extends that specification by including management information useful for the management of 1000 Mb/s and full-duplex Ethernet interfaces.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 RFC2358、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」をこのメモは時代遅れにします。 このメモは、1000Mb/sと全二重イーサネットインタフェースの管理の役に立つ経営情報を含んでいることによって、その仕様を広げています。
Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology.
IEEEの802.3作業部会によって定義されるイーサネット技術は、発展し続けています、速度のスケーラブルな増加、新しいタイプのケーブリングとインタフェース、および新機能で。 この発展は、この新しい機能性を反映するために管理オブジェクトで釣り銭がいるかもしれません。 このドキュメントはこのワーキンググループによって発行された他のドキュメントのようにイーサネット技術の発展に、あるステージを反映します。 将来、このドキュメントが改訂されるかもしれませんか、または新しいドキュメントはイーサネットInterfacesとHub MIB作業部会によって発行されるかもしれません、イーサネット技術の発展を反映するために。
Flick & Johnson Standards Track [Page 1] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[1ページ]RFC2665
Table of Contents
目次
1. Introduction ................................................ 2 2. The SNMP Management Framework .............................. 3 3. Overview ................................................... 4 3.1. Relation to MIB-2 ........................................ 4 3.2. Relation to the Interfaces MIB ........................... 5 3.2.1. Layering Model ......................................... 5 3.2.2. Virtual Circuits ....................................... 5 3.2.3. ifTestTable ............................................ 5 3.2.4. ifRcvAddressTable ...................................... 6 3.2.5. ifPhysAddress .......................................... 6 3.2.6. ifType ................................................. 6 3.2.7. Specific Interface MIB Objects ......................... 7 3.3. Relation to the 802.3 MAU MIB ............................ 11 3.4. dot3StatsEtherChipSet .................................... 11 3.5. Mapping of IEEE 802.3 Managed Objects .................... 12 4. Definitions ................................................ 16 5. Intellectual Property ...................................... 39 6. Acknowledgements ........................................... 40 7. References ................................................. 41 8. Security Considerations .................................... 43 9. Authors' Addresses ......................................... 44 A. Change Log ................................................. 45 A.1. Changes since RFC 2358 ................................... 45 A.2. Changes between RFC 1650 and RFC 2358 .................... 46 B. Full Copyright Statement ................................... 47
1. 序論… 2 2. SNMP管理フレームワーク… 3 3. 概要… 4 3.1. MIB-2との関係… 4 3.2. インタフェースMIBとの関係… 5 3.2.1. レイヤリングモデル… 5 3.2.2. 仮想の回路… 5 3.2.3ifTestTable… 5 3.2.4ifRcvAddressTable… 6 3.2.5ifPhysAddress… 6 3.2.6ifType… 6 3.2.7. 特定のインタフェースMIBは反対します… 7 3.3. 802.3MAU MIBとの関係… 11 3.4dot3StatsEtherChipSet… 11 3.5. IEEE802.3管理オブジェクトに関するマッピング… 12 4. 定義… 16 5. 知的所有権… 39 6. 承認… 40 7. 参照… 41 8. セキュリティ問題… 43 9. 作者のアドレス… 44 A. ログを変えてください… 45 A.1。 RFC2358以来の変化… 45 A.2。 RFC1650とRFC2358の間の変化… 46 B.の完全な著作権宣言文… 47
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 defines objects for managing Ethernet-like interfaces.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは、イーサネットのようなインタフェースを管理するためにオブジェクトを定義します。
This memo also includes a MIB module. This MIB module extends the list of managed objects specified in the earlier version of this MIB: RFC 2358 [23].
また、このメモはMIBモジュールを含んでいます。 このMIBモジュールはこのMIBの以前のバージョンで指定された管理オブジェクトのリストを広げています: RFC2358[23]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [26].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[26]で説明されるように本書では解釈されることであるべきですか?
Flick & Johnson Standards Track [Page 2] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[2ページ]RFC2665
2. The SNMP Management Framework
2. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [1].
o RFC2571[1]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
second version, called SMIv2, is described in STD 58, RFC 2578
[5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[2]、STD16、RFC1212[3]、およびRFC1215[4]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[5]、STD58、RFC2579[6]、およびSTD58(RFC2580[7])で説明されます。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [8]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC
1906 [10]. The third version of the message protocol is called
SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574
[12].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[8]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[9]とRFC1906[10]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[10]、RFC2572[11]、およびRFC2574[12]でSNMPv3と呼ばれて、説明されます。
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [8]. A second set of protocol
operations and associated PDU formats is described in RFC 1905
[13].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[8]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[13]で説明されます。
o A set of fundamental applications described in RFC 2573 [14] and
the view-based access control mechanism described in RFC 2575
[15].
o 1セットの基礎的応用はRFCで2573[14]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[15]について説明しました。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 SMIv2の何らかのマシンの読み込み可能な情報が翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
Flick & Johnson Standards Track [Page 3] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[3ページ]RFC2665
3. Overview
3. 概要
Instances of these object types represent attributes of an interface to an ethernet-like communications medium. At present, ethernet-like media are identified by the following values of the ifType object in the Interfaces MIB [25]:
これらのオブジェクト・タイプのインスタンスはイーサネットのようなコミュニケーション媒体にインタフェースの属性を表します。 現在のところ、イーサネットのようなメディアはInterfaces MIB[25]のifTypeオブジェクトの以下の値によって特定されます:
ethernetCsmacd(6)
iso88023Csmacd(7)
starLan(11)
ethernetCsmacd(6) iso88023Csmacd(7) starLan(11)
The definitions presented here are based on Section 30, "10 Mb/s, 100 Mb/s and 1000 Mb/s Management", and Annex 30A, "GDMO Specification for 802.3 managed object classes" of IEEE Std. 802.3, 1998 Edition [16], as originally interpreted by Frank Kastenholz then of Interlan in [17]. Implementors of these MIB objects should note that IEEE Std. 802.3 [16] explicitly describes (in the form of Pascal pseudocode) when, where, and how various MAC attributes are measured. The IEEE document also describes the effects of MAC actions that may be invoked by manipulating instances of the MIB objects defined here.
ここに提示された定義はセクション30と、「10Mb/s、100Mb/s、および1000Mb/sの管理」に基づいています、そして、Annex 30A、「802.3管理オブジェクトのためのGDMO Specificationは属します」。IEEE Stdについて。 802.3(1998Edition[16])は同じくらい元々、[17]でそして、InterlanのフランクKastenholzで解釈しました。 これらのMIBオブジェクトの作成者はそのIEEE Stdに注意するべきです。 802.3 [16]は明らかにいつ、どこと様々なMAC属性がどう測定されるかを説明します(パスカル擬似コードの形で)。 また、IEEEドキュメントはここで定義されたMIBオブジェクトのインスタンスを操ることによって呼び出されるかもしれないMAC動作の効果について説明します。
To the extent that some of the attributes defined in [16] are represented by previously defined objects in MIB-2 [24] or in the Interfaces MIB [25], such attributes are not redundantly represented by objects defined in this memo. Among the attributes represented by objects defined in other memos are the number of octets transmitted or received on a particular interface, the number of frames transmitted or received on a particular interface, the promiscuous status of an interface, the MAC address of an interface, and multicast information associated with an interface.
[16]で定義された属性のいくつかがMIB-2[24]かInterfaces MIB[25]に以前に定義されたオブジェクトによって表されるという範囲には、そのような属性がこのメモで定義されたオブジェクトによって冗長に表されません。 他のメモで定義されたオブジェクトによって表された属性の中では、フレームの数は、特定のインタフェース、インタフェースの無差別な状態、インタフェースに関連しているインタフェース、およびマルチキャスト情報のMACアドレスで八重奏の数が特定のインタフェースに伝えられるか、または受け取られるのを伝えたか、または受けました。
3.1. Relation to MIB-2
3.1. MIB-2との関係
This section applies only when this MIB is used in conjunction with the "old" (RFC 1213) [24] interface group.
このMIBが「古い」(RFC1213)[24]インタフェースグループに関連して使用されるときだけ、このセクションは適用されます。
The relationship between an ethernet-like interface and an interface in the context of MIB-2 is one-to-one. As such, the value of an ifIndex object instance can be directly used to identify corresponding instances of the objects defined herein.
イーサネットのようなインタフェースとMIB-2の文脈のインタフェースとの関係は、1〜1です。 そういうものとして、ここに定義されたオブジェクトの対応するインスタンスを特定するのに直接ifIndexオブジェクトインスタンスの値を使用できます。
For agents which implement the (now deprecated) ifSpecific object, an instance of that object that is associated with an ethernet-like interface has the OBJECT IDENTIFIER value:
エージェントに関しては、どれが、(現在、推奨しない)のifSpecificがオブジェクト、その関連オブジェクトのインスタンスであると実装するかに、OBJECT IDENTIFIER値がイーサネットのようなインタフェースと共にあります:
dot3 OBJECT IDENTIFER ::= { transmission 7 }
dot3 OBJECT IDENTIFER:、:= トランスミッション7
Flick & Johnson Standards Track [Page 4] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[4ページ]RFC2665
3.2. Relation to the Interfaces MIB
3.2. インタフェースMIBとの関係
The Interface MIB [25] requires that any MIB which is an adjunct of the Interface MIB clarify specific areas within the Interface MIB. These areas were intentionally left vague in the Interface MIB to avoid over constraining the MIB, thereby precluding management of certain media-types.
Interface MIB[25]は、Interface MIBの付属物であるどんなMIBもInterface MIBの中で特定の領域をはっきりさせるのを必要とします。 これらの領域は故意に、MIBを抑制して、その結果、ある管理を排除する上で避けるInterface MIBであいまいな左にメディアでタイプされるということでした。
Section 3.3 of [25] enumerates several areas which a media-specific MIB must clarify. Each of these areas is addressed in a following subsection. The implementor is referred to [25] in order to understand the general intent of these areas.
[25]のセクション3.3はメディア特有のMIBがはっきりさせなければならないいくつかの領域を列挙します。 それぞれのこれらの領域は次の小区分で扱われます。 作成者は、[25] これらの領域の総合的目的を理解するために言及されます。
3.2.1. Layering Model
3.2.1. レイヤリングモデル
This MIB does not provide for layering. There are no sublayers.
このMIBはレイヤリングに備えません。 副層が全くありません。
EDITOR'S NOTE:
編集者注:
One could foresee the development of an 802.2 and enet-transceiver MIB. They could be higher and lower sublayers, respectively. All that THIS document should do is allude to the possibilities and urge the implementor to be aware of the possibility and that they may have requirements which supersede the requirements in this document.
1つは802.2とenet-トランシーバーMIBの開発について見通すかもしれません。 それらはそれぞれより高くて下側の副層であるかもしれません。 そのTHISドキュメントがするはずであるのが、可能性について暗示して、可能性を意識しているよう作成者に促すことであり、それらは本書では要件に取って代わる要件を持っているかもしれません。
3.2.2. Virtual Circuits
3.2.2. 仮想の回路
This medium does not support virtual circuits and this area is not applicable to this MIB.
この媒体は仮想の回路を支えません、そして、この領域はこのMIBに適切ではありません。
3.2.3. ifTestTable
3.2.3. ifTestTable
This MIB defines two tests for media which are instrumented with this MIB; TDR and Loopback. Implementation of these tests is not required. Many common interface chips do not support one or both of these tests.
このMIBはこのMIBと共に器具を取り付けられるメディアのために2つのテストを定義します。 TDRとループバック。 これらのテストの実装は必要ではありません。 多くの一般的なインタフェースチップはこれらのテストの1か両方をサポートしません。
These two tests are provided as a convenience, allowing a common method to invoke the test.
共通方法がテストを呼び出すのを許容して、便利としてこれらの2つのテストを提供します。
Standard MIBs do not include objects in which to return the results of the TDR test. Any needed objects MUST be provided in the vendor specific MIB.
標準のMIBsはTDRテストの結果を返すオブジェクトを含んでいません。 どんな必要なオブジェクトもベンダーの特定のMIBに提供しなければなりません。
Note that the ifTestTable is now deprecated. Work is underway to define a replacement MIB for system and interface testing. It is expected that the tests defined in this document will be usable in this replacement MIB.
ifTestTableが現在推奨しないことに注意してください。 仕事は、システムとインターフェース試験のために交換MIBを定義するために進行中です。 本書では定義されたテストがこの交換MIBで使用可能になると予想されます。
Flick & Johnson Standards Track [Page 5] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[5ページ]RFC2665
3.2.4. ifRcvAddressTable
3.2.4. ifRcvAddressTable
This table contains all IEEE 802.3 addresses, unicast, multicast, and broadcast, for which this interface will receive packets and forward them up to a higher layer entity for local consumption. The format of the address, contained in ifRcvAddressAddress, is the same as for ifPhysAddress.
このテーブルは802.3が扱うすべてのIEEE、ユニキャスト、マルチキャスト、および放送を含んでいます。(このインタフェースは、それのために地方の消費で、より高い層の実体までパケットを受けて、それらを進めるでしょう)。 アドレスのifRcvAddressAddressに含まれた形式はifPhysAddressのように同じです。
In the event that the interface is part of a MAC bridge, this table does not include unicast addresses which are accepted for possible forwarding out some other port. This table is explicitly not intended to provide a bridge address filtering mechanism.
インタフェースがMACブリッジの一部であるなら、このテーブルは可能な推進のためにある他のポートから受け入れられるユニキャストアドレスを含んでいません。 明らかに、このテーブルがブリッジアドレスフィルタリングメカニズムを提供することを意図しません。
3.2.5. ifPhysAddress
3.2.5. ifPhysAddress
This object contains the IEEE 802.3 address which is placed in the source-address field of any Ethernet, Starlan, or IEEE 802.3 frames that originate at this interface. Usually this will be kept in ROM on the interface hardware. Some systems may set this address via software.
このオブジェクトはこのインタフェースで起因するどんなイーサネット、Starlan、またはIEEE802.3フレームのソースアドレス分野にも置かれるIEEE802.3アドレスを含んでいます。 通常、これはインタフェースハードウェアの上にROMに保たれるでしょう。 いくつかのシステムがソフトウェアでこのアドレスを設定するかもしれません。
In a system where there are several such addresses the designer has a tougher choice. The address chosen should be the one most likely to be of use to network management (e.g. the address placed in ARP responses for systems which are primarily IP systems).
そのようないくつかのアドレスがあるシステムでは、デザイナーは、より厳しい選択を持っています。 選ばれたアドレスはネットワークマネージメント(例えば主としてIPシステムであるシステムのためのARP応答に置かれたアドレス)の役に立つ最も傾向があるものであるべきです。
If the designer truly can not chose, use of the factory- provided ROM address is suggested.
デザイナーであるなら、本当に、缶は選ばれないで、工場の提供されたROMアドレスの使用は示されます。
If the address can not be determined, an octet string of zero length should be returned.
アドレスが決定できないなら、ゼロ・レングスの八重奏ストリングを返すべきです。
The address is stored in binary in this object. The address is stored in "canonical" bit order, that is, the Group Bit is positioned as the low-order bit of the first octet. Thus, the first byte of a multicast address would have the bit 0x01 set.
アドレスはこのオブジェクトのバイナリーで保存されます。 アドレスは噛み付いている「正準な」オーダーに保存されます、すなわち、Group Bitが最初の八重奏の下位のビットとして置かれます。 したがって、マルチキャストアドレスの最初のバイトで、ビット0x01を設定するでしょう。
3.2.6. ifType
3.2.6. ifType
This MIB applies to interfaces which have any of the following ifType values:
このMIBは以下のifType値のいずれも持っているインタフェースに適用します:
ethernetCsmacd(6)
iso88023Csmacd(7)
starLan(11)
ethernetCsmacd(6) iso88023Csmacd(7) starLan(11)
Flick & Johnson Standards Track [Page 6] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[6ページ]RFC2665
It is RECOMMENDED that all Ethernet-like interfaces use an ifType of ethernetCsmacd(6) regardless of the speed that the interface is running or the link-layer encapsulation in use. iso88023Csmacd(7) and starLan(11) are supported for backwards compatability.
すべてのイーサネットのようなインタフェースがインタフェースが実行している速度か使用中のリンクレイヤカプセル化にかかわらずethernetCsmacd(6)のifTypeを使用するのは、RECOMMENDEDです。iso88023Csmacd(7)とstarLan(11)は遅れているcompatabilityのためにサポートされます。
There are three other interface types defined in the IANAifType-MIB for Ethernet. They are fastEther(62), fastEtherFX(69), and gigabitEthernet(117). This document takes the position that an Ethernet is an Ethernet, and Ethernet interfaces SHOULD always have the same value of ifType. Information on the particular flavor of Ethernet that an interface is running is available from ifSpeed in the Interfaces MIB, and ifMauType in the 802.3 MAU MIB. An Ethernet-like interface SHOULD NOT use the fastEther(62), fastEtherFX(69), or gigabitEthernet(117) ifTypes.
イーサネットのためにIANAifType-MIBで定義された他の3人のインターフェース型がいます。 それらは、fastEther(62)と、fastEtherFX(69)と、gigabitEthernet(117)です。 このドキュメントはイーサネットがイーサネットと、SHOULDが同じくらいにいつも評価させるifTypeのイーサネットインタフェースであるという立場を取ります。 インタフェースが実行しているイーサネットの特定の風味に関する情報はInterfaces MIBのifSpeed、および802.3MAU MIBのifMauTypeから利用可能です。 イーサネットのようなインタフェースSHOULD NOTはfastEther(62)、fastEtherFX(69)、またはgigabitEthernet(117) ifTypesを使用します。
Interfaces with any of the supported ifType values map to the EtherLike-MIB in the same manner. There are no implementation differences.
値が同じ方法でEtherLike-MIBに写像するサポートしているifTypeのいずれとのインタフェース。 実装差が全くありません。
3.2.7. Specific Interface MIB Objects
3.2.7. 特定のインタフェースMIBオブジェクト
The following table provides specific implementation guidelines for applying the interface group objects to ethernet-like media.
以下のテーブルはイーサネットのようなメディアにインタフェース群対象を適用するための特定の実施要綱を提供します。
Object Guidelines
オブジェクトガイドライン
ifIndex Each ethernet-like interface is
represented by an ifEntry. The
dot3StatsTable in this MIB module is
indexed by dot3StatsIndex. The interface
identified by a particular value of
dot3StatsIndex is the same interface as
identified by the same value of ifIndex.
ifIndex EachのイーサネットのようなインタフェースはifEntryによって表されます。 このMIBモジュールによるdot3StatsTableはdot3StatsIndexによって索引をつけられます。 dot3StatsIndexの特定の値によって特定されたインタフェースはifIndexの同じ値によって特定されるように同じインタフェースです。
ifDescr Refer to [25].
ifDescrは[25]について言及します。
ifType Refer to section 3.2.6.
セクション3.2.6へのifType Refer。
ifMtu 1500 octets. NOTE: This is the MTU as
seen by the MAC client. When a higher
layer protocol, like IP, is running over
Ethernet, this is the MTU that will be
seen by that higher layer protocol.
However, when using the IEEE 802.2 LLC
protocol, higher layer protocols will
see a different MTU. In particular, an
LLC type 1 client protocol will see
ifMtu1500八重奏。 以下に注意してください。 MACクライアントによって見られるようにこれはMTUです。 より高い層のプロトコルがIPのようにイーサネットをひいているとき、これはそのより高い層のプロトコルによって見られるMTUです。 しかしながら、IEEE802.2LLCプロトコルを使用するとき、より高い層のプロトコルは異なったMTUを見るでしょう。 特に、LLCのタイプの1人のクライアントのプロトコルは見られるでしょう。
Flick & Johnson Standards Track [Page 7] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[7ページ]RFC2665
an MTU of 1497 octets, and a protocol
running over SNAP will see an MTU of
1492 octets.
1497の八重奏のMTU、およびSNAPをひくプロトコルは見るでしょう。1492の八重奏のMTUを見てください。
ifSpeed The current operational speed of the
interface in bits per second. For
current ethernet-like interfaces, this
will be equal to 1,000,000 (1 million),
10,000,000 (10 million), 100,000,000
(100 million), or 1,000,000,000 (1
billion). If the interface implements
auto-negotiation, auto-negotiation is
enabled for this interface, and the
interface has not yet negotiated to an
operational speed, this object SHOULD
reflect the maximum speed supported by
the interface. Note that this object
MUST NOT indicate a doubled value when
operating in full-duplex mode. It MUST
indicate the correct line speed
regardless of the current duplex mode.
The duplex mode of the interface may
be determined by examining either the
dot3StatsDuplexStatus object in this
MIBmodule, or the ifMauType object in
the 802.3 MAU MIB.
bpsにおける、インタフェースの現在の操作上の速度をifSpeedしました。 現在のイーサネットのようなインタフェースに関して、これは100万と等しくなるでしょう。(100万) 1000万 (1000万) 1億 (1億)、または10億(10億)。 インタフェースが自動交渉を実装して、自動交渉がこのインタフェースに可能にされて、インタフェースがまだ操作上の速度と交渉されていないなら、このオブジェクトSHOULDはインタフェースによってサポートされた最高回転数を反映します。 全二重モードで作動するとき、このオブジェクトが倍増している値を示してはいけないことに注意してください。 それは現在の重複のモードにかかわらず適度のライン・スピードを示さなければなりません。 インタフェースの重複のモードは、このMIBmoduleのdot3StatsDuplexStatusオブジェクトか802.3MAU MIBのifMauTypeオブジェクトのどちらかを調べることによって、決定するかもしれません。
ifPhysAddress Refer to section 3.2.5.
セクション3.2.5へのifPhysAddress Refer。
ifAdminStatus Write access is not required. Support
for 'testing' is not required.
ifAdminStatus Writeアクセスは必要ではありません。 'テスト'であるサポートは必要ではありません。
ifOperStatus The operational state of the interface.
Support for 'testing' is not required.
The value 'dormant' has no meaning for
an ethernet-like interface.
操作上が述べるインタフェースのifOperStatus。 'テスト'であるサポートは必要ではありません。 値の'眠ること'で、イーサネットのようなインタフェースへの意味がありません。
ifLastChange Refer to [25].
ifLastChangeは[25]について言及します。
ifInOctets The number of octets in valid MAC
frames received on this interface,
including the MAC header and FCS.
This does include the number of octets
in valid MAC Control frames received on
this interface.
MACヘッダーとFCSを含んでいて、有効なMACフレームの八重奏の数がこのインタフェースで受けたifInOctets。 これはこのインタフェースに受け取られた有効なMAC Controlフレームの八重奏の数を含んでいます。
Flick & Johnson Standards Track [Page 8] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[8ページ]RFC2665
ifInUcastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are consumed by the
interface layer and are not passed to
any higher layer protocol.
ifInUcastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって消費されて、どんなより高い層のプロトコルにも通り過ぎられないので。
ifInDiscards Refer to [25].
ifInDiscardsは[25]について言及します。
ifInErrors The sum for this interface of
dot3StatsAlignmentErrors,
dot3StatsFCSErrors,
dot3StatsFrameTooLongs,
dot3StatsInternalMacReceiveErrors and
dot3StatsSymbolErrors.
これのための合計が連結するdot3StatsAlignmentErrors、dot3StatsFCSErrors、dot3StatsFrameTooLongs、dot3StatsInternalMacReceiveErrors、およびdot3StatsSymbolErrorsのifInErrors。
ifInUnknownProtos Refer to [25].
ifInUnknownProtosは[25]について言及します。
ifOutOctets The number of octets transmitted in
valid MAC frames on this interface,
including the MAC header and FCS.
This does include the number of octets
in valid MAC Control frames transmitted
on this interface.
八重奏の数が有効なMACで伝えたifOutOctetsはMACヘッダーとFCSを含むこのインタフェースで縁どっています。 これはこのインタフェースで伝えられた有効なMAC Controlフレームの八重奏の数を含んでいます。
ifOutUcastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by the
interface layer, and are not passed
from any higher layer protocol.
ifOutUcastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって生成されて、どんなより高い層のプロトコルからも通り過ぎられないので。
ifOutDiscards Refer to [25].
ifOutDiscardsは[25]について言及します。
ifOutErrors The sum for this interface of:
dot3StatsSQETestErrors,
dot3StatsLateCollisions,
dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors and
dot3StatsCarrierSenseErrors.
これのための合計が連結するifOutErrors: dot3StatsSQETestErrors、dot3StatsLateCollisions、dot3StatsExcessiveCollisions、dot3StatsInternalMacTransmitErrors、およびdot3StatsCarrierSenseErrors。
ifName Locally-significant textual name for
the interface (e.g. lan0).
インタフェース(例えば、lan0)へのifName Locally重要な原文の名前。
ifInMulticastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are consumed by the
interface layer and are not passed to
any higher layer protocol.
ifInMulticastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって消費されて、どんなより高い層のプロトコルにも通り過ぎられないので。
Flick & Johnson Standards Track [Page 9] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[9ページ]RFC2665
ifInBroadcastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by
the interface layer, and are not passed
from any higher layer protocol.
ifInBroadcastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって生成されて、どんなより高い層のプロトコルからも通り過ぎられないので。
ifOutMulticastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are consumed by the
interface layer and are not passed to
any higher layer protocol.
ifOutMulticastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって消費されて、どんなより高い層のプロトコルにも通り過ぎられないので。
ifOutBroadcastPkts Refer to [25]. Note that this does
not include MAC Control frames, since
MAC Control frames are generated by
the interface layer, and are not passed
from any higher layer protocol.
ifOutBroadcastPktsは[25]について言及します。 これがMAC Controlフレームを含んでいないことに注意してください、MAC Controlフレームがインタフェース層によって生成されて、どんなより高い層のプロトコルからも通り過ぎられないので。
ifHCInOctets 64-bit versions of counters. Required
ifHCOutOctets for ethernet-like interfaces that are
capable of operating at 20Mbit/sec or
faster, even if the interface is
currently operating at less than
20Mbit/sec.
カウンタのifHCInOctetsの64ビットのバージョン。 インタフェースが現在20Mbit/秒以下で作動していても、20Mbit/秒のときに作動できるか、または、より速いイーサネットのようなインタフェースへの必要なifHCOutOctets
ifHCInUcastPkts 64-bit versions of packet counters.
ifHCInMulticastPkts Required for ethernet-like interfaces
ifHCInBroadcastPkts that are capable of operating at
ifHCOutUcastPkts 640Mbit/sec or faster, even if the
ifHCOutMulticastPkts interface is currently operating at
ifHCOutBroadcastPkts less than 640Mbit/sec.
パケットカウンタifHCOutMulticastPktsインタフェースが現在ifHCOutBroadcastPktsで作動していなくても、ifHCOutUcastPkts 640Mbit/秒のときに作動できるか、または640Mbit/秒より速いイーサネットのようなインタフェースifHCInBroadcastPktsへのifHCInMulticastPkts RequiredのifHCInUcastPktsの64ビットのバージョン
ifLinkUpDownTrapEnable Refer to [25]. Default is 'enabled'
ifLinkUpDownTrapEnableは[25]について言及します。 デフォルトは'可能にされます'。
ifHighSpeed The current operational speed of the
interface in millions of bits per
second. For current ethernet-like
interfaces, this will be equal to 1,
10, 100, or 1,000. If the interface
implements auto-negotiation,
auto-negotiation is enabled for this
interface, and the interface has not
yet negotiated to an operational speed,
this object SHOULD reflect the maximum
speed supported by the interface. Note
that this object MUST NOT indicate a
doubled value when operating in full-
duplex mode. It MUST indicate the
何百万ものbpsにおける、インタフェースの現在の操作上の速度のifHighSpeed。 現在のイーサネットのようなインタフェースに関しては、これは1、10、100、または1,000と等しくなるでしょう。 インタフェースが自動交渉を実装して、自動交渉がこのインタフェースに可能にされて、インタフェースがまだ操作上の速度と交渉されていないなら、このオブジェクトSHOULDはインタフェースによってサポートされた最高回転数を反映します。 完全な重複のモードで作動するとき、このオブジェクトが倍増している値を示してはいけないことに注意してください。 それは示さなければなりません。
Flick & Johnson Standards Track [Page 10] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[10ページ]RFC2665
correct line speed regardless of the
current duplex mode. The duplex mode
of the interface may be determined
by examining either the
dot3StatsDuplexStatus object in this
MIB module, or the ifMauType object in
the 802.3 MAU MIB.
現在の重複のモードにかかわらずライン・スピードを修正してください。 インタフェースの重複のモードは、802.3MAU MIBでこのMIBモジュールによるdot3StatsDuplexStatusオブジェクトかifMauTypeオブジェクトのどちらかを調べることによって、決定するかもしれません。
ifPromiscuousMode Refer to [25].
ifPromiscuousModeは[25]について言及します。
ifConnectorPresent This will normally be 'true'.
通常、ifConnectorPresent Thisは'本当でしょう'。
ifAlias Refer to [25].
ifAliasは[25]について言及します。
ifCounterDiscontinuityTime Refer to [25]. Note that a
discontinuity in the Interface MIB
counters may also indicate a
discontinuity in some or all of the
counters in this MIB that are
associated with that interface.
ifCounterDiscontinuityTimeは[25]について言及します。 また、Interface MIBカウンタの不連続がそのインタフェースに関連しているこのMIBのカウンタのいくつかかすべてで不連続を示すかもしれないことに注意してください。
ifStackHigherLayer Refer to section 3.2.1.
ifStackLowerLayer
ifStackStatus
セクション3.2.1ifStackLowerLayer ifStackStatusへのifStackHigherLayer Refer
ifRcvAddressAddress Refer to section 3.2.4.
ifRcvAddressStatus
ifRcvAddressType
セクション3.2.4ifRcvAddressStatus ifRcvAddressTypeへのifRcvAddressAddress Refer
3.3. Relation to the 802.3 MAU MIB
3.3. 802.3MAU MIBとの関係
Support for the mauModIfCompl2 compliance statement of the MAU-MIB [27] is REQUIRED for Ethernet-like interfaces. This MIB is needed in order to allow applications to determine the current MAU type in use by the interface, and to control autonegotiation and duplex mode for the interface. Implementing this MIB module without implementing the MAU-MIB would leave applications with no standard way to determine the media type in use, and no standard way to control the duplex mode of the interface.
MAU-MIB[27]のmauModIfCompl2承諾声明のサポートはイーサネットのようなインタフェースへのREQUIREDです。 このMIBが、アプリケーションが現在のMAUがインタフェースのそばで使用をタイプすることを決定して、autonegotiationと重複のモードをインタフェースに制御するのを許容するのに必要です。 標準の道なしで実装することのないMAU-MIBがそうするこのMIBモジュールに休暇届を実装して、使用をタイプしますが、メディアを決定するために、インタフェースの重複のモードを制御するどんな標準の方法もタイプしないでください。
3.4. dot3StatsEtherChipSet
3.4. dot3StatsEtherChipSet
This document defines an object called dot3StatsEtherChipSet, which is used to identify the MAC hardware used to communicate on an interface. Previous versions of this document contained a number of OID assignments for some existing Ethernet chipsets. Maintaining
このドキュメントはインタフェースについて話し合うのに使用されるMACハードウェアを特定するのに使用されるdot3StatsEtherChipSetと呼ばれるオブジェクトを定義します。 このドキュメントの旧バージョンはいくつかの既存のイーサネットチップセットのための多くのOID課題を含みました。 維持
Flick & Johnson Standards Track [Page 11] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[11ページ]RFC2665
that list as part of this document has proven to be problematic, so the OID assignments contained in prevous versions of this document have now been moved to a separate document [28].
このドキュメントの一部としてのそのリストが問題が多いと判明したので、このドキュメントのprevousバージョンに含まれたOID課題は今、別々のドキュメント[28]に動かされました。
The dot3StatsEtherChipSet object has now been deprecated. Implementation feedback indicates that this object is much more useful in theory than in practice. The object's utility in debugging network problems in the field appears to be limited. In those cases where it may be useful, it is not sufficient, since it identifies only the MAC chip, and not the PHY, PMD, or driver. The administrative overhead involved in maintaining a central registry of chipset OIDs cannot be justified for an object whose usefulness is questionable at best.
dot3StatsEtherChipSetオブジェクトは現在、推奨しないです。 実装フィードバックは、このオブジェクトが習慣より理論上はるかに役に立つのを示します。 その分野でネットワーク問題をデバッグすることにおけるオブジェクトのユーティリティは制限されるように見えます。 役に立つかもしれないそれらの場合では、それは十分ではありません、PHY、PMD、またはドライバーではなく、MACチップだけを特定するので。有用性がせいぜい疑わしいオブジェクトのためにチップセットOIDsの中央の登録を維持するのに伴われる管理オーバーヘッドは正当化できません。
Implementations which continue to support this object for the purpose of backwards compatability may continue to use the values defined in [28]. For chipsets not listed in [28], implementors should assign OBJECT IDENTIFIERS within that part of the registration tree delegated to individual enterprises.
後方にの目的のためのこのオブジェクトがcompatabilityであるとサポートし続けている実装は、[28]で定義された値を使用し続けるかもしれません。 [28]に記載されなかったチップセットに関しては、作成者は個人企業へ代表として派遣された登録木のその部分の中でOBJECT IDENTIFIERSを割り当てるべきです。
3.5. Mapping of IEEE 802.3 Managed Objects
3.5. IEEE802.3管理オブジェクトに関するマッピング
IEEE 802.3 Managed Object Corresponding SNMP Object
IEEE802.3の管理オブジェクトの対応するSNMPオブジェクト
oMacEntity
.aMACID dot3StatsIndex or
IF-MIB - ifIndex
.aFramesTransmittedOK IF-MIB - ifOutUCastPkts +
ifOutMulticastPkts +
ifOutBroadcastPkts*
.aSingleCollisionFrames dot3StatsSingleCollisionFrames
.aMultipleCollisionFrames dot3StatsMultipleCollisionFrames
.aFramesReceivedOK IF-MIB - ifInUcastPkts +
ifInMulticastPkts +
ifInBroadcastPkts*
.aFrameCheckSequenceErrors dot3StatsFCSErrors
.aAlignmentErrors dot3StatsAlignmentErrors
.aOctetsTransmittedOK IF-MIB - ifOutOctets*
.aFramesWithDeferredXmissions dot3StatsDeferredTransmissions
.aLateCollisions dot3StatsLateCollisions
.aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions
.aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors
.aCarrierSenseErrors dot3StatsCarrierSenseErrors
.aOctetsReceivedOK IF-MIB - ifInOctets*
.aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors
.aPromiscuousStatus IF-MIB - ifPromiscuousMode
.aReadMulticastAddressList IF-MIB - ifRcvAddressTable
.aMulticastFramesXmittedOK IF-MIB - ifOutMulticastPkts*
oまたは、MacEntity .aMACID dot3StatsIndex、-、MIB、--、ifIndex .aFramesTransmittedOK、-、MIB、--ifOutUCastPkts+ifOutMulticastPkts+ifOutBroadcastPkts*.aSingleCollisionFrames dot3StatsSingleCollisionFrames.aMultipleCollisionFrames dot3StatsMultipleCollisionFrames; aFramesReceivedOK、-、MIB、--、ifInUcastPkts+ifInMulticastPkts+ifInBroadcastPkts*.aFrameCheckSequenceErrors dot3StatsFCSErrors.aAlignmentErrors dot3StatsAlignmentErrors .aOctetsTransmittedOK、-、MIB、--ifOutOctets*.aFramesWithDeferredXmissions dot3StatsDeferredTransmissions; aLateCollisions dot3StatsLateCollisions.aFramesAbortedDueToXSColls dot3StatsExcessiveCollisions.aFramesLostDueToIntMACXmitError dot3StatsInternalMacTransmitErrors.aCarrierSenseErrors dot3StatsCarrierSenseErrors .aOctetsReceivedOK、-、MIB、--、ifInOctets*.aFramesLostDueToIntMACRcvError dot3StatsInternalMacReceiveErrors .aPromiscuousStatus、-、MIB、--、ifPromiscuousMode .aReadMulticastAddressList、-、MIB、--、ifRcvAddressTable .aMulticastFramesXmittedOK、-、MIB、--、ifOutMulticastPkts*
Flick & Johnson Standards Track [Page 12] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[12ページ]RFC2665
.aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts*
.aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts*
.aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts*
.aFrameTooLongErrors dot3StatsFrameTooLongs
.aReadWriteMACAddress IF-MIB - ifPhysAddress
.aCollisionFrames dot3CollFrequencies
.aDuplexStatus dot3StatsDuplexStatus
.acAddGroupAddress IF-MIB - ifRcvAddressTable
.acDeleteGroupAddress IF-MIB - ifRcvAddressTable
.acExecuteSelfTest dot3TestLoopBack
.aBroadcastFramesXmittedOK IF-MIB - ifOutBroadcastPkts* .aMulticastFramesReceivedOK IF-MIB - ifInMulticastPkts* .aBroadcastFramesReceivedOK IF-MIB - ifInBroadcastPkts* .aFrameTooLongErrors dot3StatsFrameTooLongs .aReadWriteMACAddress IF-MIB - ifPhysAddress .aCollisionFrames dot3CollFrequencies .aDuplexStatus dot3StatsDuplexStatus .acAddGroupAddress IF-MIB - ifRcvAddressTable .acDeleteGroupAddress IF-MIB - ifRcvAddressTable .acExecuteSelfTest dot3TestLoopBack
oPHYEntity
.aPHYID dot3StatsIndex or
IF-MIB - ifIndex
.aSQETestErrors dot3StatsSQETestErrors
.aSymbolErrorDuringCarrier dot3StatsSymbolErrors
oまたは、PHYEntity .aPHYID dot3StatsIndex、-、MIB、--、ifIndex .aSQETestErrors dot3StatsSQETestErrors.aSymbolErrorDuringCarrier dot3StatsSymbolErrors
oMACControlEntity
.aMACControlID dot3StatsIndex or
IF-MIB - ifIndex
.aMACControlFunctionsSupported dot3ControlFunctionsSupported and
dot3ControlFunctionsEnabled
.aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes
oまたは、MACControlEntity .aMACControlID dot3StatsIndex、-、MIB、--、ifIndex .aMACControlFunctionsSupported dot3ControlFunctionsSupportedとdot3ControlFunctionsEnabled.aUnsupportedOpcodesReceived dot3ControlInUnknownOpcodes
oPAUSEEntity
.aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames
.aPAUSEMACCtrlFramesReceived dot3InPauseFrames
oPAUSEEntity .aPAUSEMACCtrlFramesTransmitted dot3OutPauseFrames.aPAUSEMACCtrlFramesReceived dot3InPauseFrames
* Note that the octet counters in IF-MIB do not exactly match the definition of the octet counters in IEEE 802.3. aOctetsTransmittedOK and aOctetsReceivedOK count only the octets in the clientData and Pad fields, whereas ifInOctets and ifOutOctets include the entire MAC frame, including MAC header and FCS. However, the IF-MIB counters can be derived from the IEEE 802.3 counters as follows:
* まさにIEEE802.3との八重奏カウンタの定義に合わないでください。八重奏が中で反対することに注意してください、-、MIB、aOctetsTransmittedOKとaOctetsReceivedOKはclientDataとPad分野で八重奏だけを数えますが、ifInOctetsとifOutOctetsは全体のMACフレームを含んでいます、MACヘッダーとFCSを含んでいて。 しかしながら、-、MIB、カウンタは以下のIEEE802.3から派生しているカウンタであるかもしれません:
ifInOctets = aOctetsReceivedOK + (18 * aFramesReceivedOK)
ifInOctetsはaOctetsReceivedOK+と等しいです。(18*aFramesReceivedOK)
ifOutOctets = aOctetsTransmittedOK + (18 * aFramesTransmittedOK)
ifOutOctetsはaOctetsTransmittedOK+と等しいです。(18*aFramesTransmittedOK)
Also note that the packet counters in the IF-MIB do not exactly match the definition of the frame counters in IEEE 802.3. aFramesTransmittedOK counts the number of frames successfully transmitted on the interface, whereas ifOutUcastPkts, ifOutMulticastPkts and ifOutBroadcastPkts count the number of transmit requests made from a higher layer, whether or not the transmit attempt was successful. This means that packets counted by ifOutErrors or ifOutDiscards are also be counted by ifOut*castPkts, but are not be counted by aFramesTransmittedOK. This also means
伝わってください。また、パケットが中で反対することに注意してください、-、MIB、ちょうどIEEE802.3aFramesTransmittedOKとのフレームカウンタの定義がifOutUcastPkts、ifOutMulticastPkts、およびifOutBroadcastPktsが数を数えますが、インタフェースで首尾よく伝えられたフレームの数を数えるマッチが、より高い層でされた要求を伝えない、試みはうまくいきました。 ifOutErrorsかifOutDiscardsによって数えられたパケットがそうであるこの手段は、また、ifOut*castPktsが数えられますが、あります。aFramesTransmittedOKによって数えられません。 また、これは意味します。
Flick & Johnson Standards Track [Page 13] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[13ページ]RFC2665
that, since MAC Control frames are generated by a sublayer internal to the interface layer rather than by a higher layer, they are not counted by ifOut*castPkts, but are counted by aFramesTransmittedOK.
MAC Controlフレームが、より高い層のそばでというよりむしろインタフェース層への内部の副層で発生するので、それらは、ifOut*castPktsによって数えられませんが、aFramesTransmittedOKによって数えられます。
Similarly, aFramesReceivedOK counts the number of frames received successfully by the interface, whether or not they are passed to a higher layer, whereas ifInUcastPkts, ifInMulticastPkts and ifInBroadcastPkts count only the number of packets passed to a higher layer. This means that packets counted by ifInDiscards or ifInUnknownProtos are also counted by aFramesReceivedOK, but are not counted by ifIn*castPkts. This also menas that, since MAC Control frames are consumed by a sublayer internal to the interface layer and not passed to a higher layer, they are not counted by ifIn*castPkts, but are counted by aFramesReceivedOK.
同様に、ifInUcastPkts、ifInMulticastPkts、およびifInBroadcastPktsがパケットの数だけを数えますが、それらが、より高い層に通過されるか否かに関係なく、フレームの数がインタフェースで首尾よく受けたaFramesReceivedOKカウントは、より高い層に終わりました。 これは、ifInDiscardsかifInUnknownProtosによって数えられたパケットがまた、aFramesReceivedOKが数えられますが、ifIn*castPktsによって数えられないことを意味します。 また、これはそれをmenasします、MAC Controlフレームがインタフェース層への内部の副層によって消費されて、より高い層に通り過ぎられないで、それらがifIn*castPktsによって数えられませんが、aFramesReceivedOKによって数えられるので。
Another difference to keep in mind between the IF-MIB counters and IEEE 802.3 counters is that in the IEEE 802.3 document, the frame counters and octet counters are always incremented together. aOctetsTransmittedOK counts the number of octets in frames that were counted by aFramesTransmittedOK. aOctetsReceivedOK counts the number of octets in frames that were counted by aFramesReceivedOK. This is not the case with the IF-MIB counters. The IF-MIB octet counters count the number of octets sent to or received from the layer below this interface, whereas the packet counters count the number of packets sent to or received from the layer above. Therefore, received MAC Control frames, ifInDiscards, and ifInUnknownProtos are counted by ifInOctets, but not ifIn*castPkts. Transmitted MAC Control frames are counted by ifOutOctets, but not ifOut*castPkts. ifOutDiscards and ifOutErrors are counted by ifOut*castPkts, but not ifOutOctets.
カウンタとIEEE802.3カウンタによるIEEE802.3ドキュメントでは、フレームカウンタと八重奏カウンタがいつも一緒に増加されるということです。念頭に保つ別の違い、-、MIB、aOctetsTransmittedOKは八重奏の数が中で縁どるaFramesReceivedOKによって数えられたaFramesTransmittedOK. aOctetsReceivedOKカウントで数えられたフレームの八重奏の数を数えます。 これがそうでない、-、MIB、カウンタ。 -、MIB、八重奏カウンタはこのインタフェースの下で層から送られたか受け取られていている八重奏の数を数えますが、パケットカウンタは上で層から送られたか受け取られていているパケットの数を数えます。 したがって、容認されたMAC Controlフレーム、ifInDiscards、およびifInUnknownProtosはifIn*castPktsではなく、ifInOctetsによって数えられます。 伝えられたMAC ControlフレームはifOut*castPkts. ifOutDiscardsではなく、ifOutOctetsによって数えられます、そして、ifOutErrorsはifOutOctetsではなく、ifOut*castPktsによって数えられます。
The following IEEE 802.3 managed objects have been removed from this MIB module as a result of implementation feedback:
以下のIEEE802.3に、実現フィードバックの結果、このMIBモジュールから管理オブジェクトを取り除きました:
oMacEntity
.aFramesWithExcessiveDeferral
.aInRangeLengthErrors
.aOutOfRangeLengthField
.aMACEnableStatus
.aTransmitEnableStatus
.aMulticastReceiveStatus
.acInitializeMAC
oMacEntity .aFramesWithExcessiveDeferral.aInRangeLengthErrors .aOutOfRangeLengthField.aMACEnableStatus .aTransmitEnableStatus.aMulticastReceiveStatus .acInitializeMAC
Please see [19] for the detailed reasoning on why these objects were removed.
これらの物が取り除かれた理由における詳細な推理のための[19]を見てください。
In addition, the following IEEE 802.3 managed objects have not been included in this MIB for the following reasons.
さらに、以下のIEEE802.3に、管理オブジェクトは以下の理由によるこのMIBに含まれていません。
Flick & Johnson Standards Track [Page 14] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[14ページ]RFC2665
IEEE 802.3 Managed Object Disposition
IEEE802.3管理オブジェクト気質
oMACEntity
.aMACCapabilities Can be derived from
MAU-MIB - ifMauTypeListBits
oMACEntity .aMACCapabilities Can、MAU-MIBから、派生してください--、ifMauTypeListBits
oPHYEntity
.aPhyType Can be derived from
MAU-MIB - ifMauType
oPHYEntity .aPhyType Can、MAU-MIBから、派生してください--、ifMauType
.aPhyTypeList Can be derived from
MAU-MIB - ifMauTypeListBits
.aPhyTypeList Can、MAU-MIBから、派生してください--、ifMauTypeListBits
.aMIIDetect Not considered useful.
.aMIIDetect Notは役に立った状態で考えました。
.aPhyAdminState Can already obtain interface
state from IF-MIB - ifOperStatus
and MAU state from MAU-MIB -
ifMauStatus. Providing an
additional state for the PHY
was not considered useful.
.aPhyAdminState Canが既に界面準位を得る、-、MIB、--MAU-MIBからのifOperStatusとMAU状態--ifMauStatus。 追加状態をPHYに供給するのは役に立つと考えられませんでした。
.acPhyAdminControl Can already control interface
state from IF-MIB - ifAdminStatus
and MAU state from MAU-MIB -
ifMauStatus. Providing separate
admin control of the PHY was not
considered useful.
.acPhyAdminControl Canが既に界面準位を制御する、-、MIB、--MAU-MIBからのifAdminStatusとMAU状態--ifMauStatus。 PHYの別々のアドミンコントロールを提供するのは役に立つと考えられませんでした。
oMACControlEntity
.aMACControlFramesTransmitted Can be determined by summing the
OutFrames counters for the
individual control functions
oOutFramesをまとめることによって、個々のコントロールのために機能を打ち返しますMACControlEntity .aMACControlFramesTransmitted Canが決心している。
.aMACControlFramesReceived Can be determined by summing the
InFrames counters for the
individual control functions
InFramesをまとめることによって、個々のコントロールのために機能を打ち返します.aMACControlFramesReceived Canが決心している。
oPAUSEEntity
.aPAUSELinkDelayAllowance Not considered useful.
oPAUSEEntity .aPAUSELinkDelayAllowance Notは役に立った状態で考えました。
Flick & Johnson Standards Track [Page 15] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[15ページ]RFC2665
4. Definitions
4. 定義
EtherLike-MIB DEFINITIONS ::= BEGIN
EtherLike-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
Counter32, mib-2, transmission
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF
ifIndex, InterfaceIndex
FROM IF-MIB;
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、OBJECT-IDENTITY、Counter32、mib-2、トランスミッションFROM SNMPv2-SMI MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF ifIndex、InterfaceIndex FROM、-、MIB、。
etherMIB MODULE-IDENTITY
LAST-UPDATED "9908240400Z" -- August 24, 1999
ORGANIZATION "IETF Ethernet Interfaces and Hub MIB
Working Group"
CONTACT-INFO
"WG E-mail: hubmib@hprnd.rose.hp.com
To subscribe: hubmib-request@hprnd.rose.hp.com
etherMIBモジュールアイデンティティ最終更新日の"9908240400Z"--「WGは以下をメールする」という1999年8月24日組織「IETFイーサネットインタフェースとハブMIBワーキンググループ」コンタクトインフォメーション 申し込む hubmib@hprnd.rose.hp.com : hubmib-request@hprnd.rose.hp.com
Chair: Dan Romascanu
Postal: Lucent Technologies
Atidum Technology Park, Bldg. 3
Tel Aviv 61131
Israel
Tel: +972 3 645 8414
E-mail: dromasca@lucent.com
議長: ダンRomascanu郵便: ルーセントテクノロジーズAtidum技術公園、ビルディング 3 テルアビブ61131イスラエルTel: +972 3 645 8414はメールされます: dromasca@lucent.com
Editor: John Flick
Postal: Hewlett-Packard Company
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747-5557
USA
Tel: +1 916 785 4018
Fax: +1 916 785 1199
E-mail: johnf@rose.hp.com
エディタ: ジョンFlick郵便: ヒューレット・パッカード会社8000山麓の丘Blvd. S5557ローズビル、カリフォルニア95747-5557M/米国Tel: +1 916 785、4018Fax: +1 1199年の916 785メール: johnf@rose.hp.com
Editor: Jeffrey Johnson
Postal: RedBack Networks
2570 North First Street, Suite 410
San Jose, CA, 95131
USA
Tel: +1 408 571 2699
Fax: +1 408 571 2698
E-Mail: jeff@redbacknetworks.com"
エディタ: ジェフリー・ジョンソンPostal: 20ドル紙幣は2570北でFirst通り、Suite410サンノゼ、カリフォルニア95131米国Tel:をネットワークでつなぎます。 +1 408 571、2699Fax: +1 2698年の408 571メール: " jeff@redbacknetworks.com "
DESCRIPTION "The MIB module to describe generic objects for
記述は「一般的な物について説明するMIBモジュール」です。
Flick & Johnson Standards Track [Page 16] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[16ページ]RFC2665
Ethernet-like network interfaces.
イーサネットのようなネットワークは連結します。
The following reference is used throughout this
MIB module:
以下の参照はこのMIBモジュール中で使用されます:
[IEEE 802.3 Std] refers to:
IEEE Std 802.3, 1998 Edition: 'Information
technology - Telecommunications and
information exchange between systems -
Local and metropolitan area networks -
Specific requirements - Part 3: Carrier
sense multiple access with collision
detection (CSMA/CD) access method and
physical layer specifications',
September 1998.
[IEEE802.3Std] 言及します: IEEE Std802.3、1998版: '情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(決められた一定の要求)は3を分けます' 1998年9月の衝突検出(CSMA/CD)アクセス法と物理的な仕様の層のものがある搬送波感知多重アクセス。
Of particular interest is Clause 30, '10Mb/s,
100Mb/s and 1000Mb/s Management'."
「特別の関心は、Clause30と、'10Mb/s、100Mb/s、および1000Mb/sのManagement'です。」
REVISION "9908240400Z" -- August 24, 1999
DESCRIPTION "Updated to include support for 1000 Mb/sec
interfaces and full-duplex interfaces.
This version published as RFC 2665."
REVISION"9908240400Z"--「1000Mb/秒のインタフェースと全二重インタフェースのサポートを含むようにアップデートする」1999年8月24日記述。 「RFC2665として発行されたこのバージョン。」
REVISION "9806032150Z"
DESCRIPTION "Updated to include support for 100 Mb/sec
interfaces.
This version published as RFC 2358."
「100Mb/秒のインタフェースのサポートを含むようにアップデートする」REVISION"9806032150Z"記述。 「RFC2358として発行されたこのバージョン。」
REVISION "9402030400Z"
DESCRIPTION "Initial version, published as RFC 1650."
「初期のバージョンであって、RFC1650として発行された」REVISION"9402030400Z"記述。
::= { mib-2 35 }
::= mib-2 35
etherMIBObjects OBJECT IDENTIFIER ::= { etherMIB 1 }
etherMIBObjects物の識別子:、:= etherMIB1
dot3 OBJECT IDENTIFIER ::= { transmission 7 }
dot3 OBJECT IDENTIFIER:、:= トランスミッション7
-- the Ethernet-like Statistics group
-- イーサネットのようなStatisticsグループ
dot3StatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3StatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Statistics for a collection of ethernet-like
interfaces attached to a particular system.
There will be one row in this table for each
「イーサネットのようなインタフェースの収集のための統計は特定のシステムに取り付けた」dot3StatsTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3StatsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 1つの列がそれぞれのためのこのテーブルにあるでしょう。
Flick & Johnson Standards Track [Page 17] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[17ページ]RFC2665
ethernet-like interface in the system."
::= { dot3 2 }
「システムのイーサネットのようなインタフェース。」 ::= dot3 2
dot3StatsEntry OBJECT-TYPE
SYNTAX Dot3StatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "Statistics for a particular interface to an
ethernet-like medium."
INDEX { dot3StatsIndex }
::= { dot3StatsTable 1 }
dot3StatsEntry OBJECT-TYPE SYNTAX Dot3StatsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「イーサネットのような媒体への特定のインタフェースへの統計。」 dot3StatsIndexに索引をつけてください:、:= dot3StatsTable1
Dot3StatsEntry ::=
SEQUENCE {
dot3StatsIndex InterfaceIndex,
dot3StatsAlignmentErrors Counter32,
dot3StatsFCSErrors Counter32,
dot3StatsSingleCollisionFrames Counter32,
dot3StatsMultipleCollisionFrames Counter32,
dot3StatsSQETestErrors Counter32,
dot3StatsDeferredTransmissions Counter32,
dot3StatsLateCollisions Counter32,
dot3StatsExcessiveCollisions Counter32,
dot3StatsInternalMacTransmitErrors Counter32,
dot3StatsCarrierSenseErrors Counter32,
dot3StatsFrameTooLongs Counter32,
dot3StatsInternalMacReceiveErrors Counter32,
dot3StatsEtherChipSet OBJECT IDENTIFIER,
dot3StatsSymbolErrors Counter32,
dot3StatsDuplexStatus INTEGER
}
Dot3StatsEntry:、:= 系列{ dot3StatsIndex InterfaceIndex、dot3StatsAlignmentErrors Counter32、dot3StatsFCSErrors Counter32、dot3StatsSingleCollisionFrames Counter32、dot3StatsMultipleCollisionFrames Counter32、dot3StatsSQETestErrors Counter32、dot3StatsDeferredTransmissions Counter32、dot3StatsLateCollisions Counter32; dot3StatsExcessiveCollisions Counter32、dot3StatsInternalMacTransmitErrors Counter32、dot3StatsCarrierSenseErrors Counter32、dot3StatsFrameTooLongs Counter32、dot3StatsInternalMacReceiveErrors Counter32、dot3StatsEtherChipSet物の識別子、dot3StatsSymbolErrors Counter32、dot3StatsDuplexStatus整数; }
dot3StatsIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An index value that uniquely identifies an
interface to an ethernet-like medium. The
interface identified by a particular value of
this index is the same interface as identified
by the same value of ifIndex."
REFERENCE "RFC 2233, ifIndex"
::= { dot3StatsEntry 1 }
dot3StatsIndex OBJECT-TYPE SYNTAX InterfaceIndexのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「唯一イーサネットのような媒体にインタフェースを特定するインデックス値。」 「このインデックスの特定の値によって特定されたインタフェースはifIndexの同じ値によって特定されるように同じインタフェースです。」 「RFC2233、ifIndex」という参照:、:= dot3StatsEntry1
dot3StatsAlignmentErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
dot3StatsAlignmentErrors OBJECT-TYPE SYNTAX Counter32マックス-ACCESS書き込み禁止STATUS海流
Flick & Johnson Standards Track [Page 18] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[18ページ]RFC2665
DESCRIPTION "A count of frames received on a particular
interface that are not an integral number of
octets in length and do not pass the FCS check.
「フレームのカウントは長さにおける、整数の八重奏でなく、またFCSチェックを通過しない特定のインタフェースで受けた」記述。
The count represented by an instance of this
object is incremented when the alignmentError
status is returned by the MAC service to the
LLC (or other MAC user). Received frames for
which multiple error conditions obtain are,
according to the conventions of IEEE 802.3
Layer Management, counted exclusively according
to the error status presented to the LLC.
alignmentError状態がLLC(または、他のMACユーザ)に対するMACサービスで返されるとき、この物の例によって表されたカウントは増加されています。 排他的なLLCに提示されたエラー状況によると、エラー条件が得るどの倍数がIEEE802.3Layer Managementのコンベンションで数えられるかために、フレーム搬入しました。
This counter does not increment for 8-bit wide
group encoding schemes.
このカウンタは8ビットの広いグループのためにコード化計画を増加しません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.7,
aAlignmentErrors"
::= { dot3StatsEntry 2 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .7、aAlignmentErrors、」、:、:= dot3StatsEntry2
dot3StatsFCSErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames received on a particular
interface that are an integral number of octets
in length but do not pass the FCS check. This
count does not include frames received with
frame-too-long or frame-too-short error.
「フレームのカウントは長さにおける、整数の八重奏ですが、FCSチェックを通過しない特定のインタフェースで受けた」dot3StatsFCSErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このカウントはまた、長さ縁どっているか、またはまた、ショートを罪に陥れている誤りで受け取られたフレームを含んでいません。
The count represented by an instance of this
object is incremented when the frameCheckError
status is returned by the MAC service to the
LLC (or other MAC user). Received frames for
which multiple error conditions obtain are,
according to the conventions of IEEE 802.3
Layer Management, counted exclusively according
to the error status presented to the LLC.
frameCheckError状態がLLC(または、他のMACユーザ)に対するMACサービスで返されるとき、このオブジェクトのインスタンスによって表されたカウントは増加されています。 排他的なLLCに提示されたエラー状況によると、エラー条件が得るどの倍数がIEEE802.3Layer Managementのコンベンションで数えられるかために、フレーム搬入しました。
Note: Coding errors detected by the physical
layer for speeds above 10 Mb/s will cause the
frame to fail the FCS check.
Discontinuities in the value of this counter can
occur at re-initialization of the management
以下に注意してください。 10Mb/sの速度のために物理的な層によって検出されたコード化誤りはフレームがFCSチェックに失敗されるでしょう。 このカウンタの値における不連続は管理の再初期化で起こることができます。
Flick & Johnson Standards Track [Page 19] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[19ページ]RFC2665
system, and at other times as indicated by the
value of ifCounterDiscontinuityTime."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.6,
aFrameCheckSequenceErrors."
::= { dot3StatsEntry 3 }
「システム、ifCounterDiscontinuityTimeの値によって示される他の時、」 参照、「[IEEE802.3Std]、30.3、.1 .1 .6、aFrameCheckSequenceErrors、」 ::= dot3StatsEntry3
dot3StatsSingleCollisionFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of successfully transmitted frames on
a particular interface for which transmission
is inhibited by exactly one collision.
「首尾よく伝えられることのカウントはトランスミッションがまさに1回の衝突で抑制される特定のインタフェースで縁どる」dot3StatsSingleCollisionFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
A frame that is counted by an instance of this
object is also counted by the corresponding
instance of either the ifOutUcastPkts,
ifOutMulticastPkts, or ifOutBroadcastPkts,
and is not counted by the corresponding
instance of the dot3StatsMultipleCollisionFrames
object.
このオブジェクトのインスタンスによって数えられるフレームは、また、ifOutUcastPkts、ifOutMulticastPktsかifOutBroadcastPktsのどちらかの対応するインスタンスが数えられて、dot3StatsMultipleCollisionFramesオブジェクトの対応するインスタンスによって数えられません。
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.3,
aSingleCollisionFrames."
::= { dot3StatsEntry 4 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .3、aSingleCollisionFrames、」 ::= dot3StatsEntry4
dot3StatsMultipleCollisionFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of successfully transmitted frames on
a particular interface for which transmission
is inhibited by more than one collision.
「首尾よく伝えられることのカウントはトランスミッションが1回以上の衝突で抑制される特定のインタフェースで縁どる」dot3StatsMultipleCollisionFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
A frame that is counted by an instance of this
object is also counted by the corresponding
instance of either the ifOutUcastPkts,
ifOutMulticastPkts, or ifOutBroadcastPkts,
and is not counted by the corresponding
instance of the dot3StatsSingleCollisionFrames
object.
このオブジェクトのインスタンスによって数えられるフレームは、また、ifOutUcastPkts、ifOutMulticastPktsかifOutBroadcastPktsのどちらかの対応するインスタンスが数えられて、dot3StatsSingleCollisionFramesオブジェクトの対応するインスタンスによって数えられません。
Flick & Johnson Standards Track [Page 20] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[20ページ]RFC2665
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.4,
aMultipleCollisionFrames."
::= { dot3StatsEntry 5 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .4、aMultipleCollisionFrames、」 ::= dot3StatsEntry5
dot3StatsSQETestErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of times that the SQE TEST ERROR
message is generated by the PLS sublayer for a
particular interface. The SQE TEST ERROR
is set in accordance with the rules for
verification of the SQE detection mechanism in
the PLS Carrier Sense Function as described in
IEEE Std. 802.3, 1998 Edition, section 7.2.4.6.
「SQE TEST ERRORメッセージは回ですが、PLS副層によって特定のインタフェースに生成されて、Aは数える」dot3StatsSQETestErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 PLS Carrier Sense FunctionでのSQE検出メカニズムの検証のための規則に従って、SQE TEST ERRORはIEEE Stdで説明されるようにセットです。 802.3(1998Edition)は7.2に.6に.4を区分します。
This counter does not increment on interfaces
operating at speeds greater than 10 Mb/s, or on
interfaces operating in full-duplex mode.
インタフェースの増分が速度で10Mb/s、またはインタフェースを作動させて、このカウンタは、全二重モードで作動しながら、そうしません。
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."
REFERENCE "[IEEE 802.3 Std.], 7.2.4.6, also 30.3.2.1.4,
aSQETestErrors."
::= { dot3StatsEntry 6 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 また、REFERENCE、「[IEEE802.3Std]、7.2、.4 .6、30.3 .2 .1 .4、aSQETestErrors、」 ::= dot3StatsEntry6
dot3StatsDeferredTransmissions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames for which the first
transmission attempt on a particular interface
is delayed because the medium is busy.
The count represented by an instance of this
object does not include frames involved in
collisions.
dot3StatsDeferredTransmissions OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「媒体が忙しいので特定のインタフェースへの最初のトランスミッション試みが遅れるフレームのカウント。」 このオブジェクトのインスタンスによって表されたカウントは衝突にかかわるフレームを含んでいません。
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
Flick & Johnson Standards Track [Page 21] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[21ページ]RFC2665
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.9,
aFramesWithDeferredXmissions."
::= { dot3StatsEntry 7 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .9、aFramesWithDeferredXmissions、」 ::= dot3StatsEntry7
dot3StatsLateCollisions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that a collision is
detected on a particular interface later than
one slotTime into the transmission of a packet.
dot3StatsLateCollisions OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「衝突が1slotTimeより遅く特定のインタフェースにパケットのトランスミッションに検出されるという回の数。」
A (late) collision included in a count
represented by an instance of this object is
also considered as a (generic) collision for
purposes of other collision-related
statistics.
また、このオブジェクトのインスタンスによって表されたカウントに(遅い)の衝突を含んでいるのは他の衝突関連の統計の目的のための(ジェネリック)衝突であるとみなされます。
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.10,
aLateCollisions."
::= { dot3StatsEntry 8 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .10、aLateCollisions、」 ::= dot3StatsEntry8
dot3StatsExcessiveCollisions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames for which transmission on a
particular interface fails due to excessive
collisions.
This counter does not increment when the
interface is operating in full-duplex mode.
dot3StatsExcessiveCollisions 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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.11,
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .11インチ
Flick & Johnson Standards Track [Page 22] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[22ページ]RFC2665
aFramesAbortedDueToXSColls."
::= { dot3StatsEntry 9 }
「aFramesAbortedDueToXSColls。」 ::= dot3StatsEntry9
dot3StatsInternalMacTransmitErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames for which transmission on a
particular interface fails due to an internal
MAC sublayer transmit error. A frame is only
counted by an instance of this object if it is
not counted by the corresponding instance of
either the dot3StatsLateCollisions object, the
dot3StatsExcessiveCollisions object, or the
dot3StatsCarrierSenseErrors object.
dot3StatsInternalMacTransmitErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「事項におけるどのトランスミッションが連結するかが内部のMAC副層のため失敗するので、フレームのカウントは誤りを伝えます」。 それがdot3StatsLateCollisionsオブジェクト、dot3StatsExcessiveCollisionsオブジェクトかdot3StatsCarrierSenseErrorsオブジェクトのどちらかの対応するインスタンスによって数えられない場合にだけ、フレームはこのオブジェクトのインスタンスによって数えられます。
The precise meaning of the count represented by
an instance of this object is implementation-
specific. In particular, an instance of this
object may represent a count of transmission
errors on a particular interface that are not
otherwise counted.
このオブジェクトのインスタンスによって表されたカウントの正確な意味は実装特有です。 特に、このオブジェクトのインスタンスは特定のインタフェースの別の方法で数えられない伝送エラーのカウントを表すかもしれません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.12,
aFramesLostDueToIntMACXmitError."
::= { dot3StatsEntry 10 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .12、aFramesLostDueToIntMACXmitError、」 ::= dot3StatsEntry10
dot3StatsCarrierSenseErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the carrier sense
condition was lost or never asserted when
attempting to transmit a frame on a particular
interface.
dot3StatsCarrierSenseErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「特定のインタフェースでフレームを伝えるのを試みるとき、キャリヤーが状態に気付くという回の数は、失われたか、または決して断言されませんでした」。
The count represented by an instance of this
object is incremented at most once per
transmission attempt, even if the carrier sense
condition fluctuates during a transmission
attempt.
このオブジェクトのインスタンスによって表されたカウントは高々トランスミッション試みに一度増加されます、キャリア検知状態がトランスミッション試みの間、変動しても。
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
Flick & Johnson Standards Track [Page 23] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[23ページ]RFC2665
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.13,
aCarrierSenseErrors."
::= { dot3StatsEntry 11 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .13、aCarrierSenseErrors、」 ::= dot3StatsEntry11
-- { dot3StatsEntry 12 } is not assigned
-- dot3StatsEntry12は割り当てられません。
dot3StatsFrameTooLongs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames received on a particular
interface that exceed the maximum permitted
frame size.
「フレームのカウントはフレーム・サイズが受入れられた最大を超えている特定のインタフェースで受けた」dot3StatsFrameTooLongs OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
The count represented by an instance of this
object is incremented when the frameTooLong
status is returned by the MAC service to the
LLC (or other MAC user). Received frames for
which multiple error conditions obtain are,
according to the conventions of IEEE 802.3
Layer Management, counted exclusively according
to the error status presented to the LLC.
frameTooLong状態がLLC(または、他のMACユーザ)に対するMACサービスで返されるとき、このオブジェクトのインスタンスによって表されたカウントは増加されています。 排他的なLLCに提示されたエラー状況によると、エラー条件が得るどの倍数がIEEE802.3Layer Managementのコンベンションで数えられるかために、フレーム搬入しました。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.25,
aFrameTooLongErrors."
::= { dot3StatsEntry 13 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .25、aFrameTooLongErrors、」 ::= dot3StatsEntry13
-- { dot3StatsEntry 14 } is not assigned
-- dot3StatsEntry14は割り当てられません。
-- { dot3StatsEntry 15 } is not assigned
-- dot3StatsEntry15は割り当てられません。
dot3StatsInternalMacReceiveErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of frames for which reception on a
particular interface fails due to an internal
MAC sublayer receive error. A frame is only
counted by an instance of this object if it is
not counted by the corresponding instance of
dot3StatsInternalMacReceiveErrors OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「内部のMAC副層によるやり損ないが特定のインタフェースにおけるそれのレセプションに関して誤りを受けるフレームのカウント。」 それが対応するインスタンスによって数えられない場合にだけ、フレームはこのオブジェクトのインスタンスによって数えられます。
Flick & Johnson Standards Track [Page 24] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[24ページ]RFC2665
either the dot3StatsFrameTooLongs object, the
dot3StatsAlignmentErrors object, or the
dot3StatsFCSErrors object.
dot3StatsFrameTooLongsが反対するか、dot3StatsAlignmentErrorsが反対するか、またはdot3StatsFCSErrorsは反対します。
The precise meaning of the count represented by
an instance of this object is implementation-
specific. In particular, an instance of this
object may represent a count of receive errors
on a particular interface that are not
otherwise counted.
このオブジェクトのインスタンスによって表されたカウントの正確な意味は実装特有です。 特に、このオブジェクトのインスタンスがカウントを表すかもしれない、特定のインタフェースにおける別の方法で数えられない誤りを受けてください。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.15,
aFramesLostDueToIntMACRcvError."
::= { dot3StatsEntry 16 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .15、aFramesLostDueToIntMACRcvError、」 ::= dot3StatsEntry16
dot3StatsEtherChipSet OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION "******** THIS OBJECT IS DEPRECATED ********
「dot3StatsEtherChipSet OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSの書き込み禁止のSTATUSの推奨しない記述」********はこれが、反対する推奨しない********です。
This object contains an OBJECT IDENTIFIER
which identifies the chipset used to
realize the interface. Ethernet-like
interfaces are typically built out of
several different chips. The MIB implementor
is presented with a decision of which chip
to identify via this object. The implementor
should identify the chip which is usually
called the Medium Access Control chip.
If no such chip is easily identifiable,
the implementor should identify the chip
which actually gathers the transmit
and receive statistics and error
indications. This would allow a
manager station to correlate the
statistics and the chip generating
them, giving it the ability to take
into account any known anomalies
in the chip."
::= { dot3StatsEntry 17 }
このオブジェクトはインタフェースがわかるのに使用されるチップセットを特定するOBJECT IDENTIFIERを含んでいます。 イーサネットのようなインタフェースは数個の異なったチップから通常造られます。 このオブジェクトを通してどのチップを特定したらよいかに関する決定をMIB作成者に与えます。 作成者は通常、Medium Access Controlチップと呼ばれるチップを特定するべきです。 そのようなどれかチップが容易に身元保証可能でないなら、作成者が実際に集まるチップを特定するべきである、統計と誤り指摘を送受信してください。 「マネージャステーションはこれで統計とそれらを生成するチップを関連させることができるでしょう、チップのどんな知られている例外も考慮に入れる能力をそれに与えて。」 ::= dot3StatsEntry17
dot3StatsSymbolErrors OBJECT-TYPE
SYNTAX Counter32
dot3StatsSymbolErrorsオブジェクト・タイプ構文Counter32
Flick & Johnson Standards Track [Page 25] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[25ページ]RFC2665
MAX-ACCESS read-only
STATUS current
DESCRIPTION "For an interface operating at 100 Mb/s, the
number of times there was an invalid data symbol
when a valid carrier was present.
「100Mb/sで作動するインタフェース、有効なキャリヤーが出席していたとき、無効のデータシンボルがあったという回の数」のためのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
For an interface operating in half-duplex mode
at 1000 Mb/s, the number of times the receiving
media is non-idle (a carrier event) for a period
of time equal to or greater than slotTime, and
during which there was at least one occurrence
of an event that causes the PHY to indicate
'Data reception error' or 'carrier extend error'
on the GMII.
インタフェースに関しては、1000Mb/s、回数における半二重モードによる受信メディアを経営するのはしばらく、GMIIでどれが少なくとも1つの事件の発生があったか間、slotTime、PHYがそれで'データ受信誤り'を示すか、または'キャリヤーは誤りを広げているか'より等しいか、またはすばらしい状態で非活動していません(キャリヤーイベント)。
For an interface operating in full-duplex mode
at 1000 Mb/s, the number of times the receiving
media is non-idle a carrier event) for a period
of time equal to or greater than minFrameSize,
and during which there was at least one
occurrence of an event that causes the PHY to
indicate 'Data reception error' on the GMII.
1000Mb/s、回数における全二重モードで作動するインタフェースに関して受信メディアは非無駄です。キャリヤーイベント) しばらく、それがPHYを引き起こす等しいか、より大きいminFrameSizeと、どれがあったか間、少なくとも1つの事件の発生がGMIIで'データ受信誤り'を示します。
The count represented by an instance of this
object is incremented at most once per carrier
event, even if multiple symbol errors occur
during the carrier event. This count does
not increment if a collision is present.
このオブジェクトのインスタンスによって表されたカウントは高々キャリヤーイベントに一度増加されます、複数のシンボル誤りがキャリヤーイベントの間、発生しても。 衝突が存在しているなら、このカウントはどんな増分もしません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.2.1.5,
aSymbolErrorDuringCarrier."
::= { dot3StatsEntry 18 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.2 .1 .5、aSymbolErrorDuringCarrier、」 ::= dot3StatsEntry18
dot3StatsDuplexStatus OBJECT-TYPE
SYNTAX INTEGER {
unknown(1),
halfDuplex(2),
fullDuplex(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The current mode of operation of the MAC
entity. 'unknown' indicates that the current
duplex mode could not be determined.
dot3StatsDuplexStatus OBJECT-TYPE SYNTAX INTEGER、未知(1)、halfDuplex(2)、fullDuplex(3)、マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「MAC実体の操作の現在のモード。」 '未知'は、現在の重複のモードが決定できなかったのを示します。
Flick & Johnson Standards Track [Page 26] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[26ページ]RFC2665
Management control of the duplex mode is
accomplished through the MAU MIB. When
an interface does not support autonegotiation,
or when autonegotiation is not enabled, the
duplex mode is controlled using
ifMauDefaultType. When autonegotiation is
supported and enabled, duplex mode is controlled
using ifMauAutoNegAdvertisedBits. In either
case, the currently operating duplex mode is
reflected both in this object and in ifMauType.
重複のモードのマネジメント・コントロールはMAU MIBを通して実行されます。 インタフェースがautonegotiationをサポートしないか、またはautonegotiationが有効にされないとき、重複のモードは、ifMauDefaultTypeを使用することで制御されています。 autonegotiationがサポートされて、有効にされるとき、重複のモードは、ifMauAutoNegAdvertisedBitsを使用することで制御されています。 どちらの場合ではも、現在稼働している重複のモードはこのオブジェクトとifMauTypeに反映されます。
Note that this object provides redundant
information with ifMauType. Normally, redundant
objects are discouraged. However, in this
instance, it allows a management application to
determine the duplex status of an interface
without having to know every possible value of
ifMauType. This was felt to be sufficiently
valuable to justify the redundancy."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.32,
aDuplexStatus."
::= { dot3StatsEntry 19 }
このオブジェクトが余分な情報にifMauTypeを提供することに注意してください。 通常、余分なオブジェクトはがっかりしています。 しかしながら、この場合、それで、ifMauTypeのあらゆる可能な値を知る必要はなくて、管理アプリケーションはインタフェースの重複の状態を決定できます。 「これは冗長を正当化するのにおいて十分貴重であると感じられました。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .32、aDuplexStatus、」 ::= dot3StatsEntry19
-- the Ethernet-like Collision Statistics group
-- イーサネットのようなCollision Statisticsグループ
-- Implementation of this group is optional; it is appropriate
-- for all systems which have the necessary metering
-- このグループの実装は任意です。 必要な計量を持っているすべてのシステムに、それは適切です。
dot3CollTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3CollEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A collection of collision histograms for a
particular set of interfaces."
REFERENCE "[IEEE 802.3 Std.], 30.3.1.1.30,
aCollisionFrames."
::= { dot3 5 }
dot3CollTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3CollEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定のセットのインタフェースへの衝突ヒストグラムの収集。」 参照、「[IEEE802.3Std]、30.3、.1 .1 .30、aCollisionFrames、」 ::= dot3 5
dot3CollEntry OBJECT-TYPE
SYNTAX Dot3CollEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A cell in the histogram of per-frame
collisions for a particular interface. An
instance of this object represents the
frequency of individual MAC frames for which
the transmission (successful or otherwise) on a
particular interface is accompanied by a
「事項のための1フレームあたりの衝突のヒストグラムによるセルは連結する」dot3CollEntry OBJECT-TYPE SYNTAX Dot3CollEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 このオブジェクトのインスタンスは特定のインタフェースの(うまくいくかそうではありません)のトランスミッションがaによって伴われる個々のMACフレームの頻度を表します。
Flick & Johnson Standards Track [Page 27] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[27ページ]RFC2665
particular number of media collisions."
INDEX { ifIndex, dot3CollCount }
::= { dot3CollTable 1 }
「特定の数のメディア衝突。」 ifIndex、dot3CollCountに索引をつけてください:、:= dot3CollTable1
Dot3CollEntry ::=
SEQUENCE {
dot3CollCount INTEGER,
dot3CollFrequencies Counter32
}
Dot3CollEntry:、:= 系列dot3CollCount整数、dot3CollFrequencies Counter32
-- { dot3CollEntry 1 } is no longer in use
-- dot3CollEntry1はもう使用中ではありません。
dot3CollCount OBJECT-TYPE
SYNTAX INTEGER (1..16)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The number of per-frame media collisions for
which a particular collision histogram cell
represents the frequency on a particular
interface."
::= { dot3CollEntry 2 }
dot3CollCount OBJECT-TYPE SYNTAX INTEGER(1 .16)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の衝突ヒストグラムセルが特定のインタフェースに頻度を表す1フレームあたりのメディア衝突の数。」 ::= dot3CollEntry2
dot3CollFrequencies OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of individual MAC frames for which the
transmission (successful or otherwise) on a
particular interface occurs after the
frame has experienced exactly the number
of collisions in the associated
dot3CollCount object.
dot3CollFrequencies OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「特定のインタフェースの(うまくいくかそうではありません)のトランスミッションがフレームの後に起こる個々のMACフレームのカウントはちょうど関連dot3CollCountオブジェクトの衝突の数になりました」。
For example, a frame which is transmitted
on interface 77 after experiencing
exactly 4 collisions would be indicated
by incrementing only dot3CollFrequencies.77.4.
No other instance of dot3CollFrequencies would
be incremented in this example.
例えば、まさに4回の衝突を経験した後にインタフェース77で伝えられるフレームがdot3CollFrequenciesだけを増加することによって示されるだろう、.77、.4 dot3CollFrequenciesの他のインスタンスは全くこの例で増加されないでしょう。
This counter does not increment when the
interface is operating in full-duplex mode.
インタフェースが全二重モードで作動しているとき、このカウンタはどんな増分もしません。
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."
::= { dot3CollEntry 3 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 ::= dot3CollEntry3
Flick & Johnson Standards Track [Page 28] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[28ページ]RFC2665
dot3ControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3ControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A table of descriptive and status information
about the MAC Control sublayer on the
ethernet-like interfaces attached to a
particular system. There will be one row in
this table for each ethernet-like interface in
the system which implements the MAC Control
sublayer. If some, but not all, of the
ethernet-like interfaces in the system implement
the MAC Control sublayer, there will be fewer
rows in this table than in the dot3StatsTable."
::= { dot3 9 }
「イーサネットのようなインタフェースのMAC Control副層の描写的、そして、状態情報のテーブルは特定のシステムに取り付けた」dot3ControlTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3ControlEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 MAC Control副層を実装するシステムには1つの行がそれぞれのイーサネットのようなインタフェースへのこのテーブルにあるでしょう。 「すべてではなく、システムのイーサネットのようなインタフェースのいくつかがMAC Control副層を実装すると、より少ない行がdot3StatsTableよりこのテーブルにあるでしょう。」 ::= dot3 9
dot3ControlEntry OBJECT-TYPE
SYNTAX Dot3ControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the table, containing information
about the MAC Control sublayer on a single
ethernet-like interface."
INDEX { dot3StatsIndex }
::= { dot3ControlTable 1 }
dot3ControlEntry OBJECT-TYPE SYNTAX Dot3ControlEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「単一のイーサネットのようなインタフェースのMAC Control副層の情報を含むテーブルのエントリー。」 dot3StatsIndexに索引をつけてください:、:= dot3ControlTable1
Dot3ControlEntry ::=
SEQUENCE {
dot3ControlFunctionsSupported BITS,
dot3ControlInUnknownOpcodes Counter32
}
Dot3ControlEntry:、:= 系列dot3ControlFunctionsSupportedビット、dot3ControlInUnknownOpcodes Counter32
dot3ControlFunctionsSupported OBJECT-TYPE
SYNTAX BITS {
pause(0) -- 802.3x flow control
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A list of the possible MAC Control functions
implemented for this interface."
REFERENCE "[IEEE 802.3 Std.], 30.3.3.2,
aMACControlFunctionsSupported."
::= { dot3ControlEntry 1 }
「可能なMAC Control機能のリストはこのインタフェースに実装した」dot3ControlFunctionsSupported OBJECT-TYPE SYNTAX BITSの{(0)をポーズしてください--802.3xフロー制御}というマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 参照、「[IEEE802.3Std]、30.3、.3、.2、aMACControlFunctionsSupported、」 ::= dot3ControlEntry1
dot3ControlInUnknownOpcodes OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
dot3ControlInUnknownOpcodes OBJECT-TYPE SYNTAX Counter32マックス-ACCESS書き込み禁止STATUS海流
Flick & Johnson Standards Track [Page 29] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[29ページ]RFC2665
DESCRIPTION "A count of MAC Control frames received on this
interface that contain an opcode that is not
supported by this device.
「MAC Controlフレームのカウントはこのデバイスによってサポートされないopcodeを含むこのインタフェースで受けた」記述。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.3.5,
aUnsupportedOpcodesReceived"
::= { dot3ControlEntry 2 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.3、.5、aUnsupportedOpcodesReceived、」、:、:= dot3ControlEntry2
dot3PauseTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot3PauseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A table of descriptive and status information
about the MAC Control PAUSE function on the
ethernet-like interfaces attached to a
particular system. There will be one row in
this table for each ethernet-like interface in
the system which supports the MAC Control PAUSE
function (i.e., the 'pause' bit in the
corresponding instance of
dot3ControlFunctionsSupported is set). If some,
but not all, of the ethernet-like interfaces in
the system implement the MAC Control PAUSE
function (for example, if some interfaces only
support half-duplex), there will be fewer rows
in this table than in the dot3StatsTable."
::= { dot3 10 }
「イーサネットのようなインタフェースでのMAC Control PAUSE機能の描写的、そして、状態情報のテーブルは特定のシステムに取り付けた」dot3PauseTable OBJECT-TYPE SYNTAX SEQUENCE OF Dot3PauseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 MAC Control PAUSE機能をサポートするシステムには1つの行がそれぞれのイーサネットのようなインタフェースへのこのテーブルにあるでしょう(すなわち、dot3ControlFunctionsSupportedの対応するインスタンスにおける'くぎり'ビットは設定されます)。 「すべてではなく、システムのイーサネットのようなインタフェースのいくつかがMAC Control PAUSE機能を実装すると(いくつかのインタフェースが例えば半二重をサポートするだけであるなら)、より少ない行がdot3StatsTableよりこのテーブルにあるでしょう。」 ::= dot3 10
dot3PauseEntry OBJECT-TYPE
SYNTAX Dot3PauseEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An entry in the table, containing information
about the MAC Control PAUSE function on a single
ethernet-like interface."
INDEX { dot3StatsIndex }
::= { dot3PauseTable 1 }
dot3PauseEntry OBJECT-TYPE SYNTAX Dot3PauseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「単一のイーサネットのようなインタフェースでのMAC Control PAUSE機能の情報を含むテーブルのエントリー。」 dot3StatsIndexに索引をつけてください:、:= dot3PauseTable1
Dot3PauseEntry ::=
SEQUENCE {
dot3PauseAdminMode INTEGER,
dot3PauseOperMode INTEGER,
dot3InPauseFrames Counter32,
dot3OutPauseFrames Counter32
Dot3PauseEntry:、:= 系列、dot3PauseAdminMode整数、dot3PauseOperMode整数、dot3InPauseFrames Counter32、dot3OutPauseFrames Counter32
Flick & Johnson Standards Track [Page 30] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[30ページ]RFC2665
}
}
dot3PauseAdminMode OBJECT-TYPE
SYNTAX INTEGER {
disabled(1),
enabledXmit(2),
enabledRcv(3),
enabledXmitAndRcv(4)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION "This object is used to configure the default
administrative PAUSE mode for this interface.
(1)、enabledXmit(2)、enabledRcv(3)、enabledXmitAndRcv(4)であることが無効にされたマックス-ACCESSが「デフォルトの管理PAUSEモードをこのインタフェースに構成するために、使用これが反対するされる」とSTATUSの現在の記述に読書して書くdot3PauseAdminMode OBJECT-TYPE SYNTAX INTEGER。
This object represents the
administratively-configured PAUSE mode for this
interface. If auto-negotiation is not enabled
or is not implemented for the active MAU
attached to this interface, the value of this
object determines the operational PAUSE mode
of the interface whenever it is operating in
full-duplex mode. In this case, a set to this
object will force the interface into the
specified mode.
このオブジェクトは行政上構成されたPAUSEモードをこのインタフェースに表します。 自動交渉が可能にされないか、またはこのインタフェースに取り付けられたアクティブなMAUのために実装されないなら、全二重モードで作動しているときはいつも、このオブジェクトの値はインタフェースの操作上のPAUSEモードを決定します。 この場合、このオブジェクトへのセットは指定されたモードにインタフェースを力づくで押すでしょう。
If auto-negotiation is implemented and enabled
for the MAU attached to this interface, the
PAUSE mode for this interface is determined by
auto-negotiation, and the value of this object
denotes the mode to which the interface will
automatically revert if/when auto-negotiation is
later disabled. Note that when auto-negotiation
is running, administrative control of the PAUSE
mode may be accomplished using the
ifMauAutoNegCapAdvertisedBits object in the
MAU-MIB.
自動交渉がこのインタフェースに取り付けられたMAUのために実装されて、可能にされるなら、このインタフェースへのPAUSEモードは自動交渉で決定します、そして、このオブジェクトの値は自動交渉が後で無効にされるときインタフェースが/であるなら自動的に戻るモードを指示します。 自動交渉が稼働しているとき、PAUSEモードの運営管理コントロールがMAU-MIBでifMauAutoNegCapAdvertisedBitsオブジェクトを使用することで実行されるかもしれないことに注意してください。
Note that the value of this object is ignored
when the interface is not operating in
full-duplex mode.
インタフェースが全二重モードで作動していないとき、このオブジェクトの値が無視されることに注意してください。
An attempt to set this object to
'enabledXmit(2)' or 'enabledRcv(3)' will fail
on interfaces that do not support operation
at greater than 100 Mb/s."
::= { dot3PauseEntry 1 }
「'enabledXmit(2)'か'enabledRcv(3)'にこのオブジェクトを設定する試みは100Mb/s.で操作をサポートしないインタフェースで失敗するでしょう」 ::= dot3PauseEntry1
dot3PauseOperMode OBJECT-TYPE
dot3PauseOperModeオブジェクト・タイプ
Flick & Johnson Standards Track [Page 31] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[31ページ]RFC2665
SYNTAX INTEGER {
disabled(1),
enabledXmit(2),
enabledRcv(3),
enabledXmitAndRcv(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION "This object reflects the PAUSE mode currently
in use on this interface, as determined by
either (1) the result of the auto-negotiation
function or (2) if auto-negotiation is not
enabled or is not implemented for the active MAU
attached to this interface, by the value of
dot3PauseAdminMode. Interfaces operating at
100 Mb/s or less will never return
'enabledXmit(2)' or 'enabledRcv(3)'. Interfaces
operating in half-duplex mode will always return
'disabled(1)'. Interfaces on which
auto-negotiation is enabled but not yet
completed should return the value
'disabled(1)'."
::= { dot3PauseEntry 2 }
SYNTAX INTEGERは、(1)、enabledXmit(2)がenabledRcv(3)、enabledXmitAndRcv(4)であると無効にしました。マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「自動交渉が可能にされないか、またはこのインタフェースに取り付けられたアクティブなMAUのために実装されないなら(1) 自動交渉機能の結果か(2)のどちらかで決定するようにdot3PauseAdminModeの値で現在このインタフェースで使用中のPAUSEモードを反映これが反対するします」。 100Mb/s以下で作動するインタフェースは'enabledXmit(2)'か'enabledRcv(3)'を決して返さないでしょう。 モードがいつも返す半二重で作動するインタフェースは'(1)を無効にしました'。 「自動交渉が可能にされますが、まだ終了していないインタフェースは'(1)であると無効にされた'値を返すべきです。」 ::= dot3PauseEntry2
dot3InPauseFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of MAC Control frames received on this
interface with an opcode indicating the PAUSE
operation.
「opcodeがPAUSE操作を必要とすることで、MAC Controlフレームのカウントはこのインタフェースで受けた」dot3InPauseFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。
This counter does not increment when the
interface is operating in half-duplex mode.
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.4.3,
aPAUSEMACCtrlFramesReceived."
::= { dot3PauseEntry 3 }
インタフェースが半二重モードで作動しているとき、このカウンタはどんな増分もしません。 「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.4、.3、aPAUSEMACCtrlFramesReceived、」 ::= dot3PauseEntry3
dot3OutPauseFrames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A count of MAC Control frames transmitted on
this interface with an opcode indicating the
dot3OutPauseFrames OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「opcodeが示されている状態でMAC Controlフレームのカウントがこのインタフェースを伝わった、」
Flick & Johnson Standards Track [Page 32] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[32ページ]RFC2665
PAUSE operation.
PAUSE操作。
This counter does not increment when the
interface is operating in half-duplex mode.
インタフェースが半二重モードで作動しているとき、このカウンタはどんな増分もしません。
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."
REFERENCE "[IEEE 802.3 Std.], 30.3.4.2,
aPAUSEMACCtrlFramesTransmitted."
::= { dot3PauseEntry 4 }
「このカウンタの値における不連続はマネージメントシステムの再初期化においてifCounterDiscontinuityTimeの値によって示される他の時に起こることができます。」 参照、「[IEEE802.3Std]、30.3、.4、.2、aPAUSEMACCtrlFramesTransmitted、」 ::= dot3PauseEntry4
-- 802.3 Tests
-- 802.3 テスト
dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
dot3Testsオブジェクト識別子:、:= dot3 6
dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
dot3Errorsオブジェクト識別子:、:= dot3 7
-- TDR Test
-- TDRテスト
dot3TestTdr OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Time-Domain Reflectometry (TDR) test is
specific to ethernet-like interfaces of type
10Base5 and 10Base2. The TDR value may be
useful in determining the approximate distance
to a cable fault. It is advisable to repeat
this test to check for a consistent resulting
TDR value, to verify that there is a fault.
dot3TestTdr OBJECT-IDENTITY STATUSの現在の記述、「Time-ドメインReflectometry(TDR)テストはタイプ10Base5と10Base2のイーサネットのようなインタフェースに特定です」。 TDR値はケーブル欠点に大体の距離を測定する際に役に立つかもしれません。 一貫した結果として起こるTDR値がないかどうかチェックするためにこのテストを繰り返すのは、欠点があることを確かめるために賢明です。
A TDR test returns as its result the time
interval, measured in 10 MHz ticks or 100 nsec
units, between the start of TDR test
transmission and the subsequent detection of a
collision or deassertion of carrier. On
successful completion of a TDR test, the result
is stored as the value of an appropriate
instance of an appropriate vendor specific MIB
object, and the OBJECT IDENTIFIER of that
instance is stored in the appropriate instance
of the appropriate test result code object
(thereby indicating where the result has been
stored)."
::= { dot3Tests 1 }
TDRテストは結果として10MHzのカチカチする音か100nsec単位で測定された時間間隔を返します、TDRテスト送信の始まりとキャリヤーの衝突か反主張のその後の検出の間で。 「TDRテストの無事終了のときに結果は適切なベンダー特定のMIBオブジェクトの適切なインスタンスの値として保存されます、そして、そのインスタンスのOBJECT IDENTIFIERは適切なテスト結果コードオブジェクトの適切なインスタンスで保存されます(その結果、結果がどこに保存されたかを示します)。」 ::= dot3Tests1
-- Loopback Test
-- 折返しテスト
Flick & Johnson Standards Track [Page 33] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[33ページ]RFC2665
dot3TestLoopBack OBJECT-IDENTITY
STATUS current
DESCRIPTION "This test configures the MAC chip and executes
an internal loopback test of memory, data paths,
and the MAC chip logic. This loopback test can
only be executed if the interface is offline.
Once the test has completed, the MAC chip should
be reinitialized for network operation, but it
should remain offline.
dot3TestLoopBack OBJECT-IDENTITY STATUSの現在の記述、「このテストは、MACチップを構成して、メモリ、データ経路、およびMACチップ論理の内部の折返しテストを実行します」。 インタフェースがオフラインである場合にだけ、この折返しテストを実行できます。 テストがいったんそうすると、完成していて、MACチップはネットワーク操作のために再初期化されるべきですが、それはオフラインのままで残るべきです。
If an error occurs during a test, the
appropriate test result object will be set
to indicate a failure. The two OBJECT
IDENTIFIER values dot3ErrorInitError and
dot3ErrorLoopbackError may be used to provided
more information as values for an appropriate
test result code object."
::= { dot3Tests 2 }
誤りがテストの間、発生すると、適切なテスト結果オブジェクトが失敗を示すように設定されるでしょう。 「2OBJECT IDENTIFIERはdot3ErrorInitErrorを評価します、そして、適切なテスト結果コードのための値が反対するようにdot3ErrorLoopbackErrorは提供された詳しい情報に使用されるかもしれません。」 ::= dot3Tests2
dot3ErrorInitError OBJECT-IDENTITY
STATUS current
DESCRIPTION "Couldn't initialize MAC chip for test."
::= { dot3Errors 1 }
dot3ErrorInitError OBJECT-IDENTITY STATUSの現在の記述は「テストのためにMACチップを初期化できませんでした」。 ::= dot3Errors1
dot3ErrorLoopbackError OBJECT-IDENTITY
STATUS current
DESCRIPTION "Expected data not received (or not received
correctly) in loopback test."
::= { dot3Errors 2 }
「容認された(または、正しく受け取られない)ループバックではなく、予想されたデータがテストする」dot3ErrorLoopbackError OBJECT-IDENTITY STATUSの現在の記述。 ::= dot3Errors2
-- { dot3 8 }, the dot3ChipSets tree, is defined in [28]
-- dot3 8(dot3ChipSets木)は中で定義されます。[28]
-- conformance information
-- 順応情報
etherConformance OBJECT IDENTIFIER ::= { etherMIB 2 }
etherConformanceオブジェクト識別子:、:= etherMIB2
etherGroups OBJECT IDENTIFIER ::= { etherConformance 1 }
etherCompliances OBJECT IDENTIFIER ::= { etherConformance 2 }
etherGroupsオブジェクト識別子:、:= etherConformance1etherCompliancesオブジェクト識別子:、:= etherConformance2
-- compliance statements
-- 承諾声明
etherCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ********
「etherCompliance MODULE-COMPLIANCE STATUSの推奨しない記述」、********この承諾は推奨しない********です。
The compliance statement for managed network
entities which have ethernet-like network
interfaces.
イーサネットのようなネットワークを持っている管理されたネットワーク実体のための承諾声明は連結します。
Flick & Johnson Standards Track [Page 34] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[34ページ]RFC2665
This compliance is deprecated and replaced by
dot3Compliance."
「このコンプライアンスを推奨しなく、dot3Complianceに取り替えます。」
MODULE -- this module
MANDATORY-GROUPS { etherStatsGroup }
MODULE--このモジュールMANDATORY-GROUPSetherStatsGroup
GROUP etherCollisionTableGroup
DESCRIPTION "This group is optional. It is appropriate
for all systems which have the necessary
metering. Implementation in such systems is
highly recommended."
::= { etherCompliances 1 }
GROUP etherCollisionTableGroup記述、「このグループは任意です」。 必要な計量を持っているすべてのシステムに、それは適切です。 「そのようなシステムの実装は非常にお勧めです。」 ::= etherCompliances1
ether100MbsCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION "******** THIS COMPLIANCE IS DEPRECATED ********
「ether100MbsCompliance MODULE-COMPLIANCE STATUSの推奨しない記述」、********この承諾は推奨しない********です。
The compliance statement for managed network
entities which have 100 Mb/sec ethernet-like
network interfaces.
100Mb/秒のイーサネットのようなネットワークを持っている管理されたネットワーク実体のための承諾声明は連結します。
This compliance is deprecated and replaced by
dot3Compliance."
「このコンプライアンスを推奨しなく、dot3Complianceに取り替えます。」
MODULE -- this module
MANDATORY-GROUPS { etherStats100MbsGroup }
MODULE--このモジュールMANDATORY-GROUPSetherStats100MbsGroup
GROUP etherCollisionTableGroup
DESCRIPTION "This group is optional. It is appropriate
for all systems which have the necessary
metering. Implementation in such systems is
highly recommended."
::= { etherCompliances 2 }
GROUP etherCollisionTableGroup記述、「このグループは任意です」。 必要な計量を持っているすべてのシステムに、それは適切です。 「そのようなシステムの実装は非常にお勧めです。」 ::= etherCompliances2
dot3Compliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for managed network
entities which have ethernet-like network
interfaces."
dot3Compliance MODULE-COMPLIANCE STATUSの現在の記述、「イーサネットのようなネットワークを持っている管理されたネットワーク実体のための承諾声明は連結します」。
MODULE -- this module
MANDATORY-GROUPS { etherStatsBaseGroup }
MODULE--このモジュールMANDATORY-GROUPSetherStatsBaseGroup
GROUP etherDuplexGroup
DESCRIPTION "This group is mandatory for all
ethernet-like network interfaces which are
capable of operating in full-duplex mode.
It is highly recommended for all
GROUP etherDuplexGroup記述は「全二重モードで作動できるインタフェースをネットワークでつなこのグループがイーサネットのすべてにような状態で義務的であるです」。 それはすべてのために強く推薦されます。
Flick & Johnson Standards Track [Page 35] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[35ページ]RFC2665
ethernet-like network interfaces."
「イーサネットのようなネットワークは連結します。」
GROUP etherStatsLowSpeedGroup
DESCRIPTION "This group is mandatory for all
ethernet-like network interfaces which are
capable of operating at 10 Mb/s or slower in
half-duplex mode."
「このグループはすべての10時に作動できるイーサネットのようなネットワーク・インターフェースMb/sか半二重モードで、より遅く義務的である」GROUP etherStatsLowSpeedGroup記述。
GROUP etherStatsHighSpeedGroup
DESCRIPTION "This group is mandatory for all
ethernet-like network interfaces which are
capable of operating at 100 Mb/s or faster."
GROUP etherStatsHighSpeedGroup記述は「100Mb/sで作動できるか、または、より速いインタフェースをネットワークでつなこのグループがイーサネットのすべてにような状態で義務的であるです」。
GROUP etherControlGroup
DESCRIPTION "This group is mandatory for all
ethernet-like network interfaces that
support the MAC Control sublayer."
GROUP etherControlGroup記述は「MAC Control副層をサポートするインタフェースをネットワークでつなこのグループがイーサネットのすべてにような状態で義務的であるです」。
GROUP etherControlPauseGroup
DESCRIPTION "This group is mandatory for all
ethernet-like network interfaces that
support the MAC Control PAUSE function."
GROUP etherControlPauseGroup記述は「MAC Control PAUSE機能をサポートするインタフェースをネットワークでつなこのグループがイーサネットのすべてにような状態で義務的であるです」。
GROUP etherCollisionTableGroup
DESCRIPTION "This group is optional. It is appropriate
for all ethernet-like network interfaces
which are capable of operating in
half-duplex mode and have the necessary
metering. Implementation in systems with
such interfaces is highly recommended."
GROUP etherCollisionTableGroup記述、「このグループは任意です」。 半二重モードで作動できて、必要な計量を持っているすべてのイーサネットのようなネットワーク・インターフェースに、それは適切です。 「そのようなインタフェースがあるシステムの実装は非常にお勧めです。」
::= { etherCompliances 3 }
::= etherCompliances3
-- units of conformance
-- ユニットの順応
etherStatsGroup OBJECT-GROUP
OBJECTS { dot3StatsIndex,
dot3StatsAlignmentErrors,
dot3StatsFCSErrors,
dot3StatsSingleCollisionFrames,
dot3StatsMultipleCollisionFrames,
dot3StatsSQETestErrors,
dot3StatsDeferredTransmissions,
dot3StatsLateCollisions,
dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors,
dot3StatsCarrierSenseErrors,
dot3StatsFrameTooLongs,
etherStatsGroupオブジェクト群対象、dot3StatsIndex、dot3StatsAlignmentErrors、dot3StatsFCSErrors、dot3StatsSingleCollisionFrames、dot3StatsMultipleCollisionFrames、dot3StatsSQETestErrors、dot3StatsDeferredTransmissions、dot3StatsLateCollisions、dot3StatsExcessiveCollisions、dot3StatsInternalMacTransmitErrors、dot3StatsCarrierSenseErrors、dot3StatsFrameTooLongs
Flick & Johnson Standards Track [Page 36] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[36ページ]RFC2665
dot3StatsInternalMacReceiveErrors,
dot3StatsEtherChipSet
}
STATUS deprecated
DESCRIPTION "********* THIS GROUP IS DEPRECATED **********
dot3StatsInternalMacReceiveErrors、dot3StatsEtherChipSet これが分類する「STATUSの推奨しない記述」*********は推奨しない**********です。
A collection of objects providing information
applicable to all ethernet-like network
interfaces.
すべてのイーサネットのようなネットワークに適切な情報を提供するオブジェクトの収集は連結します。
This object group has been deprecated and
replaced by etherStatsBaseGroup and
etherStatsLowSpeedGroup."
::= { etherGroups 1 }
「このオブジェクトグループを推奨しなく、etherStatsBaseGroupとetherStatsLowSpeedGroupに取り替えました。」 ::= etherGroups1
etherCollisionTableGroup OBJECT-GROUP
OBJECTS { dot3CollFrequencies
}
STATUS current
DESCRIPTION "A collection of objects providing a histogram
of packets successfully transmitted after
experiencing exactly N collisions."
::= { etherGroups 2 }
etherCollisionTableGroup OBJECT-GROUP OBJECTS dot3CollFrequencies、「まさにN衝突を経験した後に、オブジェクトが首尾よくパケットのヒストグラムを提供する収集は伝えた」STATUSの現在の記述。 ::= etherGroups2
etherStats100MbsGroup OBJECT-GROUP
OBJECTS { dot3StatsIndex,
dot3StatsAlignmentErrors,
dot3StatsFCSErrors,
dot3StatsSingleCollisionFrames,
dot3StatsMultipleCollisionFrames,
dot3StatsDeferredTransmissions,
dot3StatsLateCollisions,
dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors,
dot3StatsCarrierSenseErrors,
dot3StatsFrameTooLongs,
dot3StatsInternalMacReceiveErrors,
dot3StatsEtherChipSet,
dot3StatsSymbolErrors
}
STATUS deprecated
DESCRIPTION "********* THIS GROUP IS DEPRECATED **********
「etherStats100MbsGroup OBJECT-GROUP OBJECTS、dot3StatsIndex、dot3StatsAlignmentErrors、dot3StatsFCSErrors、dot3StatsSingleCollisionFrames、dot3StatsMultipleCollisionFrames、dot3StatsDeferredTransmissions、dot3StatsLateCollisions、dot3StatsExcessiveCollisions、dot3StatsInternalMacTransmitErrors、dot3StatsCarrierSenseErrors、dot3StatsFrameTooLongs、dot3StatsInternalMacReceiveErrors、dot3StatsEtherChipSet、dot3StatsSymbolErrors、STATUSの推奨しない記述、」 これが分類する*********は推奨しない**********です。
A collection of objects providing information
applicable to 100 Mb/sec ethernet-like network
interfaces.
100Mb/秒のイーサネットのようなネットワークに適切な情報を提供するオブジェクトの収集は連結します。
This object group has been deprecated and
そしてこのオブジェクトグループが推奨しない。
Flick & Johnson Standards Track [Page 37] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[37ページ]RFC2665
replaced by etherStatsBaseGroup and
etherStatsHighSpeedGroup."
::= { etherGroups 3 }
「etherStatsBaseGroupとetherStatsHighSpeedGroupに取り替えられます」。 ::= etherGroups3
etherStatsBaseGroup OBJECT-GROUP
OBJECTS { dot3StatsIndex,
dot3StatsAlignmentErrors,
dot3StatsFCSErrors,
dot3StatsSingleCollisionFrames,
dot3StatsMultipleCollisionFrames,
dot3StatsDeferredTransmissions,
dot3StatsLateCollisions,
dot3StatsExcessiveCollisions,
dot3StatsInternalMacTransmitErrors,
dot3StatsCarrierSenseErrors,
dot3StatsFrameTooLongs,
dot3StatsInternalMacReceiveErrors
}
STATUS current
DESCRIPTION "A collection of objects providing information
applicable to all ethernet-like network
interfaces."
::= { etherGroups 4 }
etherStatsBaseGroup OBJECT-GROUP OBJECTS、dot3StatsIndex、dot3StatsAlignmentErrors、dot3StatsFCSErrors、dot3StatsSingleCollisionFrames、dot3StatsMultipleCollisionFrames、dot3StatsDeferredTransmissions、dot3StatsLateCollisions、dot3StatsExcessiveCollisions、dot3StatsInternalMacTransmitErrors、dot3StatsCarrierSenseErrors、dot3StatsFrameTooLongs、dot3StatsInternalMacReceiveErrors、「オブジェクトがすべてのイーサネットのようなネットワークに適切な情報を提供する収集は連結する」STATUSの現在の記述。 ::= etherGroups4
etherStatsLowSpeedGroup OBJECT-GROUP
OBJECTS { dot3StatsSQETestErrors }
STATUS current
DESCRIPTION "A collection of objects providing information
applicable to ethernet-like network interfaces
capable of operating at 10 Mb/s or slower in
half-duplex mode."
etherStatsLowSpeedGroup OBJECT-GROUP OBJECTS dot3StatsSQETestErrors、「オブジェクトがイーサネットのように適切な情報を提供する収集は半分のデュプレックスモードで10Mb/sか、より遅く作動できるインタフェースをネットワークでつなぐ」STATUSの現在の記述。
::= { etherGroups 5 }
::= etherGroups5
etherStatsHighSpeedGroup OBJECT-GROUP
OBJECTS { dot3StatsSymbolErrors }
STATUS current
DESCRIPTION "A collection of objects providing information
applicable to ethernet-like network interfaces
capable of operating at 100 Mb/s or faster."
::= { etherGroups 6 }
etherStatsHighSpeedGroup OBJECT-GROUP OBJECTS dot3StatsSymbolErrors、「オブジェクトがイーサネットのように適切な情報を提供する収集は100Mb/sか、より速く作動できるインタフェースをネットワークでつなぐ」STATUSの現在の記述。 ::= etherGroups6
etherDuplexGroup OBJECT-GROUP
OBJECTS { dot3StatsDuplexStatus }
STATUS current
DESCRIPTION "A collection of objects providing information
about the duplex mode of an ethernet-like
network interface."
etherDuplexGroup OBJECT-GROUP OBJECTS dot3StatsDuplexStatus、STATUSの現在の記述、「イーサネットのようなネットワーク・インターフェースの重複のモードの情報を提供するオブジェクトの収集。」
Flick & Johnson Standards Track [Page 38] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[38ページ]RFC2665
::= { etherGroups 7 }
::= etherGroups7
etherControlGroup OBJECT-GROUP
OBJECTS { dot3ControlFunctionsSupported,
dot3ControlInUnknownOpcodes
}
STATUS current
DESCRIPTION "A collection of objects providing information
about the MAC Control sublayer on ethernet-like
network interfaces."
::= { etherGroups 8 }
etherControlGroup OBJECT-GROUP OBJECTS、dot3ControlFunctionsSupported、dot3ControlInUnknownOpcodes、「オブジェクトがイーサネットのようなネットワークのMAC Control副層の情報を提供する収集は連結する」STATUSの現在の記述。 ::= etherGroups8
etherControlPauseGroup OBJECT-GROUP
OBJECTS { dot3PauseAdminMode,
dot3PauseOperMode,
dot3InPauseFrames,
dot3OutPauseFrames
}
STATUS current
DESCRIPTION "A collection of objects providing information
about and control of the MAC Control PAUSE
function on ethernet-like network interfaces."
::= { etherGroups 9 }
etherControlPauseGroup OBJECT-GROUP OBJECTS、dot3PauseAdminMode、dot3PauseOperMode、dot3InPauseFrames、dot3OutPauseFrames、「周囲で情報を提供するオブジェクトの収集とイーサネットのようなネットワークにおけるMAC Control PAUSE機能のコントロールは連結する」STATUSの現在の記述。 ::= etherGroups9
END
終わり
5. Intellectual Property
5. 知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Flick & Johnson Standards Track [Page 39] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[39ページ]RFC2665
6. Acknowledgements
6. 承認
This document was produced by the IETF Ethernet Interfaces and Hub MIB Working Group, whose efforts were greatly advanced by the contributions of the following people:
このドキュメントはIETFイーサネットInterfacesとHub MIB作業部会によって製作されました:(作業部会の取り組みは以下の人々の貢献で大いに進められました)。
Lynn Kubinec
Steve McRobert
Dan Romascanu
Andrew Smith
Geoff Thompson
リンKubinecスティーブMcRobertダンRomascanuアンドリュー・スミスジェフトンプソン
This document is based on the Proposed Standard Ethernet MIB, RFC 2358 [23], edited by John Flick of Hewlett-Packard and Jeffrey Johnson of RedBack Networks and produced by the 802.3 Hub MIB Working Group. It extends that document by providing support for full-duplex Ethernet interfaces and 1000 Mb/sec Ethernet interfaces as outlined in [16].
このドキュメントは、802.3Hub MIB作業部会によってイーサネットMIB(RFC2358[23])がヒューレット・パッカードのジョンFlickとRedBack Networksのジェフリー・ジョンソンで編集したProposed Standardに基づいていて、製作されます。 それは、[16]に概説されているように全二重イーサネットインタフェースと1000Mb/秒のイーサネットインタフェースのサポートを提供することによって、そのドキュメントを広げています。
RFC 2358, in turn, is almost completely based on both the Standard Ethernet MIB, RFC 1643 [21], and the Proposed Standard Ethernet MIB using the SNMPv2 SMI, RFC 1650 [22], both of which were edited by Frank Kastenholz of FTP Software and produced by the Interfaces MIB Working Group. RFC 2358 extends those documents by providing support for 100 Mb/sec ethernet interfaces.
RFC2358は順番に両方のStandardイーサネットMIB、RFC1643[21]、およびSNMPv2 SMIを使用するProposed StandardイーサネットMIB、RFC1650[22]にほぼ完全に基づいています。FTP SoftwareのフランクKastenholzによって編集されます。Interfaces MIB作業部会はその両方をそれを生産しました。 RFC2358は、100Mb/秒のイーサネットインタフェースのサポートを提供することによって、それらのドキュメントを広げています。
RFC 1643 and RFC 1650, in turn, are based on the Draft Standard Ethernet MIB, RFC 1398 [20], also edited by Frank Kastenholz and produced by the Ethernet MIB Working Group.
RFC1643とRFC1650はイーサネットMIB作業部会によって順番にまたイーサネットMIB(RFC1398[20])がフランクKastenholzで編集したDraft Standardに基づいていて、生産されます。
RFC 1398, in turn, is based on the Proposed Standard Ethernet MIB, RFC 1284 [18], which was edited by John Cook of Chipcom and produced by the Transmission MIB Working Group. The Ethernet MIB Working Group gathered implementation experience of the variables specified in RFC 1284, documented that experience in RFC 1369 [19], and used that information to develop this revised MIB.
RFC1398は順番にProposed StandardイーサネットMIB、Chipcomのション・クックによって編集されて、Transmission MIB作業部会によって生産されたRFC1284[18]に基づいています。 イーサネットMIB作業部会は、変数の実装経験がRFC1284で指定して、RFC1369[19]にその経験を記録して、この改訂されたMIBを開発するのにその情報を使用したと推測しました。
RFC 1284, in turn, is based on a document written by Frank Kastenholz, then of Interlan, entitled IEEE 802.3 Layer Management Draft M compatible MIB for TCP/IP Networks [17]. This document was modestly reworked, initially by the SNMP Working Group, and then by the Transmission Working Group, to reflect the current conventions for defining objects for MIB interfaces. James Davin, of the MIT Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN Systems, contributed to later drafts of this memo. Marshall Rose of Performance Systems International, Inc. converted the document into
RFC1284は順番にそして、Interlan(TCP/IP Networks[17]のための題しているIEEE802.3のLayer Management DraftのMコンパチブルMIB)についてフランクKastenholzによって書かれたドキュメントに基づいています。 このドキュメントは、初めは、MIBインタフェースとオブジェクトを定義するために現在のコンベンションを反映するためにSNMP作業部会、およびそして、Transmission作業部会によって遠慮深く作りなおされました。 MITコンピュータサイエンス研究所のジェームス・デーヴィン、およびヒューズLAN SystemsのキースMcCloghrieはこのメモの後の草稿に貢献しました。 国際Inc.がドキュメントを変換したパフォーマンスSystemsのマーシャル・ローズ
Flick & Johnson Standards Track [Page 40] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[40ページ]RFC2665
RFC 1212 [3] concise format. Anil Rijsinghani of DEC contributed text that more adequately describes the TDR test. Thanks to Frank Kastenholz of Interlan and Louis Steinberg of IBM for their experimentation.
RFC1212の[3]の簡潔な形式。 12月のコマツナギRijsinghaniは、より適切にTDRテストについて説明するテキストを寄付しました。 彼らの実験をInterlanのフランクKastenholzとIBMのルイス・スタインバーグをありがとうございます。
7. References
7. 参照
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, May 1999.
[1] ハリントン、D.、Presuhn、R.、およびB.Wijnen(「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571)は1999がそうするかもしれません。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[2] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[4] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[6]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S Waldbusser, "Conformance Statements for SMIv2", STD 58,
RFC 2580, April 1999.
[7]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, May 1999.
[11]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年5月。
Flick & Johnson Standards Track [Page 41] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[41ページ]RFC2665
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, May 1999.
[12] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年5月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1905, January 1996.
[13] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, May 1999.
[14] レビ、D.、マイヤー、P.、およびB.スチュワート(「SNMPv3アプリケーション」、RFC2573)は1999がそうするかもしれません。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, May 1999.
[15] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年5月。
[16] IEEE, IEEE Std 802.3, 1998 Edition: "Information technology -
Telecommunications and information exchange between systems -
Local and metropolitan area networks - Specific requirements -
Part 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer specifications"
(incorporating ANSI/IEEE Std. 802.3, 1996 Edition, IEEE Std.
802.3r-1996, 802.3u-1995, 802.3x&y-1997, 802.3z-1998, and
802.3aa-1998), September 1998.
[16]IEEE、IEEE Std802.3、1998版: 「情報技術--システムの間のテレコミュニケーションと情報交換--地方とメトロポリタンエリアネットワーク(決められた一定の要求)は3を分けます」 「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」(ANSI/IEEE Stdを組み込みます。 802.3 1996年の版、IEEE Std。 802.3r-1996、802.3u-1995、802.3x、y-1997、802.3z-1998、および802.3aa-1998), 1998年9月。
[17] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible
MIB for TCP/IP Networks", electronic mail message to mib-
wg@nnsc.nsf.net, 9 June 1989.
[17]Kastenholz、F.、「TCP/IP NetworksのためのIEEE802.3のLayer Management DraftのコンパチブルMIB」、mib wg@nnsc.nsf.net (1989年6月9日)への電子メールメッセージ。
[18] Cook, J., "Definitions of Managed Objects for Ethernet-Like
Interface Types", RFC 1284, December 1991.
[18] クック、J.、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」、RFC1284、1991年12月。
[19] Kastenholz, F., "Implementation Notes and Experience for The
Internet Ethernet MIB", RFC 1369, October 1992.
[19]Kastenholzと、F.と、「インターネットイーサネットMIBのための実装注意と経験」、RFC1369、10月1992日
[20] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", RFC 1398, January 1993.
[20]Kastenholz、F.、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」、RFC1398、1993年1月。
[21] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types", STD 50, RFC 1643, July 1994.
[21]Kastenholz、F.、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」、STD50、RFC1643、1994年7月。
[22] Kastenholz, F., "Definitions of Managed Objects for the
Ethernet-like Interface Types using SMIv2", RFC 1650, August
1994.
[22]Kastenholz、F.、「1994年8月にSMIv2"、RFC1650を使用するイーサネットのようなインターフェース型のための管理オブジェクトの定義。」
[23] Flick, J. and J. Johnson, "Definitions of Managed Objects for
the Ethernet-like Interface Types", RFC 2358, June 1998.
[23] 軽打とJ.とJ.ジョンソン、「イーサネットのようなインターフェース型のための管理オブジェクトの定義」、RFC2358、1998年6月。
Flick & Johnson Standards Track [Page 42] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[42ページ]RFC2665
[24] McCloghrie, K. and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, March 1991.
[24]McCloghrie、K.とM.ローズ、エディターズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[25] McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[25] McCloghrie、K.、およびF.Kastenholz、「1997年11月にSMIv2"、RFC2233を使用するインタフェースグループMIB。」
[26] Bradner, S., "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[26] ブラドナー、S.、「Indicate Requirements LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[27] Smith, A., Flick, J., deGraaf, K., Romascanu, D., McMaster, D.,
McCloghrie, K. and S. Roberts, "Definitions of Managed Objects
for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668, August
1999.
[27] スミスとA.と軽打とJ.とdeGraafとK.とRomascanuとD.とマクマスターとD.、McCloghrieとK.とS.ロバーツ、「IEEE802.3媒体付属ユニット(MAUs)管理オブジェクトの定義」RFC2668(1999年8月)。
[28] Flick, J., "Definitions of Object Identifiers for Identifying
Ethernet Chip Sets", RFC 2666, August 1999.
[28] 軽打、J.、「イーサネットチップ・セットを特定するためのオブジェクト識別子の定義」、RFC2666、1999年8月。
8. Security Considerations
8. セキュリティ問題
There are two management objects defined in this MIB that have a MAX-ACCESS clause of read-write. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された2個の管理オブジェクトがあります。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
There are a number of managed objects in this MIB that may be considered to contain sensitive information. In particular, the dot3StatsEtherChipSet object may be considered sensitive in many environments, since it would allow an intruder to obtain information about which vendor's equipment is in use on the network. Note that this object has been deprecated. However, some implementors may still choose to implement it for backwards compatability.
多くの管理オブジェクトが機密情報を含むと考えられるかもしれないこのMIBにあります。 特に、dot3StatsEtherChipSetオブジェクトは多くの環境で敏感であると考えられるかもしれません、侵入者はそれでどのベンダーの設備がネットワークで使用中であるかの情報を得ることができるでしょう、したがって。 このオブジェクトが推奨しないことに注意してください。 しかしながら、何人かの作成者が、遅れているcompatabilityのためにそれを実装するのをまだ選んでいるかもしれません。
Therefore, it may be important in some environments to control read access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment.
したがって、SNMPを通してネットワークの上にそれらを送るとき、これらのオブジェクトの値を暗号化するのさえこれらのオブジェクトへのアクセスが読まれたコントロールへのいくつかの環境とことによると重要であるかもしれません。 SNMPのすべてのバージョンがそのような安全な環境のための特徴を提供するというわけではありません。
SNMPv1 by itself is such an insecure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET (read) the objects in this MIB.
それ自体でSNMPv1はそのように不安定な環境です。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET(読む)へのオブジェクトがこのMIBに安全なネットワークにだれに許容されているかに関してコントロールが全くありません。
It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View-based Access Control Model RFC 2575 [15] is recommended.
作成者がSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model RFC2574[12]とViewベースのAccess Control Model RFC2575[15]の使用はお勧めです。
Flick & Johnson Standards Track [Page 43] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[43ページ]RFC2665
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to those objects only to those principals (users) that have legitimate rights to access them.
そして、それらにアクセスする正当な権利を持っているそれらの校長だけ(ユーザ)にそれらのオブジェクトへのアクセスを与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
9. Authors' Addresses
9. 作者のアドレス
John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557
ジョン軽打ヒューレット・パッカード会社8000山麓の丘Blvd. S5557ローズビル、M/カリフォルニア95747-5557
Phone: +1 916 785 4018 EMail: johnf@rose.hp.com
以下に電話をしてください。 +1 4018年の916 785メール: johnf@rose.hp.com
Jeffrey Johnson RedBack Networks 2570 North First Street, Suite 410 San Jose, CA, 95131, USA
ジェフリーペニス20ドル紙幣はNorth First通り、Suite410サンノゼ、2570カリフォルニア 95131、米国をネットワークでつなぎます。
Phone: +1 408 571 2699 EMail: jeff@redbacknetworks.com
以下に電話をしてください。 +1 2699年の408 571メール: jeff@redbacknetworks.com
Flick & Johnson Standards Track [Page 44] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[44ページ]RFC2665
A. Change Log
A。 チェンジログ
A.1. Changes since RFC 2358
A.1。 RFC2358以来の変化
This section enumerates changes made to RFC 2358 to produce this document.
このセクションはこのドキュメントを製作するのがRFC2358にされた変更を列挙します。
(1) Section 2 has been replaced with the current SNMP
Management Framework boilerplate.
(1) セクション2を現在のSNMP Management Frameworkの決まり文句に取り替えました。
(2) The ifMtu mapping has been clarified.
(2) ifMtuマッピングははっきりさせられました。
(3) The relationship between the IEEE 802.3 octet counters
and the IF-MIB octet counters has been clarified.
そして、(3) IEEE802.3八重奏の間の関係が反対する、-、MIB、八重奏カウンタははっきりさせられました。
(4) REFERENCE clauses have been updated to reflect the
actual IEEE 802.3 managed object that each MIB object
is based on.
(4) それぞれのMIBオブジェクトが基づいている実際のIEEE802.3管理オブジェクトを反映するためにREFERENCE節をアップデートしました。
(5) The following object DESCRIPTION clauses have been
updated to reflect that they do not increment in
(5) 反射するのをそれらがどんな増分もしない以下のオブジェクト記述節をアップデートしました。
full-duplex mode: dot3StatsSingleCollisionFrames,
dot3StatsMultipleCollisionFrames, dot3StatsSQETestErrors,
dot3StatsDeferredTransmissions, dot3StatsLateCollisions,
dot3StatsExcessiveCollisions, dot3StatsCarrierSenseErrors,
dot3CollFrequencies.
全二重モード: dot3StatsSingleCollisionFrames、dot3StatsMultipleCollisionFrames、dot3StatsSQETestErrors、dot3StatsDeferredTransmissions、dot3StatsLateCollisions、dot3StatsExcessiveCollisions、dot3StatsCarrierSenseErrors、dot3CollFrequencies。
(6) The following object DESCRIPTION clauses have been
updated to reflect behaviour on full-duplex and
1000 Mb/s interfaces: dot3StatsAlignmentErrors,
dot3StatsFCSErrors, dot3StatsSQETestErrors,
dot3StatsLateCollisions, dot3StatsSymbolErrors.
(6) 全二重と1000Mb/sのインタフェースにふるまいを反映するために以下のオブジェクト記述節をアップデートしました: dot3StatsAlignmentErrors、dot3StatsFCSErrors、dot3StatsSQETestErrors、dot3StatsLateCollisions、dot3StatsSymbolErrors。
(7) Two new tables, dot3ControlTable and dot3PauseTable,
have been added.
(7) 2個の新しいテーブル(dot3ControlTableとdot3PauseTable)が、加えられます。
(8) A new object, dot3StatsDuplexStatus, has been added.
(8) 新しいオブジェクト(dot3StatsDuplexStatus)は加えられます。
(9) The object groups and compliances have been restructured.
(9) オブジェクトグループとコンプライアンスを再構築してあります。
(10) The dot3StatsEtherChipSet object has been deprecated.
(10) dot3StatsEtherChipSetオブジェクトは推奨しないです。
(11) The dot3ChipSets have been moved to a separate document.
(11) dot3ChipSetsは別々のドキュメントに動かされました。
Flick & Johnson Standards Track [Page 45] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[45ページ]RFC2665
A.2. Changes between RFC 1650 and RFC 2358
A.2。 RFC1650とRFC2358の間の変化
This section enumerates changes made to RFC 1650 to produce RFC 2358.
このセクションはRFC2358を生産するのがRFC1650にされた変更を列挙します。
(1) The MODULE-IDENTITY has been updated to reflect the changes
in the MIB.
(1) MIBにおける変化を反映するためにMODULE-IDENTITYをアップデートしました。
(2) A new object, dot3StatsSymbolErrors, has been added.
(2) 新しいオブジェクト(dot3StatsSymbolErrors)は加えられます。
(3) The definition of the object dot3StatsIndex has been
converted to use the SMIv2 OBJECT-TYPE macro.
(3) オブジェクトdot3StatsIndexの定義は、SMIv2 OBJECT-TYPEマクロを使用するために変換されました。
(4) A new conformance group, etherStats100MbsGroup, has been
added.
(4) 新しい順応グループ(etherStats100MbsGroup)は加えられます。
(5) A new compliance statement, ether100MbsCompliance, has
been added.
(5) 新しい承諾声明(ether100MbsCompliance)は加えられます。
(6) The Acknowledgements were extended to provide a more
complete history of the origin of this document.
(6) Acknowledgementsは、このドキュメントの発生源の、より完全な歴史を供給するために広げられました。
(7) The discussion of ifType has been expanded.
(7) ifTypeの議論を広げてあります。
(8) A section on mapping of Interfaces MIB objects has
been added.
(8) Interfaces MIBオブジェクトに関するマッピングのセクションは加えられます。
(9) A section defining the relationship of this MIB to
the MAU MIB has been added.
(9) このMIBの関係をMAU MIBと定義するセクションは加えられます。
(10) A section on the mapping of IEEE 802.3 managed objects
to this MIB and the Interfaces MIB has been added.
(10) IEEE802.3のこのMIBへの管理オブジェクトとInterfaces MIBに関するマッピングのセクションは加えられます。
(11) Converted the dot3Tests, dot3Errors, and dot3ChipSets
OIDs to use the OBJECT-IDENTITY macro.
(11)は、OBJECT-IDENTITYマクロを使用するためにdot3Tests、dot3Errors、およびdot3ChipSets OIDsを変換しました。
(12) Added to the list of registered dot3ChipSets.
登録されたdot3ChipSetsのリストに追加された(12)。
(13) An intellectual property notice and copyright notice
were added, as required by RFC 2026.
(13) 知的所有権通知と版権情報は必要に応じてRFC2026によって加えられました。
Flick & Johnson Standards Track [Page 46] RFC 2665 Ethernet-Like MIB August 1999
MIB1999年8月にイーサネットのような軽打とペニス標準化過程[46ページ]RFC2665
B. Full Copyright Statement
B。 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Flick & Johnson Standards Track [Page 47]
軽打とペニス標準化過程[47ページ]
一覧
スポンサーリンク
