Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
Network Working Group K. McCloghrie Request for Comments: 1213 Hughes LAN Systems, Inc. Obsoletes: RFC 1158 M. Rose 旧文書 : RFC1158 Performance Systems International Editors March 1991 Management Information Base for Network Management of TCP/IP-based internets: TCP/IPベースのインターネットのネットワーク管理用 管理情報ベース MIB-II Status of this Memo この文書の位置付け This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はTCP/IPベースのインターネットのネットワーク管理プロトコルで 使用する為の管理情報ベース(MIB-II)の第2バージョンを定義する。このRFC は、インターネット共同体のためにIAB 標準化文書を指定し、そして改良の 為の議論と提案を求めている。このプロトコルの標準化状態と状況は "IAB 公式プロトコル標準" の現行版を参照願いたい。この文書の配布は無制限で ある。 Table of Contents 目次 1. Abstract............................................... 2 要約 2. Introduction .......................................... 2 はじめに 3. Changes from RFC 1156 ................................. 3 RFC1156 からの変更 3.1 Deprecated Objects ................................... 3 推奨しないオブジェクト 3.2 Display Strings ...................................... 4 表示文字列 3.3 Physical Addresses ................................... 4 物理アドレス 3.4 The System Group ..................................... 5 システムグループ 3.5 The Interfaces Group ................................. 5 インタフェースグループ 3.6 The Address Translation Group ........................ 6 アドレストランスレーショングループ 3.7 The IP Group ......................................... 6 IPグループ 3.8 The ICMP Group ....................................... 7 ICMPグループ 3.9 The TCP Group ........................................ 7 TCPグループ 3.10 The UDP Group ....................................... 7 UDPグループ 3.11 The EGP Group ....................................... 7 EGPグループ 3.12 The Transmission Group .............................. 8 トランスミッショングループ 3.13 The SNMP Group ...................................... 8 SNMPグループ 3.14 Changes from RFC 1158 ................. ............. 9 RFC1158 からの変更 4. Objects ............................................... 10 オブジェクト 4.1 Format of Definitions ................................ 10 定義フォーマット 5. Overview .............................................. 10 概要 6. Definitions ........................................... 12 定義 6.1 Textual Conventions .................................. 12 テキスト規約 6.2 Groups in MIB-II ..................................... 13 MIB-II のグループ 6.3 The System Group ..................................... 13 システムグループ SNMP Working Group [Page 1] RFC 1213 MIB-II March 1991 6.4 The Interfaces Group ................................. 16 インタフェースグループ 6.5 The Address Translation Group ........................ 23 アドレストランスレーショングループ 6.6 The IP Group ......................................... 26 IPグループ 6.7 The ICMP Group ....................................... 41 ICMPグループ 6.8 The TCP Group ........................................ 46 TCPグループ 6.9 The UDP Group ........................................ 52 UDPグループ 6.10 The EGP Group ....................................... 54 EGPグループ 6.11 The Transmission Group .............................. 60 トランスミッショングループ 6.12 The SNMP Group ...................................... 60 SNMPグループ 7. Acknowledgements ...................................... 67 謝辞 8. References ............................................ 69 参考文献 9. Security Considerations ............................... 70 セキュリティ考察 10. Authors' Addresses ................................... 70 著者の住所 1. Abstract 要約 This memo defines the second version of the Management Information Base (MIB-II) for use with network management protocols in TCP/IP- based internets. In particular, together with its companion memos which describe the structure of management information (RFC 1155) along with the network management protocol (RFC 1157) for TCP/IP- based internets, these documents provide a simple, workable architecture and system for managing TCP/IP-based internets and in particular the Internet community. この文書はTCP/IPベースのインターネットのネットワーク管理プロトコルで 使用する為の管理情報ベース(MIB-II)の第2バージョンを定義する。 TCP/IP ベースのインターネットの為に、SNMP(RFC 1157) と SMI(RFC 1155) の構造 について説明する関連文書と併せ、特にこれら文書はTCP/IPベースのインタ ーネットと特にインターネットコミュニティを管理する簡潔で実現可能なア ーキテクチャとシステムを提供する。 2. Introduction はじめに As reported in RFC 1052, IAB Recommendations for the Development of Internet Network Management Standards [1], a two-prong strategy for network management of TCP/IP-based internets was undertaken. In the short-term, the Simple Network Management Protocol (SNMP) was to be used to manage nodes in the Internet community. In the long-term, the use of the OSI network management framework was to be examined. Two documents were produced to define the management information: RFC 1065, which defined the Structure of Management Information (SMI) [2], and RFC 1066, which defined the Management Information Base (MIB) [3]. Both of these documents were designed so as to be compatible with both the SNMP and the OSI network management framework. RFC 1052 (インターネット ネットワーク管理標準の開発の為のIAB 勧告)の 中で報告されるように、TCP/IPベースのインターネットのネットワーク管理 に対して２手に分かれた戦略が執られていた。短期的には、インターネット コミュニティのノード管理でSNMPを使用する事、長期的には、OSI ネットワ ーク管理フレームワークの利用を検討する事。２つの文書が管理情報を定義 する為に作成された。RFC 1065 はSMIを定義、RFC 1066 はMIBを定義した。 この２つの文書は、SNMPおよびOSI ネットワーク管理フレームワークの両方 と互換性を持つように設計された。 This strategy was quite successful in the short-term: Internet-based network management technology was fielded, by both the research and commercial communities, within a few months. As a result of this, portions of the Internet community became network manageable in a timely fashion. この戦略は短期的には大成功だった。インターネットベースのネットワーク 管理テクノロジーは、研究および商用コミュニティーの両方によって吟味さ れ、その結果、インターネットコミュニティの部分は現代風の扱い易いネッ トワークとなった。 As reported in RFC 1109, Report of the Second Ad Hoc Network Management Review Group [4], the requirements of the SNMP and the OSI RFC 1109 で報告されるように、第２特別ネットワーク管理評価グループのレ SNMP Working Group [Page 2] RFC 1213 MIB-II March 1991 network management frameworks were more different than anticipated. As such, the requirement for compatibility between the SMI/MIB and both frameworks was suspended. This action permitted the operational network management framework, the SNMP, to respond to new operational needs in the Internet community by producing this document. ポートで、予想よりもSNMPとOSI ネットワーク管理フレームワークの必要条 件は異なっていた。その為、SMI/MIB とフレームワーク間の互換性の要件は 中断された。この行動は、この文書の作成により、インターネットコミュニ ティーの中の新しい運用上のニーズに運用上のネットワーク管理フレームワ ーク(SNMP)が対応することを可能にした。 As such, the current network management framework for TCP/IP- based internets consists of: Structure and Identification of Management Information for TCP/IP-based internets, RFC 1155 [12], which describes how managed objects contained in the MIB are defined; Management Information Base for Network Management of TCP/IP-based internets: MIB-II, this memo, which describes the managed objects contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple Network Management Protocol, RFC 1098 [5], which defines the protocol used to manage these objects. ゆえに、TCP/IPベースのインターネットにおける現在のネットワーク管理フ レームワークは次から成る。TCP/IPベースのインターネットの為の管理情報 の構造と識別。RFC 1155 は、MIBに含まれた管理オブジェクトがどう定義さ れるかを説明している。TCP/IPベースのインターネットのネットワーク管理 用の、管理情報ベース MIB-II。（この文書(それは管理オブジェクトについ て説明する）は、MIB(そして、RFC 1156 に取って代わる)を含んでいる）そ してSNMP、これらのオブジェクトを管理するのに使用されるプロトコルを定 義する RFC 1098。 3. Changes from RFC 1156 RFC 1156 からの変更 Features of this MIB include: このMIBの特徴： (1) incremental additions to reflect new operational requirements; 新しい運用上の必要条件を反映する増加分の付加; (2) upwards compatibility with the SMI/MIB and the SNMP; SMI/MIB 及びSNMPとの上位互換; (3) improved support for multi-protocol entities; and, マルチプロトコルのエンティティのサポート改善; そして (4) textual clean-up of the MIB to improve clarity and readability. 可読性を良くする為に、MIBのテキストをクリーンナップ。 The objects defined in MIB-II have the OBJECT IDENTIFIER prefix: MIB-IIで定義されたオブジェクトはOBJECT IDENTIFIERを先頭に付ける: mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } which is identical to the prefix used in MIB-I. MIB-Iで使われているprefixと同じ。 3.1. Deprecated Objects 推奨しないオブジェクト In order to better prepare implementors for future changes in the MIB, a new term "deprecated" may be used when describing an object. A deprecated object in the MIB is one which must be supported, but one which will most likely be removed from the next version of the MIB (e.g., MIB-III). MIB の将来の変更の為に、よりよい作成者の準備の為に、オブジェクトにつ いて記述する時、推奨しない言葉が使われるかもしれない。MIB の推奨しな いオブジェクトはサポートしなければならないが、おそらくMIB（例えばMIB -III）の次のバージョンからは取り除かれる。 MIB-II marks one object as being deprecated: MIB-II が推奨しないオブジェクトを記す。 atTable SNMP Working Group [Page 3] RFC 1213 MIB-II March 1991 As a result of deprecating the atTable object, the entire Address Translation group is deprecated. atTableオブジェクトを推奨しないという結果は、Address Translationグル ープ全体を推奨しないという事。 Note that no functionality is lost with the deprecation of these objects: new objects providing equivalent or superior functionality are defined in MIB-II. これらのオブジェクトは非推奨だが、その機能が全く失われていないのに注 意。同等か、より優れた機能を提供する新しいオブジェクトがMIB-IIで定義 される。 3.2. Display Strings 表示文字列 In the past, there have been misinterpretations of the MIB as to when a string of octets should contain printable characters, meant to be displayed to a human. As a textual convention in the MIB, the datatype 過去に、印刷可能なキャラクタを含むべき時、文字列が人間によって表示さ れたという事を意味していたMIBの誤りがあった。MIBのデータ型式における テキスト規約として、データ型 DisplayString ::= OCTET STRING is introduced. A DisplayString is restricted to the NVT ASCII character set, as defined in pages 10-11 of [6]. を導入する。DisplayStringは [6] の10〜11ページの中で定義されるように NVT ASCII文字セットに制限される。 The following objects are now defined in terms of DisplayString: 以下のオブジェクトは現在、DisplayString として定義: sysDescr ifDescr It should be noted that this change has no effect on either the syntax nor semantics of these objects. The use of the DisplayString notation is merely an artifact of the explanatory method used in MIB-II and future MIBs. この変更がこれらのオブジェクトの構文にも意味論にも影響を及ぼさない事 に注意。 DisplayString 記法の使用は、単にMIB-IIおよび将来のMIBの中で 使用される説明的表現である。 Further it should be noted that any object defined in terms of OCTET STRING may contain arbitrary binary data, in which each octet may take any value from 0 to 255 (decimal). さらに、OCTET STRINGとして定義されたどんなオブジェクトも任意のバイナ リデータを含むかもしれないことに注意。(各バイトはその中で0〜255(10進) の任意の値を持っているかもしれない) 3.3. Physical Addresses 物理アドレス As a further, textual convention in the MIB, the datatype MIB、データ形式のさらなるテキスト規約。 PhysAddress ::= OCTET STRING is introduced to represent media- or physical-level addresses. メディアか、物理的なレベルアドレスを表現するために導入。 The following objects are now defined in terms of PhysAddress: 以下のオブジェクトは現在、PhysAddressとして定義: ifPhysAddress atPhysAddress ipNetToMediaPhysAddress SNMP Working Group [Page 4] RFC 1213 MIB-II March 1991 It should be noted that this change has no effect on either the syntax nor semantics of these objects. The use of the PhysAddress notation is merely an artifact of the explanatory method used in MIB-II and future MIBs. この変更がこれらのオブジェクトの構文にも意味論にも影響を及ぼさない事 に注意。 PhysAddress 記法の使用は、単にMIB-IIおよび将来のMIBの中で使 用される説明的表現である。 3.4. The System Group システムグループ Four new objects are added to this group: 4個の新しいオブジェクトがこのグループに追加: sysContact sysName sysLocation sysServices These provide contact, administrative, location, and service information regarding the managed node. これらは管理、位置および管理ノードに関するサービス情報を取得して提供 する。 3.5. The Interfaces Group インタフェースグループ The definition of the ifNumber object was incorrect, as it required all interfaces to support IP. (For example, devices without IP, such as MAC-layer bridges, could not be managed if this definition was strictly followed.) The description of the ifNumber object is changed accordingly. IPを必要とする全てのインタフェースをサポートしていたので、ifNumberの 定義は適当ではなかった。(例えば、この定義そのままであれば、IP のない MAC 層のブリッジなどのデバイスを管理することができなかった。) 従って ifNumber オブジェクトの記述を変更する。 The ifTable object was mistaken marked as read-write, it has been (correctly) re-designated as not-accessible. In addition, several new values have been added to the ifType column in the ifTable object: ifTable オブジェクトは read-write と間違って示されていた。not-acces sible なそれを再度（正しく）修正した。さらに、いくつかの新しい値を ifTableオブジェクトのifTypeカラムに追加した: ppp(23) softwareLoopback(24) eon(25) ethernet-3Mbit(26) nsip(27) slip(28) ultra(29) ds3(30) sip(31) frame-relay(32) Finally, a new column has been added to the ifTable object: 最終的に、新しいカラムはifTable オブジェクトに追加した: ifSpecific which provides information about information specific to the media being used to realize the interface. そしてそれは、インターフェースを実現するのに用いられているメディアに 固有な情報に関する情報を提供する。 SNMP Working Group [Page 5] RFC 1213 MIB-II March 1991 3.6. The Address Translation Group アドレストランスレーショングループ In MIB-I this group contained a table which permitted mappings from network addresses (e.g., IP addresses) to physical addresses (e.g., MAC addresses). Experience has shown that efficient implementations of this table make two assumptions: a single network protocol environment, and mappings occur only from network address to physical address. MIB-I では、このグループは、ネットワーク・アドレス(例えばIPアドレス) から物理アドレス(例えばMAC アドレス)までのマッピングを許可したテーブ ルを含んでいた。 経験上、このテーブルの効率的な実装には2つの仮定があ る: 単一ネットワークプロトコル環境と、そしてマッピングはネットワーク アドレスから物理アドレスにしか起こらない。 The need to support multi-protocol nodes (e.g., those with both the IP and CLNP active), and the need to support the inverse mapping (e.g., for ES-IS), have invalidated both of these assumptions. As such, the atTable object is declared deprecated. マルチプロトコルノード (例えば IPとCLNP の両方がアクティブなそれら） をサポートする必要や反対方向へのマッピング(例えばES-IS の為)をサポー トする必要があるが、これらは両方の仮定を無効にしている。故に atTable オブジェクトは不要と断言できる。 In order to meet both the multi-protocol and inverse mapping requirements, MIB-II and its successors will allocate up to two address translation tables inside each network protocol group. That is, the IP group will contain one address translation table, for going from IP addresses to physical addresses. Similarly, when a document defining MIB objects for the CLNP is produced (e.g., [7]), it will contain two tables, for mappings in both directions, as this is required for full functionality. マルチプロトコルおよび反対方向へのマッピングの必要条件の両方を満たす 為に、 MIB-II とその後任者は、最高２つのアドレス変換テーブルを、それ ぞれのネットワークプロトコルグループに割り当てる。すなわち、IPグルー プはIPアドレスから物理アドレスまで行くために１つのアドレス変換テーブ ルを含む。同様に、CLNP のための MIB オブジェクトを定義する文書が作成 される時 (例えば[7])、これが十分な機能のために必要になるり、それは両 方の方向のマッピングのため２つのテーブルを含むであろう。 It should be noted that the choice of two tables (one for each direction of mapping) provides for ease of implementation in many cases, and does not introduce undue burden on implementations which realize the address translation abstraction through a single internal table. ２つのテーブル(マッピングの各方向のひとつ)の選択が、多くの場合で実装 が容易になるようにする事、そして単一の内部テーブルを通ってアドレス変 換の抽出を行う時の、実装の上での余計な負担を導入しないよう注意。 3.7. The IP Group IPグループ The access attribute of the variable ipForwarding has been changed from read-only to read-write. 変数 ipForwarding のアクセス属性は、read-only からread-writeに変更。 In addition, there is a new column to the ipAddrTable object, さらに、ipAddrTable オブジェクトに新しいカラムを追加、 ipAdEntReasmMaxSize which keeps track of the largest IP datagram that can be re-assembled on a particular interface. それは特定のインターフェース上で、再編成可能な最も大きいなIPデータ グラムの情報を保持する。 The descriptor of the ipRoutingTable object has been changed to ipRouteTable for consistency with the other IP routing objects. There are also three new columns in the ipRouteTable object, ipRoutingTable オブジェクト記述子は、他のIPルーティングオブジェクトと の一貫性の為に ipRouteTable に変更。 さらに ipRouteTable オブジェクト の中に新しいカラムが３つ、 ipRouteMask ipRouteMetric5 ipRouteInfo SNMP Working Group [Page 6] RFC 1213 MIB-II March 1991 the first is used for IP routing subsystems that support arbitrary subnet masks, and the latter two are IP routing protocol-specific. １番目は、任意のサブネットマスクをサポートするIPルーティングサブシス テムのために使用される。また、後の２つはプロトコルに特有のIPルーティ ング。 Two new objects are added to the IP group: 新しい2つのオブジェクトがIPグループに加えられる。 ipNetToMediaTable ipRoutingDiscards the first is the address translation table for the IP group (providing identical functionality to the now deprecated atTable in the address translation group), and the latter provides information when routes are lost due to a lack of buffer space. １番目は、IPグループ(同一の機能を提供して不要を宣言された Address T- ranslation Group の atTable )用のアドレス変換テーブル。 また、後者は ルートがバッファスペース不足により失われる場合の情報を提供する。 3.8. The ICMP Group ICMPグループ There are no changes to this group. このグループへの変更はなし。 3.9. The TCP Group TCPグループ Two new variables are added: 二つの新しい変数が追加。 tcpInErrs tcpOutRsts which keep track of the number of incoming TCP segments in error and the number of resets generated by a TCP. 入力時の TCP セグメントエラーおよび TCP によってリセットされた数を保持する。 3.10. The UDP Group UDPグループ A new table: 新テーブル udpTable is added. 追加。 3.11. The EGP Group EGPグループ Experience has indicated a need for additional objects that are useful in EGP monitoring. In addition to making several additions to the egpNeighborTable object, i.e., 経験から、EGPモニタリングに役立つオブジェクトを追加する必要があった。 すなわち、egpNeighborTable オブジェクトへいくつか追加することに加えて、 egpNeighAs egpNeighInMsgs egpNeighInErrs egpNeighOutMsgs egpNeighOutErrs egpNeighInErrMsgs egpNeighOutErrMsgs SNMP Working Group [Page 7] RFC 1213 MIB-II March 1991 egpNeighStateUps egpNeighStateDowns egpNeighIntervalHello egpNeighIntervalPoll egpNeighMode egpNeighEventTrigger a new variable is added: 新しい変数を追加: egpAs which gives the autonomous system associated with this EGP entity. そして、自律システムをEGPエンティティに与えて結びつけた。 3.12. The Transmission Group トランスミッショングループ MIB-I was lacking in that it did not distinguish between different types of transmission media. A new group, the Transmission group, is allocated for this purpose: MIB-I は、異なるタイプの通信メディアを識別しないところが欠点だった。 よって、新しいグループ(Transmissionグループ)を割り当てる: transmission OBJECT IDENTIFIER ::= { mib-2 10 } When Internet-standard definitions for managing transmission media are defined, the transmission group is used to provide a prefix for the names of those objects. 送信メディアを管理するためのインターネット標準定義が定義される場合、 トランスミッショングループはそれらオブジェクトの名前の prefix を提供 するために使用される。 Typically, such definitions reside in the experimental portion of the MIB until they are "proven", then as a part of the Internet standardization process, the definitions are accordingly elevated and a new object identifier, under the transmission group is defined. By convention, the name assigned is: 通常、そのような定義はMIB の実験部分で「証明される」まで存在する。そ の後、インターネット標準化プロセスの一部として、定義はそれに応じて新 しいオブジェクト識別子として立ち上がり、トランスミッショングループの 元で定義される。規約で割り当てられた名前は以下の通り: type OBJECT IDENTIFIER ::= { transmission number } where "type" is the symbolic value used for the media in the ifType column of the ifTable object, and "number" is the actual integer value corresponding to the symbol. type が ifTable オブジェクトの ifType カラムのメディアで使用されるシ ンボル値であり、number がシンボル値に対応する実際の整数値となる。 3.13. The SNMP Group SNMPグループ The application-oriented working groups of the IETF have been tasked to be receptive towards defining MIB variables specific to their respective applications. IETF の application-oriented ワーキンググループは、彼らのそれぞれのア プリケーションに、MIB 変数仕様の定義に向けて受容的であるよう課された。 For the SNMP, it is useful to have statistical information. A new group, the SNMP group, is allocated for this purpose: SNMP のために、統計情報を持つことは有用である。新しいグループ（SNMP グループ）は、このために割り当てられる： snmp OBJECT IDENTIFIER ::= { mib-2 11 } SNMP Working Group [Page 8] RFC 1213 MIB-II March 1991 3.14. Changes from RFC 1158 RFC1158 からの変更 Features of this MIB include: このMIBの特徴： (1) The managed objects in this document have been defined using the conventions defined in the Internet-standard SMI, as amended by the extensions specified in [14]. It must be emphasized that definitions made using these extensions are semantically identically to those in RFC 1158. この文書中の管理オブジェクトは、[14] の拡張仕様によって修正され るようにインターネット標準SMIに定義された規約を使用して定義され た。これらの拡張を使用して作られた定義が、RFC 1158 の中のものに 意味的に同じであることが強調されるに違いない。 (2) The PhysAddress textual convention has been introduced to represent media addresses. メディアアドレスを表すためにPhysAddressのテキスト規約を導入。 (3) The ACCESS clause of sysLocation is now read-write. 現在、sysLocation のアクセスモードはread-write。 (4) The definition of sysServices has been clarified. sysService の定義は明確になった。 (5) New ifType values (29-32) have been defined. In addition, the textual-descriptor for the DS1 and E1 interface types has been corrected. 新しい ifType (29-32)が定義された。さらに、DS1 および E1 インタ ーフェースタイプのためのテキスト記述子は修正された。 (6) The definition of ipForwarding has been clarified. ipForwarding の定義は明確になった。 (7) The definition of ipRouteType has been clarified. ipRouteType の定義は明確になった。 (8) The ipRouteMetric5 and ipRouteInfo objects have been defined. ipRouteMetric5 とipRouteInfo オブジェクトが定義された。 (9) The ACCESS clause of tcpConnState is now read-write, to support deletion of the TCB associated with a TCP connection. The definition of this object has been clarified to explain this usage. tcpConnState のアクセスモードはTCP接続に関連したTCBの削除をサポ ートするために現在 read-write。このオブジェクトの定義はこの使い 方の説明のために明確にされた。 (10) The definition of egpNeighEventTrigger has been clarified. egpNeighEventTrigger の定義は明確になった。 (11) The definition of several of the variables in the new snmp group have been clarified. In addition, the snmpInBadTypes and snmpOutReadOnlys objects are no longer present. (However, the object identifiers associated with those objects are reserved to prevent future use.) 新しいSNMP グループ中のいくつかの変数の定義は明確にされた。それ に加えて、snmpInBadTypes と snmpOutReadOnlys オブジェクトは、も はや存在しない。(しかしながら、それらのオブジェクトに関連してい るオブジェクト識別子は今後の使用を防ぐために予約される) (12) The definition of snmpInReadOnlys has been clarified. snmpInReadOnlys の定義は明確になった。 (13) The textual descriptor of the snmpEnableAuthTraps has been changed to snmpEnableAuthenTraps, and the definition has been clarified. snmpEnableAuthTraps のテキスト記述子は snmpEnableAuthenTraps に 変更された。そして定義が明確になった。 SNMP Working Group [Page 9] RFC 1213 MIB-II March 1991 (14) The ipRoutingDiscards object was added. ipRoutingDiscards オブジェクトが追加された。 (15) The optional use of an implementation-dependent, small positive integer was disallowed when identifying instances of the IP address and routing tables. IP アドレスとルーティングテーブルのインスタンスを識別するとき 実装依存の小さな正の整数の任意の使用が禁止された。 4. Objects オブジェクト Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) [8] defined in the SMI. In particular, each object has a name, a syntax, and an encoding. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the OBJECT DESCRIPTOR, to also refer to the object type. 管理オブジェクトは管理情報ベースかMIB と名付けられ、仮想情報ストア経 由でアクセスされる。MIBの中のオブジェクトは、SMIに定義されたアセンワ ン(ASN.1)[8]のサブセットを使用して定義される。各オブジェクトは特有の 名前、文法およびコード化を持っている。名前は、オブジェクトタイプを指 定するオブジェクト識別子(管理上割り当てられた名前)。オブジェクトイン スタンスと一緒のオブジェクトタイプは、一意にオブジェクトの具体的詳細 を識別するのに役に立つ。人の利便性について、我々はオブジェクトタイプ を参照するために、オブジェクトディスクリプタと呼ばれるテキスト文字列 をしばしば使用する。 The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 language is used for this purpose. However, the SMI [12] purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. オブジェクトタイプの文法はそのオブジェクトタイプに対応する抽象的なデ ータ構造を定義する。アセンワンはこの目的のために使用される。しかし、 SMI[12] は故意にアセンワンの利用構成について制限するかもするかもしれ ない。これらの制限はシンプル性のために明確に作られる。 The encoding of an object type is simply how that object type is represented using the object type's syntax. Implicitly tied to the notion of an object type's syntax and encoding is how the object type is represented when being transmitted on the network. オブジェクトタイプのコード化は単に、そのオブジェクトタイプがオブジェ クトタイプの文法を使って、どのように表わされるかによる。暗黙に、ネッ トワーク上で送信される場合、オブジェクトタイプがどのように表わされる かが、オブジェクトタイプの文法およびコード化についての概念に紐付く。 The SMI specifies the use of the basic encoding rules of ASN.1 [9], subject to the additional requirements imposed by the SNMP. SMI は、アセンワン[9](SNMPによって課された追加の必要条件に従う)の基 本的なコード化を行う規則の使用を指定する。 4.1. Format of Definitions 定義フォーマット Section 6 contains contains the specification of all object types contained in this MIB module. The object types are defined using the conventions defined in the SMI, as amended by the extensions specified in [14]. ６章は、このMIB モジュールに含まれていたすべてのオブジェクトタイプの 詳細を含んでいる。オブジェクトタイプは、[14]に指定された拡張によって 修正されるように、SMIに定義された規約を使用して定義される。 5. Overview 概要 Consistent with the IAB directive to produce simple, workable systems in the short-term, the list of managed objects defined here, has been derived by taking only those elements which are considered essential. 不可欠であると考えられる要素だけを抽出した（ここで定義された管理オブ ジェクトのリスト）短期間でのシンプルな稼動可能なシステムの作りは IAB の方針と合致する。 This approach of taking only the essential objects is NOT restrictive, since the SMI defined in the companion memo provides 本質的なオブジェクトだけをとるこのアプローチは制限していない。仲間メ モに定義されたSMIが3つの拡張メカニズムを提供する: SNMP Working Group [Page 10] RFC 1213 MIB-II March 1991 three extensibility mechanisms: one, the addition of new standard objects through the definitions of new versions of the MIB; two, the addition of widely-available but non-standard objects through the experimental subtree; and three, the addition of private objects through the enterprises subtree. Such additional objects can not only be used for vendor-specific elements, but also for experimentation as required to further the knowledge of which other objects are essential. 1、MIB の新バージョンの定義による新しい標準オブジェクトの追加。 2、実 験のサブツリーによる広く利用可能であるが非標準のオブジェクトの追加。3 、企業サブツリーによる私的オブジェクトの追加。 このような追加のオブジ ェクトは単にベンダーに特有の要素のために使用されるのみでなく、 他のオ ブジェクトが知識を促進するよう求められるような実験に不可欠。 The design of MIB-II is heavily influenced by the first extensibility mechanism. Several new variables have been added based on operational experience and need. Based on this, the criteria for including an object in MIB-II are remarkably similar to the MIB-I criteria: MIB-II のデザインは、極度に第1の拡張メカニズムによって影響を受ける。 いくつかの新しい変数は運用上の経験および必要に基づいて加えられた。こ れに基づいてMIB-IIにオブジェクトを含んでいる基準は、MIB-I 基準に類似 している: (1) An object needed to be essential for either fault or configuration management. オブジェクトはフォールトか構成管理のいずれかに不可欠である必要 があった。 (2) Only weak control objects were permitted (by weak, it is meant that tampering with them can do only limited damage). This criterion reflects the fact that the current management protocols are not sufficiently secure to do more powerful control operations. 弱い制御オブジェクトだけが許可される。（弱いとは、それをいじる ことが単に制限された損害しか与えられる事ができないことが意味さ れる）この基準は、現在の管理プロトコルがより強力な制御機能を行 うのには十分に安全ではないという事実を反映する。 (3) Evidence of current use and utility was required. 現在の使い方と有効性に関する証拠が必要。 (4) In MIB-I, an attempt was made to limit the number of objects to about 100 to make it easier for vendors to fully instrument their software. In MIB-II, this limit was raised given the wide technological base now implementing MIB-I. MIB-I では、ベンダーが完全にソフトウェアに機器を備えることをよ り容易にするためにオブジェクトの数を約１００に制限する試みがな された。MIB-II ではこの限界は今MIB-Iを実装する広い技術的な基礎 を与えられて引き上げられている。 (5) To avoid redundant variables, it was required that no object be included that can be derived from others in the MIB. 冗長変数を回避するため、MIB の中の他に由来することができるオブ ジェクトを含まない事。 (6) Implementation specific objects (e.g., for BSD UNIX) were excluded. 実装における特定のオブジェクト(例えばBSD UNIXのため)を除外。 (7) It was agreed to avoid heavily instrumenting critical sections of code. The general guideline was one counter per critical section per layer. コードのクリティカルセクションの実装を避ける事は同意済み。一般 的なガイドラインは1層のクリティカルセクションに1つのカウンター。 MIB-II, like its predecessor, the Internet-standard MIB, contains only essential elements. There is no need to allow individual objects to be optional. Rather, the objects are arranged into the following groups: MIB-II は以前のMIB の全ての要素を含んでいる。個々のオブジェクトがオ プションとして加わる必要性はない 。正確に言うと、オブジェクトは次の グループに整理される: SNMP Working Group [Page 11] RFC 1213 MIB-II March 1991 - System - Interfaces - Address Translation (deprecated) - IP - ICMP - TCP - UDP - EGP - Transmission - SNMP These groups are the basic unit of conformance: This method is as follows: if the semantics of a group is applicable to an implementation, then it must implement all objects in that group. For example, an implementation must implement the EGP group if and only if it implements the EGP. これらグループの基本的な配置の単位:メソッドは次の通り:グループの意義 が実装に適したものであれば、そのグループ内の全てのオブジェクトをすべ て実装しなければならない。例えば、その実装がEGPの実装であれば、EGPグ ループを実装しなければならない。 There are two reasons for defining these groups: to provide a means of assigning object identifiers; and, to provide a method for implementations of managed agents to know which objects they must implement. これらのグループを定義する２つの理由：オブジェクト識別子を割り当てる 手段を提供する; そして、それらがどのオブジェクトを実装しなければなら ないかを知る為のメソッドを管理エージェントの実装に提供する。 6. Definitions 定義 RFC1213-MIB DEFINITIONS ::= BEGIN -- MIB 定義開始 IMPORTS -- 他の定義ファイルから変数型・オブジェクトIDをインポート mgmt, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212; -- This MIB module uses the extended OBJECT-TYPE macro as -- defined in [14]; -- このMIBモジュールは[14]で定義されている拡張OBJECT-TYPEマクロを使用; -- MIB-II (same prefix as MIB-I) -- MIB-I と同じ prefix mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- MIB-2 のオブジェクトID -- textual conventions -- 書き方の規約 -- この定義ファイル中で使用する型について定義している。 -- OCTET STRING 型から派生している。 DisplayString ::= OCTET STRING -- This data type is used to model textual information taken -- from the NVT ASCII character set. By convention, objects -- with this syntax are declared as having -- このデータ型は、NVT ASCII 文字セットのテキスト情報をモデル -- 化して使用している。規約によって、この書式を備えたオブジェ -- クトを持っているものとして宣言される。 SNMP Working Group [Page 12] RFC 1213 MIB-II March 1991 -- -- SIZE (0..255) PhysAddress ::= OCTET STRING -- This data type is used to model media addresses. For many -- types of media, this will be in a binary representation. -- For example, an ethernet address would be represented as -- a string of 6 octets. -- このデータ型は、メディアアドレスをモデル化するのに使用され -- る。多くのタイプのメディアにおいて、これは２進表現であるは -- ず。例えばイーサネットアドレスは６バイトの文字列として表現 -- される。 -- groups in MIB-II -- MIB-II グループ system OBJECT IDENTIFIER ::= { mib-2 1 } interfaces OBJECT IDENTIFIER ::= { mib-2 2 } at OBJECT IDENTIFIER ::= { mib-2 3 } ip OBJECT IDENTIFIER ::= { mib-2 4 } icmp OBJECT IDENTIFIER ::= { mib-2 5 } tcp OBJECT IDENTIFIER ::= { mib-2 6 } udp OBJECT IDENTIFIER ::= { mib-2 7 } egp OBJECT IDENTIFIER ::= { mib-2 8 } -- historical (some say hysterical) -- cmot OBJECT IDENTIFIER ::= { mib-2 9 } transmission OBJECT IDENTIFIER ::= { mib-2 10 } snmp OBJECT IDENTIFIER ::= { mib-2 11 } -- the System group -- システムグループのオブジェクトを定義 -- Implementation of the System group is mandatory for all -- systems. If an agent is not configured to have a value -- for any of these variables, a string of length 0 is -- returned. -- Systemグループの実装はすべてのシステムに必須。これらの変数 -- の値をエージェントが持っていない場合は長さ０の文字列を返す。 sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory SNMP Working Group [Page 13] RFC 1213 MIB-II March 1991 DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software. It is mandatory that this only contain printable ASCII characters." エンティティの記述方法。この値はシステムのハード ウェアタイプ、ソフトウェアオペレーティングシステ ム、およびネットワークソフトウェアのフルネームと バージョン識別を含むべき。これが印刷可能なASCII キャラクタを含むだけである事は必須。 ::= { system 1 } -- オブジェクトＩＤ sysObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The vendor's authoritative identification of the network management subsystem contained in the entity. This value is allocated within the SMI enterprises subtree (1.3.6.1.4.1) and provides an easy and unambiguous means for determining `what kind of box' is being managed. For example, if vendor `Flintstones, Inc.' was assigned the subtree 1.3.6.1.4.1.4242, it could assign the identifier 1.3.6.1.4.1.4242.1.1 to its `Fred Router'." どのようなネットワーク管理サブシステムがエンティ ティに含まれるかを、ベンダーを示すことによって表 した値。この値はSMIのサブツリー (1.3.6.1.4.1) の 下に割り振られ'どういう装置'が管理されているかを 簡単で正確に知る事ができる。 例えば、サブツリー 1.3.6.1.4.1.4242 がベンダー 'Flintstones Inc.'に 割り当てられた時、それは 1.3.6.1.4.1.4242.1.1 を 識別子として'FredRouter'に割り当てるかもしれない。 ::= { system 2 } sysUpTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." システムのネットワーク・マネージメントの一部が最 後に初期化されてからの時間 (1/100秒) ::= { system 3 } sysContact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The textual identification of the contact person for this managed node, together with information on how to contact this person." このノードを管理する人への連絡方法とその人の情報。 ::= { system 4 } sysName OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) SNMP Working Group [Page 14] RFC 1213 MIB-II March 1991 ACCESS read-write STATUS mandatory DESCRIPTION "An administratively-assigned name for this managed node. By convention, this is the node's fully-qualified domain name." この管理されたノードのための管理上割り当てられた 名前。規約で、これはノードの完璧なドメインネーム。 ::= { system 5 } sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-write STATUS mandatory DESCRIPTION "The physical location of this node (e.g., `telephone closet, 3rd floor')." このノードの物理的な場所 (例えば'電話台、3階') ::= { system 6 } sysServices OBJECT-TYPE SYNTAX INTEGER (0..127) ACCESS read-only STATUS mandatory DESCRIPTION "A value which indicates the set of services that this entity primarily offers. このエンティティが主にどのようなサービスを提供するか。 The value is a sum. This sum initially takes the value zero, Then, for each layer, L, in the range 1 through 7, that this node performs transactions for, 2 raised to (L - 1) is added to the sum. For example, a node which performs primarily routing functions would have a value of 4 (2^(3-1)). In contrast, a node which is a host offering application services would have a value of 72 (2^(4-1) + 2^(7-1)). Note that in the context of the Internet suite of protocols, values should be calculated accordingly: 合計が値となる。この値には最初0がセットされる。このノード が処理を行うそれぞれのレイヤに対し、レイヤをL(1層から7層の 範囲)で表すとした場合、2の(L-1)乗を加算していく。例えば 主にルーティング機能の処理をするノードの値は4となる。 (2^(3-1))。これに対して、ノードがアプリケーションサービス を提供するホストである時は72が値となる。(2^(4-1)+2^(7-1)) プロトコルのインターネット統合に関する文脈では、値がそれに 従って計算されるべきであるのに注意。 layer functionality 1 physical (e.g., repeaters) 2 datalink/subnetwork (e.g., bridges) 3 internet (e.g., IP gateways) 4 end-to-end (e.g., IP hosts) 7 applications (e.g., mail relays) For systems including OSI protocols, layers 5 and 6 may also be counted." OSI のプロトコルを含むシステムでは、５層、６層も カウントされるかもしれない。 ::= { system 7 } SNMP Working Group [Page 15] RFC 1213 MIB-II March 1991 -- the Interfaces group -- インタフェースグループのオブジェクトを定義 -- Implementation of the Interfaces group is mandatory for -- all systems. -- インタフェースグループの実装はすべてのシステムに必須。 ifNumber OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The number of network interfaces (regardless of their current state) present on this system." このシステムの現在のネットワークインタフェース数。 （現状況にかかわらず） ::= { interfaces 1 } -- the Interfaces table -- インタフェーステーブルの定義 -- The Interfaces table contains information on the entity's -- interfaces. Each interface is thought of as being -- attached to a `subnetwork'. Note that this term should -- not be confused with `subnet' which refers to an -- addressing partitioning scheme used in the Internet suite -- of protocols. -- Interfacesテーブルはエンティティのインタフェースに関する情報を含ん -- でいる。各インタフェースは'サブネットワーク'に付けられていると考え -- られる。インターネットプロトコル全般で使用されるアドレシング区画の -- 計画について言及する'サブネット'と混同しないよう注意。 ifTable OBJECT-TYPE -- テーブル型の定義 SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible -- アクセス不可 STATUS mandatory -- 必須 DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifNumber." インタフェースエントリーリスト。ifNumberの値で エントリー数を与える。 ::= { interfaces 2 } -- ifTable は interfaceグループの２番目 ifEntry OBJECT-TYPE -- テーブル中のエントリーの型定義。エントリーの型が ifEntry となる。 SYNTAX IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular interface." サブネットワーク層における以下の特定のインタフェースへの オブジェクトを含むインタフェースエントリー。 INDEX { ifIndex } ::= { ifTable 1 } -- ifEntry は ifTable の１番目 IfEntry ::= -- エントリーメンバーのプロトタイプ宣言みたいなもの SEQUENCE { ifIndex INTEGER, SNMP Working Group [Page 16] RFC 1213 MIB-II March 1991 ifDescr DisplayString, ifType INTEGER, ifMtu INTEGER, ifSpeed Gauge, ifPhysAddress PhysAddress, ifAdminStatus INTEGER, ifOperStatus INTEGER, ifLastChange TimeTicks, ifInOctets Counter, ifInUcastPkts Counter, ifInNUcastPkts Counter, ifInDiscards Counter, ifInErrors Counter, ifInUnknownProtos Counter, ifOutOctets Counter, ifOutUcastPkts Counter, ifOutNUcastPkts Counter, ifOutDiscards Counter, ifOutErrors Counter, ifOutQLen Gauge, ifSpecific OBJECT IDENTIFIER } ifIndex OBJECT-TYPE -- エントリーメンバーの定義 SYNTAX INTEGER ACCESS read-only STATUS mandatory SNMP Working Group [Page 17] RFC 1213 MIB-II March 1991 DESCRIPTION "A unique value for each interface. Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re- initialization." 各インタフェースへのユニークな値。値の範囲は1からifNumber 値の間。各インタフェースへの値は少なくとも1つの次への エンティティのネットワーク管理システムの再初期化から次の 再初期化まで一定のままで残っていなければならない。 ::= { ifEntry 1 } ifDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A textual string containing information about the interface. This string should include the name of the manufacturer, the product name and the version of the hardware interface." インタフェースに関する情報を表すテキスト文字列。この文字列 には、メーカー名、製品名、およびハードウェアインタフェース のバージョンを含むべき。 ::= { ifEntry 2 } ifType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following regular1822(2), hdh1822(3), ddn-x25(4), rfc877-x25(5), ethernet-csmacd(6), iso88023-csmacd(7), iso88024-tokenBus(8), iso88025-tokenRing(9), iso88026-man(10), starLan(11), proteon-10Mbit(12), proteon-80Mbit(13), hyperchannel(14), fddi(15), lapb(16), sdlc(17), ds1(18), -- T-1 e1(19), -- european equiv. of T-1 basicISDN(20), primaryISDN(21), -- proprietary serial propPointToPointSerial(22), ppp(23), softwareLoopback(24), eon(25), -- CLNP over IP [11] ethernet-3Mbit(26), SNMP Working Group [Page 18] RFC 1213 MIB-II March 1991 nsip(27), -- XNS over IP slip(28), -- generic SLIP ultra(29), -- ULTRA technologies ds3(30), -- T-3 sip(31), -- SMDS frame-relay(32) } ACCESS read-only STATUS mandatory DESCRIPTION "The type of interface, distinguished according to the physical/link protocol(s) immediately `below' the network layer in the protocol stack." インタフェースのタイプ。タイプは、プロトコロルスタック でネットワーク層のすぐ下位にある物理層/データリンク層の プロトコルによって区別される。 ::= { ifEntry 3 } ifMtu OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The size of the largest datagram which can be sent/received on the interface, specified in octets. For interfaces that are used for transmitting network datagrams, this is the size of the largest network datagram that can be sent on the interface." バイトで指定されたインタフェースに送信、または受信可能な 最大のデータグラムサイズ。ネットワークデータグラムを 送信するのに使用されるインタフェースに関しては、これは インタフェースで送信することができる中で最も大きい ネットワークデータグラムのサイズ。 ::= { ifEntry 4 } ifSpeed OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "An estimate of the interface's current bandwidth in bits per second. For interfaces which do not vary in bandwidth or for those where no accurate estimation can be made, this object should contain the nominal bandwidth." bpsでのインタフェースの現在の推定帯域幅。帯域幅が変化 しないインタフェースや、正確な推定値が得られない インタフェースでは、公称値を表示。 ::= { ifEntry 5 } ifPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-only STATUS mandatory DESCRIPTION "The interface's address at the protocol layer immediately `below' the network layer in the protocol stack. For interfaces which do not have プロトコルスタックでネットワーク層のすぐ下位にある プロトコルの階層におけるインタフェースアドレス。 SNMP Working Group [Page 19] RFC 1213 MIB-II March 1991 such an address (e.g., a serial line), this object should contain an octet string of zero length." このようなアドレスを持たない（例えばシリアルラインなど） インタフェースでは、バイト単位でゼロを表示。 ::= { ifEntry 6 } ifAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } ACCESS read-write STATUS mandatory DESCRIPTION "The desired state of the interface. The testing(3) state indicates that no operational packets can be passed." インタフェースの望ましい状態。testing(3)は、どんな操作上の パケットも通過することができない。 ::= { ifEntry 7 } ifOperStatus OBJECT-TYPE SYNTAX INTEGER { up(1), -- ready to pass packets down(2), testing(3) -- in some test mode } ACCESS read-only STATUS mandatory DESCRIPTION "The current operational state of the interface. The testing(3) state indicates that no operational packets can be passed." インタフェースの現在の状態。testing(3)は、どんな操作上の パケットも通過することができない。 ::= { ifEntry 8 } ifLastChange OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The value of sysUpTime at the time the interface entered its current operational state. If the current state was entered prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." インタフェースが現在の動作状態になった時の SysUpTime の値。 ローカルネットワーク管理サブシステムが最後に再初期化される 前に現在の状態となっていた場合は、ゼロが表示される。 ::= { ifEntry 9 } ifInOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only SNMP Working Group [Page 20] RFC 1213 MIB-II March 1991 STATUS mandatory DESCRIPTION "The total number of octets received on the interface, including framing characters." フレーミング文字を含むインタフェースで受信したバイト の総数。 ::= { ifEntry 10 } ifInUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of subnetwork-unicast packets delivered to a higher-layer protocol." 上位階層のプロトコルに渡されたサブネットワーク ユニキャストパケットの数。 ::= { ifEntry 11 } ifInNUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of non-unicast (i.e., subnetwork- broadcast or subnetwork-multicast) packets delivered to a higher-layer protocol." 上位階層のプロトコルに渡された非ユニキャスト(サブネット ワークブロードキャストか、サブネットワークマルチキャスト) パケットの数。 ::= { ifEntry 12 } ifInDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space." エラーが検出されなかったにもかかわらず破棄され、上位階層に 渡されなかった着信パケットの数。バッファ空間の空きスペース を増やすために、このようなパケットが破棄される事がある。 ::= { ifEntry 13 } ifInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol." エラーがあったため上位階層のプロコトルに渡されなかった 着信パケットの数。 ::= { ifEntry 14 } SNMP Working Group [Page 21] RFC 1213 MIB-II March 1991 ifInUnknownProtos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of packets received via the interface which were discarded because of an unknown or unsupported protocol." インタフェースを経由して受信し、プロトコルが未知または サポートされていないために破棄されたパケットの数。 ::= { ifEntry 15 } ifOutOctets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters." フレーミング文字を含むインタフェースから送信された バイトの総数。 ::= { ifEntry 16 } ifOutUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted to a subnetwork-unicast address, including those that were discarded or not sent." 上位階層のプロトコルがサブネットワークユニキャストアドレス に対して送信を要求した総パケット数。破棄されたパケットや 送信されなかったパケットも含む。 ::= { ifEntry 17 } ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted to a non- unicast (i.e., a subnetwork-broadcast or subnetwork-multicast) address, including those that were discarded or not sent." 上位階層のプロトコルが非ユニキャスト (サブネットワーク ブロードキャストまたはサブネットワークマルチキャスト) アドレスに対して送信を要求した総パケット数。破棄された パケットや送信されなかったパケットも含む。 ::= { ifEntry 18 } ifOutDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of outbound packets which were chosen エラーが検出されなかったにもかかわらず破棄され SNMP Working Group [Page 22] RFC 1213 MIB-II March 1991 to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space." 送信されなかった発信パケットの数。バッファ空間の空き スペースを増やすために、このようなパケットが破棄される 事がある。 ::= { ifEntry 19 } ifOutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of outbound packets that could not be transmitted because of errors." エラーがあったため送信されなかった発信パケットの数。 ::= { ifEntry 20 } ifOutQLen OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The length of the output packet queue (in packets)." 送信パケットキューの長さ。(単位: パケット) ::= { ifEntry 21 } ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular media being used to realize the interface. For example, if the interface is realized by an ethernet, then the value of this object refers to a document defining objects specific to ethernet. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." インターフェイスのメディアの特性を定義するMIBへの リファレンス。例えば、インタフェースがイーサネットによって 実現される場合、オブジェクトの値はイーサネットに特定の オブジェクトを定義するドキュメントを参照する。この情報が 存在しない場合、値がOBJECT IDENTIFIER{ 0 0 }に設定される べきで、ASN.1とBERのどんなconformant実装も、この値を生成 して認識できなければならない。(OBJECT IDENTIFIERは syntaticallyに有効なオブジェクト識別子) ::= { ifEntry 22 } -- the Address Translation group -- アドレストランスレーショングループ -- Implementation of the Address Translation group is -- mandatory for all systems. Note however that this group -- is deprecated by MIB-II. That is, it is being included -- Address Translationグループの実装はすべてのシステムに必須。 -- しかしながら、このグループはMIB-IIで推奨していない事に注意。 SNMP Working Group [Page 23] RFC 1213 MIB-II March 1991 -- solely for compatibility with MIB-I nodes, and will most -- likely be excluded from MIB-III nodes. From MIB-II and -- onwards, each network protocol group contains its own -- address translation tables. -- これはMIB-1ノードとの互換性のために含まれている。MIB-3ノードからは -- 取り除かれるであろう。またこれらはMIB-2では network protocol group -- に含まれる。 -- The Address Translation group contains one table which is -- the union across all interfaces of the translation tables -- for converting a NetworkAddress (e.g., an IP address) into -- a subnetwork-specific address. For lack of a better term, -- this document refers to such a subnetwork-specific address -- as a `physical' address. -- このAddress Translation group はネットワークアドレス（例えば、IP -- アドレス）からサブネットアドレスへの変換テーブルも含むべきである。 -- しかし、ここでは適当な定義をしてないため、サブネットアドレスは -- あたかも物理アドレスかのようになっている。 -- Examples of such translation tables are: for broadcast -- media where ARP is in use, the translation table is -- equivalent to the ARP cache; or, on an X.25 network where -- non-algorithmic translation to X.121 addresses is -- required, the translation table contains the -- NetworkAddress to X.121 address equivalences. -- 変換テーブルの例を挙げてみる。たとえば、ブロードキャストメディアと -- してARPを用いる場合、変換テーブルはARPキャッシュと同じ意味を持つ。 -- または、アルゴリズミックな変換機能が必要のないX.25ネットワークでは -- 変換テーブルはネットワークアドレスからX.121アドレスへの変換機能と -- 同じ意味を持つことになる。 atTable OBJECT-TYPE SYNTAX SEQUENCE OF AtEntry ACCESS not-accessible STATUS deprecated DESCRIPTION "The Address Translation tables contain the NetworkAddress to `physical' address equivalences. Some interfaces do not use translation tables for determining address equivalences (e.g., DDN-X.25 has an algorithmic method); if all interfaces are of this type, then the Address Translation table is empty, i.e., has zero entries." Address Translation テーブルは"物理的な"アドレス相当値 に対するNetworkAddressのテーブルを含んでいる。いくつかの インタフェースはアドレス相当値を決定するために変換テーブル を使用しない。(例えば、DDN-X.25には、アルゴリズムメソッド がある)このようなタイプの場合は，Address Translation テーブルは空であり，エントリの数はゼロとなる。 ::= { at 1 } atEntry OBJECT-TYPE SYNTAX AtEntry ACCESS not-accessible STATUS deprecated DESCRIPTION "Each entry contains one NetworkAddress to `physical' address equivalence." 各々のエントリは、1つのネットワークアドレスと 対応する物理アドレスを持っている。 INDEX { atIfIndex, atNetAddress } ::= { atTable 1 } AtEntry ::= SEQUENCE { atIfIndex INTEGER, SNMP Working Group [Page 24] RFC 1213 MIB-II March 1991 atPhysAddress PhysAddress, atNetAddress NetworkAddress } atIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS deprecated DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." このエントリに該当する有効なインタフェースの番号。 この値で識別されるインタフェースとifIndexの値で 識別されるインタフェースは同じ。 ::= { atEntry 1 } atPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS deprecated DESCRIPTION "The media-dependent `physical' address. メディアに依存したPhysicalAddress。 Setting this object to a null string (one of zero length) has the effect of invaliding the corresponding entry in the atTable object. That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant atPhysAddress object." このオブジェクトにヌル文字(長さが０)を設定すると、atTable の中で、対応するエントリを無効に出来る。 即ち、この エントリのある変換テーブルから、そのエントリを実際に 切り離す。テーブルから無効になったエントリを、エージェント が削除するようにするかどうかは実装上の問題。従って、管理 する側は現在使われなくなったエントリに関するエージェント からの表形式の情報を受け取る用意をしておかなければならない。 このようなエントリの情報を正しく得るには、該当する atPhysAddressの値を確かめなくてはならない。 ::= { atEntry 2 } atNetAddress OBJECT-TYPE SYNTAX NetworkAddress ACCESS read-write STATUS deprecated DESCRIPTION "The NetworkAddress (e.g., the IP address) corresponding to the media-dependent `physical' address." メディアに依存する物理アドレスに対応するネットワーク アドレス。(例えば、IPアドレス) SNMP Working Group [Page 25] RFC 1213 MIB-II March 1991 ::= { atEntry 3 } -- the IP group -- IPグループ -- Implementation of the IP group is mandatory for all -- systems. -- IPグループの実装はすべてのシステムに必須。 ipForwarding OBJECT-TYPE SYNTAX INTEGER { forwarding(1), -- acting as a gateway not-forwarding(2) -- NOT acting as a gateway } ACCESS read-write STATUS mandatory DESCRIPTION "The indication of whether this entity is acting as an IP gateway in respect to the forwarding of datagrams received by, but not addressed to, this entity. IP gateways forward datagrams. IP hosts do not (except those source-routed via the host). このエンティティが、受信データグラムをフォワーディング するという意味において、IPゲートウェイとして機能するか どうかを表す。IPゲートウェイはデータグラムをフォワード する。IPホストは(ホスト経由のソースルートを除く) フォワードしない。 Note that for some managed nodes, this object may take on only a subset of the values possible. Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to change this object to an inappropriate value." いくつかの被管理ノードに対しては、このオブジェクトは可能な 値の一部しか取らないことがある。従い、エージェントは、管理 ステーションがこのオブジェクトの値を不適当な値に変えようと した時には、"badValue"の返答をするほうが良い。 ::= { ip 1 } ipDefaultTTL OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The default value inserted into the Time-To-Live field of the IP header of datagrams originated at this entity, whenever a TTL value is not supplied by the transport layer protocol." トランスポート層のプロトコルでTTLの値が与えられなかった 時に、このエンティティで発生したデータグラムのIPヘッダ のTime-To-Liveフィールドに設定されるデフォルトの値。 ::= { ip 2 } ipInReceives OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams received from interfaces, including those received in error." エラーも含め、インタフェースに到着した全ての 受信データグラムの総数。 SNMP Working Group [Page 26] RFC 1213 MIB-II March 1991 ::= { ip 3 } ipInHdrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams discarded due to errors in their IP headers, including bad checksums, version number mismatch, other format errors, time-to-live exceeded, errors discovered in processing their IP options, etc." チェックサムエラー、バージョン番号エラー、フォーマット エラー、TTLエラー、IPオプションエラーなど、IPヘッダにエ ラーがある為に捨てられた受信データグラムの数。 ::= { ip 4 } ipInAddrErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams discarded because the IP address in their IP header's destination field was not a valid address to be received at this entity. This count includes invalid addresses (e.g., 0.0.0.0) and addresses of unsupported Classes (e.g., Class E). For entities which are not IP Gateways and therefore do not forward datagrams, this counter includes datagrams discarded because the destination address was not a local address." IPヘッダの宛先フィールドのIPアドレスが、このエンティティ では受け取っても意味のない値になっている受信データグラム の数。このカウンタは、無効であるアドレス(例えば 0.0.0.0) や、サポートしていないIPアドレスクラス(例えば クラスE)を 持っているデータグラムの数も含む。IPゲートウェイでない エンティティ、つまりデータグラムをフォワードしない エンティティでは、宛先アドレスがローカルのアドレスではない 為に破棄されたデータグラムの数を含む。 ::= { ip 5 } ipForwDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input datagrams for which this entity was not their final IP destination, as a result of which an attempt was made to find a route to forward them to that final destination. In entities which do not act as IP Gateways, this counter will include only those packets which were Source-Routed via this entity, and the Source- Route option processing was successful." このエンティティが最終のIP宛先ではない受信データグラムの数。 データグラムを最終の宛先に送る為、経路を探すことによって このエンティティが最終のIP宛先ではないことが分かる。 IPゲートウェイとして動作しないエンティティでは、この カウンタは、このエンティティ経由のソースルートのパケットで ソースルートオプションの処理が正常終了したものの数だけを 含む。 ::= { ip 6 } ipInUnknownProtos OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 27] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally-addressed datagrams received successfully but discarded because of an unknown or unsupported protocol." 受信は成功したが、未知もしくはサポートされていない プロトコルの為に捨てられたローカルアドレスのデータグラム の数。 ::= { ip 7 } ipInDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of input IP datagrams for which no problems were encountered to prevent their continued processing, but which were discarded (e.g., for lack of buffer space). Note that this counter does not include any datagrams discarded while awaiting re-assembly." 以後の処理を続けるのに問題はないが、捨てられたIPデータ グラム(例えば、バッファスペース不足)の数。 データグラムの組み立て中に捨てられたデータグラムの数は 含まない事に注意されたし。 ::= { ip 8 } ipInDelivers OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of input datagrams successfully delivered to IP user-protocols (including ICMP)." IPのユーザプロトコル(ICMPも含む)へ配送が成功した 受信データグラムの総数。 ::= { ip 9 } ipOutRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of IP datagrams which local IP user-protocols (including ICMP) supplied to IP in requests for transmission. Note that this counter does not include any datagrams counted in ipForwDatagrams." ローカルのIPのユーザプロトコル(ICMPも含む)から、送信する ために、IPに渡されたIPデータグラムの総数。この値には ipForwDatagramsでカウントされたデータグラムの数はカウント されない事に注意されたし。 ::= { ip 10 } ipOutDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of output IP datagrams for which no 送信するのに問題はないが SNMP Working Group [Page 28] RFC 1213 MIB-II March 1991 problem was encountered to prevent their transmission to their destination, but which were discarded (e.g., for lack of buffer space). Note that this counter would include datagrams counted in ipForwDatagrams if any such packets met this (discretionary) discard criterion." 捨てられた(例えば、バッファスペース不足)送信IPデータグラム の数。このカウンタが ipForwDatagrams でカウントされた データグラムの中で、このように捨てられたものもカウントして いる事に注意。 ::= { ip 11 } ipOutNoRoutes OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams discarded because no route could be found to transmit them to their destination. Note that this counter includes any packets counted in ipForwDatagrams which meet this `no-route' criterion. Note that this includes any datagarms which a host cannot route because all of its default gateways are down." 宛先に転送する為の経路が判明しなかった為に廃棄された IPデータグラムの数。ipForwDatagramsでカウントされていて "no-route"規準に当てはまるパケットもカウントされる事に注意。 全てのデフォルトゲートウェイがダウンしている為にホストが ルーティング出来なかったデータグラムも含む事に注意。 ::= { ip 12 } ipReasmTimeout OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum number of seconds which received fragments are held while they are awaiting reassembly at this entity." このエンティティで、受け取ったデータグラムを組み立てる ために、フラグメントを保持する最大の秒数。 ::= { ip 13 } ipReasmReqds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP fragments received which needed to be reassembled at this entity." 受け取ったIPフラグメントの中で、このエンティティで 再組み立てが必要なものの数。 ::= { ip 14 } ipReasmOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams successfully re- assembled." 再組み立てに成功したIPデータグラムの数。 SNMP Working Group [Page 29] RFC 1213 MIB-II March 1991 ::= { ip 15 } ipReasmFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of failures detected by the IP re- assembly algorithm (for whatever reason: timed out, errors, etc). Note that this is not necessarily a count of discarded IP fragments since some algorithms (notably the algorithm in RFC 815) can lose track of the number of fragments by combining them as they are received." IP再組み立ての過程で検出された不具合(例えば、タイムアウト、 エラーなど)の数。このカウンタの値は捨てられたIPフラグ メントの数である必要はない。なぜなら受け取ったフラグメント を結合し、フラグメントの数が分からなくなっても良い アルゴリズムもある為である。(RFC815に記してある) ::= { ip 16 } ipFragOKs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams that have been successfully fragmented at this entity." このエンティティでフラグメント化に成功した IPデータグラムの数。 ::= { ip 17 } ipFragFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagrams that have been discarded because they needed to be fragmented at this entity but could not be, e.g., because their Don't Fragment flag was set." このエンティティでフラグメント化する必要があったのに フラグメント化できなくて、捨てられた IPデータグラムの数。 例えば、IPデータグラムの"Don'tFragment"フラグがセット されていた場合などがそう。 ::= { ip 18 } ipFragCreates OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of IP datagram fragments that have been generated as a result of fragmentation at this entity." このエンティティでフラグメント化した結果 生成されたIPデータグラムフラグメントの数。 ::= { ip 19 } SNMP Working Group [Page 30] RFC 1213 MIB-II March 1991 -- the IP address table -- IPアドレステーブル -- The IP address table contains this entity's IP addressing -- information. -- IPアドレス・テーブルは該当エンティティのIPアドレス情報を含む。 ipAddrTable OBJECT-TYPE SYNTAX SEQUENCE OF IpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table of addressing information relevant to this entity's IP addresses." このエンティティのIPアドレスに関連するアドレス情報テーブル。 ::= { ip 20 } ipAddrEntry OBJECT-TYPE SYNTAX IpAddrEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The addressing information for one of this entity's IP addresses." このエンティティの各IPAddressに関するアドレス情報。 INDEX { ipAdEntAddr } ::= { ipAddrTable 1 } IpAddrEntry ::= SEQUENCE { ipAdEntAddr IpAddress, ipAdEntIfIndex INTEGER, ipAdEntNetMask IpAddress, ipAdEntBcastAddr INTEGER, ipAdEntReasmMaxSize INTEGER (0..65535) } ipAdEntAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The IP address to which this entry's addressing information pertains." このエントリのアドレス情報に関係するIPアドレス。 ::= { ipAddrEntry 1 } SNMP Working Group [Page 31] RFC 1213 MIB-II March 1991 ipAdEntIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The index value which uniquely identifies the interface to which this entry is applicable. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." このエントリが適用できるインタフェースを一意に識別する indexの値。この値で識別されるインタフェースとifIndexの値で 識別されるインタフェースは同じ。 ::= { ipAddrEntry 2 } ipAdEntNetMask OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The subnet mask associated with the IP address of this entry. The value of the mask is an IP address with all the network bits set to 1 and all the hosts bits set to 0." このエントリのIPアドレスに対応しているサブネットマスク。 このマスクは、すべてのネットワークビットを1、ホストビット を0にしたIPアドレス。 ::= { ipAddrEntry 3 } ipAdEntBcastAddr OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The value of the least-significant bit in the IP broadcast address used for sending datagrams on the (logical) interface associated with the IP address of this entry. For example, when the Internet standard all-ones broadcast address is used, the value will be 1. This value applies to both the subnet and network broadcasts addresses used by the entity on this (logical) interface." このエンティティのIPアドレスに関連した論理インタフェースに データグラムを送出するのに使われるIPブロードキャスト アドレスのLSBの値。例えば、Internet標準の、全てのビットが １のブロードキャストアドレスを使用する場合は、この値は １になる。この値はこの論理インタフェースを持つエンティティ によって使われるサブネットやネットワークのブロードキャスト アドレスに適用される。 ::= { ipAddrEntry 4 } ipAdEntReasmMaxSize OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The size of the largest IP datagram which this entity can re-assemble from incoming IP fragmented datagrams received on this interface." このインタフェースで受信したIPフラグメントデータグラムから このエンティティが再編成することのできる最も大きなIPデータ グラムのサイズ。 ::= { ipAddrEntry 5 } SNMP Working Group [Page 32] RFC 1213 MIB-II March 1991 -- the IP routing table -- IPルーティングテーブル。 -- The IP routing table contains an entry for each route -- presently known to this entity. -- IPルーティングテーブルはやがてこのエンティティに知られている -- 各ルートのためのエントリーを含んでいる。 ipRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's IP Routing table." このエンティティのIPルーティングテーブル。 ::= { ip 21 } ipRouteEntry OBJECT-TYPE SYNTAX IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A route to a particular destination." 宛先別の経路情報。 INDEX { ipRouteDest } ::= { ipRouteTable 1 } IpRouteEntry ::= SEQUENCE { ipRouteDest IpAddress, ipRouteIfIndex INTEGER, ipRouteMetric1 INTEGER, ipRouteMetric2 INTEGER, ipRouteMetric3 INTEGER, ipRouteMetric4 INTEGER, ipRouteNextHop IpAddress, ipRouteType INTEGER, ipRouteProto INTEGER, ipRouteAge INTEGER, ipRouteMask IpAddress, ipRouteMetric5 INTEGER, SNMP Working Group [Page 33] RFC 1213 MIB-II March 1991 ipRouteInfo OBJECT IDENTIFIER } ipRouteDest OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The destination IP address of this route. An entry with a value of 0.0.0.0 is considered a default route. Multiple routes to a single destination can appear in the table, but access to such multiple entries is dependent on the table- access mechanisms defined by the network management protocol in use." この経路の宛先IPアドレス。 0.0.0.0というアドレスは デフォルトルートとみなされる。一つの宛先に対して複数の経路 がテーブル内にあることもある。しかし、そのような複数の エントリーに対するアクセスは、使用しているネットワーク 管理プロトコルのテーブルアクセス機能に依存する。 ::= { ipRouteEntry 1 } ipRouteIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The index value which uniquely identifies the local interface through which the next hop of this route should be reached. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." この経路で次にホップするのに通過するローカルインタフェース を一意に識別するindex値。この値で識別されるインタフェース とifIndexの値で識別されるインタフェースは同じ。 ::= { ipRouteEntry 2 } ipRouteMetric1 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The primary routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." ipRouteMetric1はこの経路の最初のメトリック。このメトリック の意味はこの経路のipRouteProtoで表しているルーティング プロトコルに従って決められる。このメトリックが使用されない 場合は、値は-1に設定される。 ::= { ipRouteEntry 3 } ipRouteMetric2 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION SNMP Working Group [Page 34] RFC 1213 MIB-II March 1991 "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." この経路のメトリックとしてipRouteMetric1の次に採用される もの。このメトリックの意味はこの経路のipRouteProtoで 表しているルーティングプロトコルに従って決められる。 このメトリックが使用されない場合は、値は-1に設定される。 ::= { ipRouteEntry 4 } ipRouteMetric3 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." この経路のメトリックとしてipRouteMetric2の次に採用される もの。このメトリックの意味はこの経路のipRouteProtoで 表しているルーティングプロトコルに従って決められる。 このメトリックが使用されない場合は、値は-1に設定される。 ::= { ipRouteEntry 5 } ipRouteMetric4 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." この経路のメトリックとしてipRouteMetric3の次に採用される もの。このメトリックの意味はこの経路のipRouteProtoで 表しているルーティングプロトコルに従って決められる。 このメトリックが使用されない場合は、値は-1に設定される。 ::= { ipRouteEntry 6 } ipRouteNextHop OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IP address of the next hop of this route. (In the case of a route bound to an interface which is realized via a broadcast media, the value of this field is the agent's IP address on that interface.)" このルートで次にホップするインタフェースのIPアドレス。 ブロードキャストメディアを通ってインタフェースへバウンド する場合、この値は、そのインタフェース上のエージェントの IPアドレスになる。 ::= { ipRouteEntry 7 } ipRouteType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated route SNMP Working Group [Page 35] RFC 1213 MIB-II March 1991 -- route to directly direct(3), -- connected (sub-)network -- route to a non-local indirect(4) -- host/network/sub-network } ACCESS read-write STATUS mandatory DESCRIPTION "The type of route. Note that the values direct(3) and indirect(4) refer to the notion of direct and indirect routing in the IP architecture. ルートのタイプ。direct(3)とindirect(4)は IPアーキテクチャーの直接ルーティングや間接ルーティング。 Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipRouteTable object. That is, it effectively dissasociates the destination identified with said entry from the route identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipRouteType object." この値をinvalid(2)に設定すると、ipRouteTableの関係する エントリが無効になる。すなわち、このエントリの経路から 宛先を切り離すことになる。エージェントがテーブルから無効 になったエントリを除去するかどうかは実装上の問題。 従い、管理ステーションは、エージェントから現在は使われて いないエントリに関する表形式の情報が送られて来ても、それ を受け取る用意をしておかなくてはならない。 ::= { ipRouteEntry 8 } ipRouteProto OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following -- non-protocol information, -- e.g., manually configured local(2), -- entries -- set via a network netmgmt(3), -- management protocol -- obtained via ICMP, icmp(4), -- e.g., Redirect -- the remaining values are -- all gateway routing -- protocols egp(5), ggp(6), SNMP Working Group [Page 36] RFC 1213 MIB-II March 1991 hello(7), rip(8), is-is(9), es-is(10), ciscoIgrp(11), bbnSpfIgp(12), ospf(13), bgp(14) } ACCESS read-only STATUS mandatory DESCRIPTION "The routing mechanism via which this route was learned. Inclusion of values for gateway routing protocols is not intended to imply that hosts should support those protocols." どのように経路を決定するかのルーティングングメカニズム。 ゲートウェイルーティングプロトコルに対応する値が有るが それは、ホストがそれらのプロトコルをサポートするという ことを意味している訳ではない。 ::= { ipRouteEntry 9 } ipRouteAge OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The number of seconds since this route was last updated or otherwise determined to be correct. Note that no semantics of `too old' can be implied except through knowledge of the routing protocol by which the route was learned." この経路が最後に更新されたか、または他の方法で正しいと決め られてからの秒数。経路を決定するのに使用したルーティング プロトコルによる以外は、"too old"の意味は規定されていない。 ::= { ipRouteEntry 10 } ipRouteMask OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "Indicate the mask to be logical-ANDed with the destination address before being compared to the value in the ipRouteDest field. For those systems that do not support arbitrary subnet masks, an agent constructs the value of the ipRouteMask by determining whether the value of the correspondent ipRouteDest field belong to a class-A, B, or C network, and then using one of: ipRouteDestの値と比較をする前に、宛先のアドレスと論理積 をとるマスク。任意のサブネットマスクをサポートしていない システムのために、エージェントは、対応するipRouteDestの 値がクラスA、B、Cのネットワークに属するかどうかを決定して ipRouteMaskの値を作る。その時、次の値を使用する。 mask network 255.0.0.0 class-A 255.255.0.0 class-B 255.255.255.0 class-C SNMP Working Group [Page 37] RFC 1213 MIB-II March 1991 If the value of the ipRouteDest is 0.0.0.0 (a default route), then the mask value is also 0.0.0.0. It should be noted that all IP routing subsystems implicitly use this mechanism." もしipRouteDestの値が0.0.0.0であれば、マスク値もまた 0.0.0.0となる。すべてのIPルーティングサブシステムが 必然的にこのメカニズムを使用する事に注意すべきである。 ::= { ipRouteEntry 11 } ipRouteMetric5 OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "An alternate routing metric for this route. The semantics of this metric are determined by the routing-protocol specified in the route's ipRouteProto value. If this metric is not used, its value should be set to -1." この経路のメトリックとしてipRouteMetric4の次に採用される もの。このメトリックの意味はこの経路のipRouteProtoで 表しているルーティングプロトコルに従って決められる。 このメトリックが使用されない場合は、値は-1に設定される。 ::= { ipRouteEntry 12 } ipRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "A reference to MIB definitions specific to the particular routing protocol which is responsible for this route, as determined by the value specified in the route's ipRouteProto value. If this information is not present, its value should be set to the OBJECT IDENTIFIER { 0 0 }, which is a syntatically valid object identifier, and any conformant implementation of ASN.1 and BER must be able to generate and recognize this value." 経路は、ipRouteProtoの値に有るルーティングメカニズムに よって決められる。このような経路を決定するのに使った特別な ルーティングプロトコルについて記述した固有のMIB定義を示す。 この情報が無い場合、値はOBJECTIDENTIFIER{ 0 0 }に設定 される。この値は、構文上正しい値。ASN.1やBERの実装では この値を生成したり認識したりが出来なくてはならない。 ::= { ipRouteEntry 13 } -- the IP Address Translation table -- IPアドレストランスレーションテーブル -- The IP address translation table contain the IpAddress to -- `physical' address equivalences. Some interfaces do not -- use translation tables for determining address -- equivalences (e.g., DDN-X.25 has an algorithmic method); -- if all interfaces are of this type, then the Address -- Translation table is empty, i.e., has zero entries. -- IPアドレス変換テーブルは'物理的な'アドレス相当値に対するIpAddressを -- 含んでいる。 いくつかのインタフェースはアドレス相当値を決定する為に -- 変換テーブルを使用しない。(例えば、DDN-X.25には、アルゴリズムメソッ -- ドがある)このようなタイプの場合は、Address Translationテーブルは空 -- であり、エントリの数はゼロとなる。 ipNetToMediaTable OBJECT-TYPE SYNTAX SEQUENCE OF IpNetToMediaEntry ACCESS not-accessible STATUS mandatory SNMP Working Group [Page 38] RFC 1213 MIB-II March 1991 DESCRIPTION "The IP Address Translation table used for mapping from IP addresses to physical addresses." IPアドレスから物理アドレスへマッピングの為の IPAddressTranslationテーブル。 ::= { ip 22 } ipNetToMediaEntry OBJECT-TYPE SYNTAX IpNetToMediaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Each entry contains one IpAddress to `physical' address equivalence." 物理アドレスに変換されるIPアドレスを一つ含むエントリ。 INDEX { ipNetToMediaIfIndex, ipNetToMediaNetAddress } ::= { ipNetToMediaTable 1 } IpNetToMediaEntry ::= SEQUENCE { ipNetToMediaIfIndex INTEGER, ipNetToMediaPhysAddress PhysAddress, ipNetToMediaNetAddress IpAddress, ipNetToMediaType INTEGER } ipNetToMediaIfIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-write STATUS mandatory DESCRIPTION "The interface on which this entry's equivalence is effective. The interface identified by a particular value of this index is the same interface as identified by the same value of ifIndex." このエントリに該当する有効なインタフェースの番号。 この値で識別されるインタフェースとifIndexの値で 識別されるインタフェースは同じ。 ::= { ipNetToMediaEntry 1 } ipNetToMediaPhysAddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-write STATUS mandatory DESCRIPTION "The media-dependent `physical' address." メディアに依存した物理アドレス。 ::= { ipNetToMediaEntry 2 } SNMP Working Group [Page 39] RFC 1213 MIB-II March 1991 ipNetToMediaNetAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IpAddress corresponding to the media- dependent `physical' address." メディアに依存した物理アドレスに対応するIPアドレス。 ::= { ipNetToMediaEntry 3 } ipNetToMediaType OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following invalid(2), -- an invalidated mapping dynamic(3), static(4) } ACCESS read-write STATUS mandatory DESCRIPTION "The type of mapping. マッピングタイプ。 Setting this object to the value invalid(2) has the effect of invalidating the corresponding entry in the ipNetToMediaTable. That is, it effectively dissasociates the interface identified with said entry from the mapping identified with said entry. It is an implementation-specific matter as to whether the agent removes an invalidated entry from the table. Accordingly, management stations must be prepared to receive tabular information from agents that corresponds to entries not currently in use. Proper interpretation of such entries requires examination of the relevant ipNetToMediaType object." このオブジェクトにinvalid(2)を設定すると、 ipNetToMediaTableの中の対応するエントリが無効になる。 即ち、このエントリの変換から、このエントリに対応する インタフェースを切り離す。エージェントが、テーブルから 無効になったエントリを削除するかどうかは実装上の問題。 従い、管理ステーションは、エージェントから、現在使用されて いないエントリのテーブル形式の情報を受け取る用意が出来て いなければならない。そのようなエントリの情報を正確に解釈 するには、対応するipNetToMediaTypeの値を調べる必要がある。 ::= { ipNetToMediaEntry 4 } -- additional IP objects -- 追加 IP オブジェクト ipRoutingDiscards OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of routing entries which were chosen to be discarded even though they are valid. One possible reason for discarding such an entry could be to free-up buffer space for other routing 有効だが放棄されたルーティングエントリーの数。 理由としては、他のルーティングエントリのための バッファスペースが足りなくなった。 SNMP Working Group [Page 40] RFC 1213 MIB-II March 1991 entries." ::= { ip 23 } -- the ICMP group -- ICMPグループ -- Implementation of the ICMP group is mandatory for all -- systems. -- ICMP グループの実装はすべてのシステムに必須。 icmpInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ICMP messages which the entity received. Note that this counter includes all those counted by icmpInErrors." エンティティが受け取ったICMPメッセージの総数。 これはicmpInErrorsでカウントされるものも含む。 ::= { icmp 1 } icmpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP messages which the entity received but determined as having ICMP-specific errors (bad ICMP checksums, bad length, etc.)." エンティティが受け取った、ICMPエラーのあるICMPメッセージ の数。(ICMPチェックサムエラーやレングスエラーなど) ::= { icmp 2 } icmpInDestUnreachs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Destination Unreachable messages received." 受信したICMPDestinationUnreachableメッセージの数。 ::= { icmp 3 } icmpInTimeExcds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Time Exceeded messages received." 受信したICMPTimeExceededメッセージの数。 ::= { icmp 4 } SNMP Working Group [Page 41] RFC 1213 MIB-II March 1991 icmpInParmProbs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Parameter Problem messages received." 受信したICMPParameterProblemメッセージの数。 ::= { icmp 5 } icmpInSrcQuenchs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Source Quench messages received." 受信したICMPSourceQuenchメッセージの数。 ::= { icmp 6 } icmpInRedirects OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Redirect messages received." 受信したICMPRedirectメッセージの数。 ::= { icmp 7 } icmpInEchos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo (request) messages received." 受信したICMPEcho(request)メッセージの数。 ::= { icmp 8 } icmpInEchoReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo Reply messages received." 受信したICMPEchoReplyメッセージの数。 ::= { icmp 9 } icmpInTimestamps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION SNMP Working Group [Page 42] RFC 1213 MIB-II March 1991 "The number of ICMP Timestamp (request) messages received." 受信したICMPTimeStampメッセージの数。 ::= { icmp 10 } icmpInTimestampReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp Reply messages received." 受信したICMPTimeStampReplyメッセージの数。 ::= { icmp 11 } icmpInAddrMasks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Request messages received." 受信したICMPAddressMaskRequestメッセージの数。 ::= { icmp 12 } icmpInAddrMaskReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Reply messages received." 受信したICMPAddressMaskReplyメッセージの数。 ::= { icmp 13 } icmpOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ICMP messages which this entity attempted to send. Note that this counter includes all those counted by icmpOutErrors." エンティティが送信したICMPメッセージの総数。 これはicmpOutErrorsでカウントされるものも含む。 ::= { icmp 14 } icmpOutErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP messages which this entity did not send due to problems discovered within ICMP バッファーが足りないというようなICMPで発見された問題 の為にエンティティが送出しなかったICMPメッセージの数。 SNMP Working Group [Page 43] RFC 1213 MIB-II March 1991 such as a lack of buffers. This value should not include errors discovered outside the ICMP layer such as the inability of IP to route the resultant datagram. In some implementations there may be no types of error which contribute to this counter's value." IPがデータグラムをルーティングできないという様な、ICMPの 外の層で発見されたエラーは、この値には含まれない。 ::= { icmp 15 } icmpOutDestUnreachs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Destination Unreachable messages sent." 送信したICMPDestinationUnreachableメッセージの数。 ::= { icmp 16 } icmpOutTimeExcds OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Time Exceeded messages sent." 送信したICMPTimeExceededメッセージの数。 ::= { icmp 17 } icmpOutParmProbs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Parameter Problem messages sent." 送信したICMPParameterProblemメッセージの数。 ::= { icmp 18 } icmpOutSrcQuenchs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Source Quench messages sent." 送信したICMPSourceQuenchメッセージの数。 ::= { icmp 19 } icmpOutRedirects OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Redirect messages sent. For a 送信したICMPRedirectメッセージの数。 SNMP Working Group [Page 44] RFC 1213 MIB-II March 1991 host, this object will always be zero, since hosts do not send redirects." ホストはredirectsメッセージを出せないので このオブジェクトの値は常に0となる。 ::= { icmp 20 } icmpOutEchos OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo (request) messages sent." 送信したICMPEcho(request)メッセージの数。 ::= { icmp 21 } icmpOutEchoReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Echo Reply messages sent." 送信したICMPEchoReplyメッセージの数。 ::= { icmp 22 } icmpOutTimestamps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp (request) messages sent." 送信したicmpOutTimestampsメッセージの数。 ::= { icmp 23 } icmpOutTimestampReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Timestamp Reply messages sent." 送信したICMPTimeStampReplyメッセージの数。 ::= { icmp 24 } icmpOutAddrMasks OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Request messages sent." 送信したicmpOutAddrMasksメッセージの数。 ::= { icmp 25 } SNMP Working Group [Page 45] RFC 1213 MIB-II March 1991 icmpOutAddrMaskReps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of ICMP Address Mask Reply messages sent." 送信したicmpOutAddrMaskRepsメッセージの数。 ::= { icmp 26 } -- the TCP group -- TCPグループ -- Implementation of the TCP group is mandatory for all -- systems that implement the TCP. -- TCP グループの実装は、TCPを実装する全てのシステムに必須。 -- Note that instances of object types that represent -- information about a particular TCP connection are -- transient; they persist only as long as the connection -- in question. -- 特定のTCP接続に関する情報を表すオブジェクトタイプのインスタンスは -- 一時的であるのに注意。それらは当のコネクションが張られている間だけ -- 存在する。 tcpRtoAlgorithm OBJECT-TYPE SYNTAX INTEGER { other(1), -- none of the following constant(2), -- a constant rto rsre(3), -- MIL-STD-1778, Appendix B vanj(4) -- Van Jacobson's algorithm [10] } ACCESS read-only STATUS mandatory DESCRIPTION "The algorithm used to determine the timeout value used for retransmitting unacknowledged octets." 再送したパケットの応答が帰ってこない間のタイムアウト値を 決定するために使われるアルゴリスム。 ::= { tcp 1 } tcpRtoMin OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The minimum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the LBOUND quantity described in RFC 793." TCPの実装によって許されている最小の再送タイムアウト値を ミリ秒単位で表している。このタイプのオブジェクトのより詳細 な意味は、再送タイムアウトを決定するのに使われているアルゴ リズムによる。特に、タイムアウトアルゴリズムがrsreの場合は このタイプのオブジェクトは、RFC793に述べてあるLBOUND 量の ことを意味している。 SNMP Working Group [Page 46] RFC 1213 MIB-II March 1991 ::= { tcp 2 } tcpRtoMax OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The maximum value permitted by a TCP implementation for the retransmission timeout, measured in milliseconds. More refined semantics for objects of this type depend upon the algorithm used to determine the retransmission timeout. In particular, when the timeout algorithm is rsre(3), an object of this type has the semantics of the UBOUND quantity described in RFC 793." TCPの実装によって許されている最大の再送タイムアウト値を ミリ秒で表している。このタイプのオブジェクトのより詳細な 意味は、再送タイムアウトを決定するのに使われているアルゴ リズムによる。 特に、タイムアウトアルゴリズムがrsreの場合 は、このタイプのオブジェクトは、RFC793に述べてあるUBOUND 量のことを意味している。 ::= { tcp 3 } tcpMaxConn OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The limit on the total number of TCP connections the entity can support. In entities where the maximum number of connections is dynamic, this object should contain the value -1." エンティティがサポート可能な最大のTCPコネクションの 数を表す。最大コネクション数が変化するエンティティでは この値は-1となる。 ::= { tcp 4 } tcpActiveOpens OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the SYN-SENT state from the CLOSED state." TCPコネクションがCLOSE状態からSYN-SENT状態に 直接状態遷移した回数。 ::= { tcp 5 } tcpPassiveOpens OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the SYN-RCVD state from the LISTEN state." TCPコネクションがLISTEN状態からSYN-RCVD状態に 直接状態遷移した回数。 ::= { tcp 6 } SNMP Working Group [Page 47] RFC 1213 MIB-II March 1991 tcpAttemptFails OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the CLOSED state from either the SYN-SENT state or the SYN-RCVD state, plus the number of times TCP connections have made a direct transition to the LISTEN state from the SYN-RCVD state." TCPコネクションがSYN-SENT状態かまたはSYN-RCVD状態から CLOSED状態へ直接状態遷移した回数と、SYN-RCVD状態から LISTEN状態へ直接状態遷移した回数との和を表す。 TCPコネクションの確立中にRST(Reset)ビットがセットされた "ConnectionRefused"パケットが相手側から返ってきたとき この状態遷移が起こり得る。 ::= { tcp 7 } tcpEstabResets OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of times TCP connections have made a direct transition to the CLOSED state from either the ESTABLISHED state or the CLOSE-WAIT state." TCPコネクションがESTABLISHED状態かまたはCLOSE-WAIT状態 からCLOSED状態へ直接状態遷移した回数を表す。上位の プロトコルから中止するよう依頼されたとき、RSTビットが セットされたセグメントが送られ、この状態遷移が起こり得る。 ::= { tcp 8 } tcpCurrEstab OBJECT-TYPE SYNTAX Gauge ACCESS read-only STATUS mandatory DESCRIPTION "The number of TCP connections for which the current state is either ESTABLISHED or CLOSE- WAIT." 現在のコネクションの状態がESTABLISHED状態かまたは CLOSE-WAIT状態であるTCPコネクションの数。 ::= { tcp 9 } tcpInSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of segments received, including those received in error. This count includes segments received on currently established connections." エラーであるものも含めて受け取ったセグメント数。現在確立 されているコネクションで受け取ったセグメントを含む。 ::= { tcp 10 } tcpOutSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 48] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of segments sent, including those on current connections but excluding those containing only retransmitted octets." 送信したセグメントの数。このコネクション上のセグメントは 含むが、再送データのみのセグメントは含まない。 ::= { tcp 11 } tcpRetransSegs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of segments retransmitted - that is, the number of TCP segments transmitted containing one or more previously transmitted octets." 再送されたセグメントの数。即ち、送信されたセグメントの うち、以前１度以上送出されたことのあるバイトを含んだ セグメントの個数。 ::= { tcp 12 } -- the TCP Connection table -- TCPコネクションテーブル -- The TCP connection table contains information about this -- entity's existing TCP connections. -- TCPコネクションテーブルはこのエンティティの既存のTCPコネクションに -- 関する情報を持っている。 tcpConnTable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing TCP connection-specific information." TCPコネクションに関する情報を持ったテーブル。 ::= { tcp 13 } tcpConnEntry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." 特定の現在のTCPコネクションの情報。コネクションがCLOSE 状態に遷移すると、すぐに値は削除されるので、このタイプの オブジェクトは一時的なものといえる。 INDEX { tcpConnLocalAddress, tcpConnLocalPort, tcpConnRemAddress, tcpConnRemPort } ::= { tcpConnTable 1 } SNMP Working Group [Page 49] RFC 1213 MIB-II March 1991 TcpConnEntry ::= SEQUENCE { tcpConnState INTEGER, tcpConnLocalAddress IpAddress, tcpConnLocalPort INTEGER (0..65535), tcpConnRemAddress IpAddress, tcpConnRemPort INTEGER (0..65535) } tcpConnState OBJECT-TYPE SYNTAX INTEGER { closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11), deleteTCB(12) } ACCESS read-write STATUS mandatory DESCRIPTION "The state of this TCP connection. TCPコネクションの状態 The only value which may be set by a management station is deleteTCB(12). Accordingly, it is appropriate for an agent to return a `badValue' response if a management station attempts to set this object to any other value. 管理ステーションがセットする値は主にdeleteTCB(12)。 従い、もし管理ステーションがこのオブジェクトに他の値を セットしようとしたら、エージェントは "badValue"レスポンス を返すのが妥当。 If a management station sets this object to the value deleteTCB(12), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. もし管理ステーションがこの値にdeleteTCB(12)をセットする ならば、管理ノードの該当するコネクションの TCB(RFC793に 定義されている)を削除して、すぐにコネクションを終了する。 As an implementation-specific option, a RST 実装上のオプションとして SNMP Working Group [Page 50] RFC 1213 MIB-II March 1991 segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)." 管理ノードからRSTセグメントがTCPコネクションの他の エンドポイントに送られるかも知れない。 ::= { tcpConnEntry 1 } tcpConnLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IP address for this TCP connection. In the case of a connection in the listen state which is willing to accept connections for any IP interface associated with the node, the value 0.0.0.0 is used." TCPコネクションのローカルIPアドレス。ノードに関連する どんなIPインタフェースに対してもコネクションを受け取る listen状態のコネクションの場合、この値は0.0.0.0を使用する。 ::= { tcpConnEntry 2 } tcpConnLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this TCP connection." TCPコネクションのローカルポートの番号。 ::= { tcpConnEntry 3 } tcpConnRemAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The remote IP address for this TCP connection." TCPコネクションのリモートのIPアドレス。 ::= { tcpConnEntry 4 } tcpConnRemPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The remote port number for this TCP connection." TCPコネクションのリモートのポート番号。 ::= { tcpConnEntry 5 } -- additional TCP objects -- 追加されたTCPオブジェクト tcpInErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 51] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of segments received in error (e.g., bad TCP checksums)." エラーとして受け取ったセグメントの総数。 （例えば，チェックサムエラー） ::= { tcp 14 } tcpOutRsts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of TCP segments sent containing the RST flag." RSTフラグを含んで送信したTCPセグメントの数。 ::= { tcp 15 } -- the UDP group -- UDPグループ -- Implementation of the UDP group is mandatory for all -- systems which implement the UDP. -- UDP グループの実装は、UDPを実装している全てのシステムに必須。 udpInDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of UDP datagrams delivered to UDP users." UDPのユーザに送られたUDPデータグラムの総数。 ::= { udp 1 } udpNoPorts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of received UDP datagrams for which there was no application at the destination port." 受信したが宛先ポートでアプリケーションが 起動されていなかったUDPデータグラムの総数。 ::= { udp 2 } udpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port." 受信したUDPデータグラムのうち、宛先ポートで アプリケーションが起動されていないという理由以外で上位の プロトコルに渡すことができなかったデータグラムの数。 ::= { udp 3 } SNMP Working Group [Page 52] RFC 1213 MIB-II March 1991 udpOutDatagrams OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of UDP datagrams sent from this entity." このエンティティから送信したUDPデータグラムの数。 ::= { udp 4 } -- the UDP Listener table -- UDPリスナーテーブル -- The UDP listener table contains information about this -- entity's UDP end-points on which a local application is -- currently accepting datagrams. -- UDPリスナーテーブルはローカルのアプリケーションが現在データグラムを -- 受け入れているこのエンティティのUDPエンドポイントに関する情報を持つ。 udpTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing UDP listener information." UDPlistener情報を含むテーブル。 ::= { udp 5 } udpEntry OBJECT-TYPE SYNTAX UdpEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current UDP listener." 現在の特定のUDPlistenerの情報。 INDEX { udpLocalAddress, udpLocalPort } ::= { udpTable 1 } UdpEntry ::= SEQUENCE { udpLocalAddress IpAddress, udpLocalPort INTEGER (0..65535) } udpLocalAddress OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The local IP address for this UDP listener. In このUDPlistnerに対するローカルなIPアドレス。 SNMP Working Group [Page 53] RFC 1213 MIB-II March 1991 the case of a UDP listener which is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used." そのノードに結合したどんなIPインタフェースに対してもデータ グラムを受け取るUDPlistnerの場合は 0.0.0.0 が使われる。 ::= { udpEntry 1 } udpLocalPort OBJECT-TYPE SYNTAX INTEGER (0..65535) ACCESS read-only STATUS mandatory DESCRIPTION "The local port number for this UDP listener." このUDPlistnerに対するローカルポートの数。 ::= { udpEntry 2 } -- the EGP group -- EGP グループ -- Implementation of the EGP group is mandatory for all -- systems which implement the EGP. -- EGPグループの実装は、EGPを実装している全てのシステムに必須。 egpInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received without error." エラーなしで受信したEGPメッセージの数。 ::= { egp 1 } egpInErrors OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received that proved to be in error." エラーであると判明した受信EGPメッセージ数。 ::= { egp 2 } egpOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of locally generated EGP messages." ローカルに生成されたEGPメッセージの総数。 ::= { egp 3 } egpOutErrors OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 54] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages not sent due to resource limitations within an EGP entity." ローカルに生成されたが、EGPエンティティの資源の不足の為に 送信できなかったEGPメッセージの数。 ::= { egp 4 } -- the EGP Neighbor table -- EGP ネイバーグループ -- The EGP neighbor table contains information about this -- entity's EGP neighbors. -- EGPネイバーテーブルはこのエンティティのEGP周りに関する情報を持つ。 egpNeighTable OBJECT-TYPE SYNTAX SEQUENCE OF EgpNeighEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The EGP neighbor table." Neighborテーブル。 ::= { egp 5 } egpNeighEntry OBJECT-TYPE SYNTAX EgpNeighEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about this entity's relationship with a particular EGP neighbor." 特定のEGPneighborとこのエンティティとの関係についての情報。 INDEX { egpNeighAddr } ::= { egpNeighTable 1 } EgpNeighEntry ::= SEQUENCE { egpNeighState INTEGER, egpNeighAddr IpAddress, egpNeighAs INTEGER, egpNeighInMsgs Counter, egpNeighInErrs Counter, egpNeighOutMsgs Counter, egpNeighOutErrs Counter, SNMP Working Group [Page 55] RFC 1213 MIB-II March 1991 egpNeighInErrMsgs Counter, egpNeighOutErrMsgs Counter, egpNeighStateUps Counter, egpNeighStateDowns Counter, egpNeighIntervalHello INTEGER, egpNeighIntervalPoll INTEGER, egpNeighMode INTEGER, egpNeighEventTrigger INTEGER } egpNeighState OBJECT-TYPE SYNTAX INTEGER { idle(1), acquisition(2), down(3), up(4), cease(5) } ACCESS read-only STATUS mandatory DESCRIPTION "The EGP state of the local system with respect to this entry's EGP neighbor. Each EGP state is represented by a value that is one greater than the numerical value associated with said state in RFC 904." このエントリのEGPneighborに関する、ローカルシステムのEGP 状態。各EGP状態は、RFC904で使用している状態の数値よりも１ 大きい値で表されている。 ::= { egpNeighEntry 1 } egpNeighAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The IP address of this entry's EGP neighbor." このエントリのEGPNeighborのIPアドレス。 ::= { egpNeighEntry 2 } egpNeighAs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory SNMP Working Group [Page 56] RFC 1213 MIB-II March 1991 DESCRIPTION "The autonomous system of this EGP peer. Zero should be specified if the autonomous system number of the neighbor is not yet known." 隣接EGPの自律システム。もし隣接EGPの自律システム数が わからないならば0が記述される。 ::= { egpNeighEntry 3 } egpNeighInMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received without error from this EGP peer." 隣接EGPからのエラー無しで受信したEGPメッセージ数。 ::= { egpNeighEntry 4 } egpNeighInErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP messages received from this EGP peer that proved to be in error (e.g., bad EGP checksum)." 隣接EGPからエラーありで受信したメッセージ数。 (例えば、EGPチェックサムエラー)。 ::= { egpNeighEntry 5 } egpNeighOutMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages to this EGP peer." ローカルで生成して隣接EGPに送信したメッセージの数。 ::= { egpNeighEntry 6 } egpNeighOutErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of locally generated EGP messages not sent to this EGP peer due to resource limitations within an EGP entity." ローカルで生成しても、EGPエンティティの資源の限界の為に 隣接EGPに送信しなかったメッセージの数。 ::= { egpNeighEntry 7 } egpNeighInErrMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 57] RFC 1213 MIB-II March 1991 DESCRIPTION "The number of EGP-defined error messages received from this EGP peer." 隣接EGPからのEGP定義のエラーメッセージの数。 ::= { egpNeighEntry 8 } egpNeighOutErrMsgs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP-defined error messages sent to this EGP peer." 隣接EGPに送信したEGP定義のエラーメッセージの数。 ::= { egpNeighEntry 9 } egpNeighStateUps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP state transitions to the UP state with this EGP peer." EGPの状態が隣接EGPに対してUP状態に遷移した数。 ::= { egpNeighEntry 10 } egpNeighStateDowns OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of EGP state transitions from the UP state to any other state with this EGP peer." EGPの状態が隣接EGPに対してUP状態から他の状態に遷移した数。 ::= { egpNeighEntry 11 } egpNeighIntervalHello OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interval between EGP Hello command retransmissions (in hundredths of a second). This represents the t1 timer as defined in RFC 904." EGPハローコマンドの再送間隔(1/100秒単位)。 これはRFC904で定義してあるt1tltimerに相当する。 ::= { egpNeighEntry 12 } egpNeighIntervalPoll OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The interval between EGP poll command SNMP Working Group [Page 58] RFC 1213 MIB-II March 1991 retransmissions (in hundredths of a second). This represents the t3 timer as defined in RFC 904." EGPポーリング再送間隔(1/100秒単位)。 これはRFC904で定義してあるt3timerに相当する。 ::= { egpNeighEntry 13 } egpNeighMode OBJECT-TYPE SYNTAX INTEGER { active(1), passive(2) } ACCESS read-only STATUS mandatory DESCRIPTION "The polling mode of this EGP entity, either passive or active." EGPエンティティの、passiveかまたはactiveのどちらかの ポーリングのモード。 ::= { egpNeighEntry 14 } egpNeighEventTrigger OBJECT-TYPE SYNTAX INTEGER { start(1), stop(2) } ACCESS read-write STATUS mandatory DESCRIPTION "A control variable used to trigger operator- initiated Start and Stop events. When read, this variable always returns the most recent value that egpNeighEventTrigger was set to. If it has not been set since the last initialization of the network management subsystem on the node, it returns a value of `stop'. オペレーターが開始したStart・Stopイベントを実行するのに使 われる制御変数。この値が読まれる時は、いつも egpNeighEventTriggerに対してセットされた最新の値を返す。 When set, this variable causes a Start or Stop event on the specified neighbor, as specified on pages 8-10 of RFC 904. Briefly, a Start event causes an Idle peer to begin neighbor acquisition and a non-Idle peer to reinitiate neighbor acquisition. A stop event causes a non-Idle peer to return to the Idle state until a Start event occurs, either via egpNeighEventTrigger or otherwise." このノードのネットワーク管理サブシステムに初期化された後、 設定されなければ、stop値を返す。セットされれば、RFC904の ページ8-10に記述してあるように、該当するneighborにStartも しくはStopのイベントを引き起す。簡単に言うと、Start イベントによって、Idlepeerはneighborを獲得し始め、 non-Idlepeerは再度neighborを獲得し始める。Stopイベントでは、 non-Idlepeerは、egpNeighEventTriggerかまたはその他を通じて Startイベントが発生するまでIdle状態になる。 ::= { egpNeighEntry 15 } -- additional EGP objects -- 追加されたEGPオブジェクト egpAs OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The autonomous system number of this EGP entity." このEGPエンティティの自律システム数。 ::= { egp 6 } SNMP Working Group [Page 59] RFC 1213 MIB-II March 1991 -- the Transmission group -- トランスミッショングループ -- Based on the transmission media underlying each interface -- on a system, the corresponding portion of the Transmission -- group is mandatory for that system. -- システムで各インタフェースの基礎となるトランスミッションメディアに -- 基づいて、Transmissionグループの対応している部分はそのシステムに必 -- 須となる。 -- When Internet-standard definitions for managing -- transmission media are defined, the transmission group is -- used to provide a prefix for the names of those objects. -- 送信メディアを管理するためのインターネット標準が定義が定義される -- 場合、トランスミッショングループはそれらオブジェクトの名前のprefix -- を提供するために使用される。 -- Typically, such definitions reside in the experimental -- portion of the MIB until they are "proven", then as a -- part of the Internet standardization process, the -- definitions are accordingly elevated and a new object -- identifier, under the transmission group is defined. By -- convention, the name assigned is: -- 通常、そのような定義はMIBの実験部分に「証明される」まで存在する。 -- その後、インターネット標準化プロセスの一部として、定義はそれに -- 応じて新しいオブジェクト識別子として立ち上がり、トランスミッション -- グループの元で定義される。規約で割り当てられた名前は以下の通り。 -- -- type OBJECT IDENTIFIER ::= { transmission number } -- -- where "type" is the symbolic value used for the media in -- the ifType column of the ifTable object, and "number" is -- the actual integer value corresponding to the symbol. -- type が ifTable オブジェクトの ifType カラムのメディアで使用される -- シンボル値であり、number がシンボル値に対応する実際の整数値となる。 -- the SNMP group -- SNMPグループ -- Implementation of the SNMP group is mandatory for all -- systems which support an SNMP protocol entity. Some of -- the objects defined below will be zero-valued in those -- SNMP implementations that are optimized to support only -- those functions specific to either a management agent or -- a management station. In particular, it should be -- observed that the objects below refer to an SNMP entity, -- and there may be several SNMP entities residing on a -- managed node (e.g., if the node is hosting acting as -- a management station). -- SNMPグループの実装は、SNMPプロトコルエンティティをサポートしている -- すべてのシステムに必須。以下に定義されるオブジェクトのいくつかは -- SNMPの実装によりゼロの値を取る場合がある。これは管理エージェントと -- しての、または管理ステーションとしての、どちらかに特有の機能のみを -- サポートするようにSNMPの実装が最適化されている場合である。 -- 特に、以下に記述するオブジェクトはSNMPエンティティに関連したもので -- あり、被管理ノード上には幾つかのSNMPエンティティがあるということ -- などを理解しておくべきある。 (例えば、もしあるノードがホストとして -- 動作しているならば、管理ステーションとしての動きの事など) snmpInPkts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of Messages delivered to the SNMP entity from the transport service." トランスポートサービスからSNMPエンティティへ配送された メッセージの総数。 ::= { snmp 1 } snmpOutPkts OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 60] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages which were passed from the SNMP protocol entity to the transport service." SNMPエンティティからトランスポートサービスへ渡した SNMPメッセージの総数。 ::= { snmp 2 } snmpInBadVersions OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages which were delivered to the SNMP protocol entity and were for an unsupported SNMP version." SNMPプロトコルエンティティへ配送された未サポートの SNMPバージョンを持つSNMPメッセージの総数。 ::= { snmp 3 } snmpInBadCommunityNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages delivered to the SNMP protocol entity which used a SNMP community name not known to said entity." SNMPプロトコルエンティティへ配送された、エンティティに 未登録のSNMPコミュニティ名を使用したSNMPメッセージの総数。 ::= { snmp 4 } snmpInBadCommunityUses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Messages delivered to the SNMP protocol entity which represented an SNMP operation which was not allowed by the SNMP community named in the Message." SNMPプロトコルエンティティへ配送された、メッセージ中にSNMP コミュニティ名によって許可されていないSNMPオペレーションを 記述したSNMPメッセージの総数。 ::= { snmp 5 } snmpInASNParseErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of ASN.1 or BER errors encountered by the SNMP protocol entity when decoding received SNMP Messages." 受信したSNMPメッセージをデコード中にSNMPプロトコル エンティティによって検出したASN.1またはBERのエラー総数。 ::= { snmp 6 } SNMP Working Group [Page 61] RFC 1213 MIB-II March 1991 -- { snmp 7 } is not used -- { snmp 7 } は使わない。 snmpInTooBigs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `tooBig'." SNMPプロトコルエンティティへ配送された、エラーステータス フィールドの値がTooBigであるSNMPPDUsの総数。 ::= { snmp 8 } snmpInNoSuchNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `noSuchName'." SNMPプロトコルエンティティへ配送された、エラーステータス フィールドの値がnoSuchNameであるSNMPPDUsの総数。 ::= { snmp 9 } snmpInBadValues OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `badValue'." SNMPプロトコルエンティティへ配送された、エラーステータス フィールドの値がbadValueであるSNMPPDUsの総数。 ::= { snmp 10 } snmpInReadOnlys OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number valid SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `readOnly'. It should be noted that it is a protocol error to generate an SNMP PDU which contains the value `readOnly' in the error-status field, as such this object is provided as a means of detecting incorrect implementations of the SNMPプロトコルエンティティへ配送された、エラーステータス フィールドの値がreadOnlyな、形式的には正しいSNMPPDUsの総数。 エラーステータスフィールドにreadOnlyの値を含むSNMPPDUsを生 成することはプロトコルエラーであるということに注意すべきで ある。このオブジェクトは、そのような不正なSNMPの実装の検出 を行う手段として用意されている。 SNMP Working Group [Page 62] RFC 1213 MIB-II March 1991 SNMP." ::= { snmp 11 } snmpInGenErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were delivered to the SNMP protocol entity and for which the value of the error-status field is `genErr'." SNMPプロトコルエンティティへ配送された、エラーステータス フィールドの値がgenErrであるSNMPPDUsの総数。 ::= { snmp 12 } snmpInTotalReqVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MIB objects which have been retrieved successfully by the SNMP protocol entity as the result of receiving valid SNMP Get-Request and Get-Next PDUs." 正しいSNMPGet-RequestとGet-NextPDUsを受信した結果 SNMP プロトコルエンティティによって回復に成功した MIB オブジェクトの総数。 ::= { snmp 13 } snmpInTotalSetVars OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of MIB objects which have been altered successfully by the SNMP protocol entity as the result of receiving valid SNMP Set-Request PDUs." 正しいSNMPSet-RequestPDUsを受け取った結果、SNMPプロトコル エンティティによって変更に成功したMIBオブジェクトの総数。 ::= { snmp 14 } snmpInGetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Request PDUs which have been accepted and processed by the SNMP protocol entity." SNMPプロトコルエンティティによって受け入れられ、処理された SNMPGet-RequestPDUsの総数。 ::= { snmp 15 } snmpInGetNexts OBJECT-TYPE SYNTAX Counter SNMP Working Group [Page 63] RFC 1213 MIB-II March 1991 ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Next PDUs which have been accepted and processed by the SNMP protocol entity." SNMPプロトコルエンティティによって受け入れられ、処理された SNMPGet-NextPDUsの総数。 ::= { snmp 16 } snmpInSetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Set-Request PDUs which have been accepted and processed by the SNMP protocol entity." SNMPプロトコルエンティティによって受け入れられ、処理された SNMPSet-RequestPDUsの総数。 ::= { snmp 17 } snmpInGetResponses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Response PDUs which have been accepted and processed by the SNMP protocol entity." SNMPプロトコルエンティティによって受け入れられ、処理された SNMPGet-ResponsePDUsの総数 ::= { snmp 18 } snmpInTraps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Trap PDUs which have been accepted and processed by the SNMP protocol entity." SNMPプロトコルエンティティによって受け入れられ、処理 されたSNMPTrapPDUsの総数。 ::= { snmp 19 } snmpOutTooBigs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `tooBig.'" SNMPプロトコルエンティティによって生成されたエラー ステータスフィールドの値がtooBigであるSNMPPDUsの総数。 ::= { snmp 20 } SNMP Working Group [Page 64] RFC 1213 MIB-II March 1991 snmpOutNoSuchNames OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status is `noSuchName'." SNMPプロトコルエンティティによって生成されたエラー ステータスフィールドの値がnoSuchNameであるSNMPPDUsの総数。 ::= { snmp 21 } snmpOutBadValues OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `badValue'." SNMPプロトコルエンティティによって生成されたエラー ステータスフィールドの値がbadValueであるSNMPPDUsの総数。 ::= { snmp 22 } -- { snmp 23 } is not used snmpOutGenErrs OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP PDUs which were generated by the SNMP protocol entity and for which the value of the error-status field is `genErr'." SNMPプロトコルエンティティによって生成されたエラー ステータスフィールドの値がgenErrであるSNMPPDUsの総数。 ::= { snmp 24 } snmpOutGetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Request PDUs which have been generated by the SNMP protocol entity." SNMPプロトコルエンティティによって生成された SNMPGet-RequestPDUsの総数。 ::= { snmp 25 } snmpOutGetNexts OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory SNMP Working Group [Page 65] RFC 1213 MIB-II March 1991 DESCRIPTION "The total number of SNMP Get-Next PDUs which have been generated by the SNMP protocol entity." SNMPプロトコルエンティティによって生成された SNMPGet-NextPDUsの総数。 ::= { snmp 26 } snmpOutSetRequests OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Set-Request PDUs which have been generated by the SNMP protocol entity." SNMPプロトコルエンティティによって生成された SNMPSet-RequestPDUsの総数。 ::= { snmp 27 } snmpOutGetResponses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Get-Response PDUs which have been generated by the SNMP protocol entity." SNMPプロトコルエンティティによって生成された SNMPGet-ResponsePDUsの総数。 ::= { snmp 28 } snmpOutTraps OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The total number of SNMP Trap PDUs which have been generated by the SNMP protocol entity." SNMPプロトコルエンティティによって生成されたSNMPTrapPDUs の総数。 ::= { snmp 29 } snmpEnableAuthenTraps OBJECT-TYPE SYNTAX INTEGER { enabled(1), disabled(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Indicates whether the SNMP agent process is permitted to generate authentication-failure traps. The value of this object overrides any configuration information; as such, it provides a means whereby all authentication-failure traps may be disabled. SNMPエージェントプロセスが認証失敗(authentication-failure) トラップを生成することを許可されているかどうかを示している。 このオブジェクトの値は、どのような構成情報も無視する。 つまり、すべての認証失敗トラップをディセーブルにしても よいという機能を提供している。 Note that it is strongly recommended that this object be stored in non-volatile memory so that it remains constant between re-initializations of the network management system." このオブジェクトはネットワーク管理システムの再初期化の間、 固定値として残しておくために不揮発性メモリ中に格納すること を推奨している事に注意。 SNMP Working Group [Page 66] RFC 1213 MIB-II March 1991 ::= { snmp 30 } END 7. Acknowledgements 謝辞 This document was produced by the SNMP Working Group: この文書は SNMP ワーキンググループによって作成された。 Anne Ambler, Spider Karl Auerbach, Sun Fred Baker, ACC David Bridgham, Epilogue Technology Ken Brinkerhoff Ron Broersma, NOSC Brian Brown, Synoptics Jack Brown, US Army Theodore Brunner, Bellcore Jeff Buffum, HP Jeffrey Buffum, HP John Burress, Wellfleet Jeffrey D. Case, University of Tennessee at Knoxville Chris Chiptasso, Spartacus Paul Ciarfella, DEC Bob Collet John Cook, Chipcom Tracy Cox, Bellcore James R. Davin, MIT-LCS Eric Decker, cisco Kurt Dobbins, Cabletron Nadya El-Afandi, Network Systems Gary Ellis, HP Fred Engle Mike Erlinger Mark S. Fedor, PSI Richard Fox, Synoptics Karen Frisa, CMU Stan Froyd, ACC Chris Gunner, DEC Fred Harris, University of Tennessee at Knoxville Ken Hibbard, Xylogics Ole Jacobsen, Interop Ken Jones Satish Joshi, Synoptics Frank Kastenholz, Racal-Interlan Shimshon Kaufman, Spartacus Ken Key, University of Tennessee at Knoxville Jim Kinder, Fibercom Alex Koifman, BBN SNMP Working Group [Page 67] RFC 1213 MIB-II March 1991 Christopher Kolb, PSI Cheryl Krupczak, NCR Paul Langille, DEC Martin Lee Schoffstall, PSI Peter Lin, Vitalink John Lunny, TWG Carl Malamud Gary Malkin, FTP Software, Inc. Randy Mayhew, University of Tennessee at Knoxville Keith McCloghrie, Hughes LAN Systems Donna McMaster, David Systems Lynn Monsanto, Sun Dave Perkins, 3COM Jim Reinstedler, Ungerman Bass Anil Rijsinghani, DEC Kathy Rinehart, Arnold AFB Kary Robertson Marshall T. Rose, PSI (chair) L. Michael Sabo, NCSC Jon Saperia, DEC Greg Satz, cisco Martin Schoffstall, PSI John Seligson Steve Sherry, Xyplex Fei Shu, NEC Sam Sjogren, TGV Mark Sleeper, Sparta Lance Sprung Mike St.Johns Bob Stewart, Xyplex Emil Sturniold Kaj Tesink, Bellcore Geoff Thompson, Synoptics Dean Throop, Data General Bill Townsend, Xylogics Maurice Turcotte, Racal-Milgo Kannan Varadhou Sudhanshu Verma, HP Bill Versteeg, Network Research Corporation Warren Vik, Interactive Systems David Waitzman, BBN Steve Waldbusser, CMU Dan Wintringhan David Wood Wengyik Yeong, PSI Jeff Young, Cray Research SNMP Working Group [Page 68] RFC 1213 MIB-II March 1991 In addition, the comments of the following individuals are also acknolwedged: さらに、次の個人のコメントも承認される: Craig A. Finseth, Minnesota Supercomputer Center, Inc. Jeffrey C. Honig, Cornell University Theory Center Philip R. Karn, Bellcore 8. References 参考文献 [1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, NRI, April 1988. RFC 1052 "インターネット ネットワーク管理標準の開発の為のIAB 勧告" [2] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets," RFC 1065, TWG, August 1988. RFC 1065 "TCP/IPベースのインターネットの為の管理情報の構造と識別" [3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets, RFC 1066, TWG, August 1988. RFC 1066 "TCP/IPベースのインターネットの為のネットワーク管理用 管理情報ベース" [4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, NRI, August 1989. "第２特別ネットワーク管理評価グループのレポート" [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", RFC 1098, University of Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic Institute, MIT Laboratory for Computer Science, April 1989. RFC 1098 "単純なネットワーク管理プロトコル(SNMP)" [6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC 854, USC/Information Sciences Institute, May 1983. RFC 854 "TELNETプロトコル詳細" [7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base", RFC 1162, cisco Systems, Inc., June 1990. RFC 1162 "中間システム管理情報ベースへのコネクションレス ネットワークプロトコルとエンドシステム" [8] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization, International Standard 8824, December 1987. "ASN.1 詳細" [9] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization, International Standard 8825, December 1987. "ASN.1 基本コーディング詳細" [10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988, Stanford, California. "混雑回避と制御" SNMP Working Group [Page 69] RFC 1213 MIB-II March 1991 [11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer", RFC 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The Wollongong Group, February 1989. RFC 1070 "OSIネットワーク層の実験のためのサブネットワークとして のインターネットの使用" [12] Rose M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. RFC 1155 "TCP/IP ベースのインターネットの為の管理情報の構造と識別" [13] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. RFC 1157 "単純なネットワーク管理プロトコル" [14] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. RFC 1212 "簡潔なMIB定義" 9. Security Considerations セキュリティ考察 Security issues are not discussed in this memo. セキュリティ問題はこの文書では議論されない。 10. Authors' Addresses 著者の住所 Keith McCloghrie Hughes LAN Systems 1225 Charleston Road Mountain View, CA 94043 1225 Charleston Road Mountain View, CA 94043 Phone: (415) 966-7934 EMail: kzm@hls.com Marshall T. Rose Performance Systems International 5201 Great America Parkway Suite 3106 Santa Clara, CA 95054 Phone: +1 408 562 6222 EMail: mrose@psi.com X.500: rose, psi, us SNMP Working Group [Page 70] -- 翻訳は、須藤 昌信 が行いました。 訳の精度について一切の保証はありません。