Network Working Group K. McCloghrie
Request for Comments: 2863 Cisco Systems
Obsoletes: 2233 F. Kastenholz
Category: Standards Track Argon Networks
June 2000
Network Working Group K. McCloghrie
Request for Comments: 2863 Cisco Systems
Obsoletes: 2233 F. Kastenholz
Category: Standards Track Argon Networks
June 2000
The Interfaces Group MIB
接口组MIB
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Table of Contents
目录
1 Introduction ................................................. 2
2 The SNMP Network Management Framework ........................ 2
3 Experience with the Interfaces Group ......................... 3
3.1 Clarifications/Revisions ................................... 4
3.1.1 Interface Sub-Layers ..................................... 4
3.1.2 Guidance on Defining Sub-layers .......................... 7
3.1.3 Virtual Circuits ......................................... 8
3.1.4 Bit, Character, and Fixed-Length Interfaces .............. 8
3.1.5 Interface Numbering ...................................... 10
3.1.6 Counter Size ............................................. 14
3.1.7 Interface Speed .......................................... 16
3.1.8 Multicast/Broadcast Counters ............................. 17
3.1.9 Trap Enable .............................................. 17
3.1.10 Addition of New ifType values ........................... 18
3.1.11 InterfaceIndex Textual Convention ....................... 18
3.1.12 New states for IfOperStatus ............................. 18
3.1.13 IfAdminStatus and IfOperStatus .......................... 19
3.1.14 IfOperStatus in an Interface Stack ...................... 21
3.1.15 Traps ................................................... 21
3.1.16 ifSpecific .............................................. 23
3.1.17 Creation/Deletion of Interfaces ......................... 23
3.1.18 All Values Must be Known ................................ 24
4 Media-Specific MIB Applicability ............................. 24
5 Overview ..................................................... 25
6 Interfaces Group Definitions ................................. 26
1 Introduction ................................................. 2
2 The SNMP Network Management Framework ........................ 2
3 Experience with the Interfaces Group ......................... 3
3.1 Clarifications/Revisions ................................... 4
3.1.1 Interface Sub-Layers ..................................... 4
3.1.2 Guidance on Defining Sub-layers .......................... 7
3.1.3 Virtual Circuits ......................................... 8
3.1.4 Bit, Character, and Fixed-Length Interfaces .............. 8
3.1.5 Interface Numbering ...................................... 10
3.1.6 Counter Size ............................................. 14
3.1.7 Interface Speed .......................................... 16
3.1.8 Multicast/Broadcast Counters ............................. 17
3.1.9 Trap Enable .............................................. 17
3.1.10 Addition of New ifType values ........................... 18
3.1.11 InterfaceIndex Textual Convention ....................... 18
3.1.12 New states for IfOperStatus ............................. 18
3.1.13 IfAdminStatus and IfOperStatus .......................... 19
3.1.14 IfOperStatus in an Interface Stack ...................... 21
3.1.15 Traps ................................................... 21
3.1.16 ifSpecific .............................................. 23
3.1.17 Creation/Deletion of Interfaces ......................... 23
3.1.18 All Values Must be Known ................................ 24
4 Media-Specific MIB Applicability ............................. 24
5 Overview ..................................................... 25
6 Interfaces Group Definitions ................................. 26
7 Acknowledgements ............................................. 64
8 References ................................................... 64
9 Security Considerations ...................................... 66
10 Authors' Addresses .......................................... 67
11 Changes from RFC 2233 ....................................... 67
12 Notice on Intellectual Property ............................. 68
13 Full Copyright Statement .................................... 69
7 Acknowledgements ............................................. 64
8 References ................................................... 64
9 Security Considerations ...................................... 66
10 Authors' Addresses .......................................... 67
11 Changes from RFC 2233 ....................................... 67
12 Notice on Intellectual Property ............................. 68
13 Full Copyright Statement .................................... 69
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II [17], especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the ' interfaces' group for managing various sub-layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the ' interfaces' group. This memo obsoletes RFC 2233, the previous version of the Interfaces Group MIB.
此备忘录定义了管理信息库（MIB）的一部分，用于Internet社区中的网络管理协议。特别是，它描述了用于管理网络接口的托管对象。本备忘录讨论了MIB-II的“接口”组[17]，特别是从定义大量特定于媒体的MIB模块中获得的经验，这些模块与“接口”组一起用于管理网络层下的各种子层。它规定了“接口”组的MIB-II模型中架构问题的澄清和扩展。本备忘录淘汰了RFC 2233，即接口组MIB的早期版本。
The key words "MUST" and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [16].
本文件中的关键词“必须”和“不得”应按照RFC 2119[16]中所述进行解释。
The SNMP Management Framework presently consists of five major components:
SNMP管理框架目前由五个主要组件组成：
o An overall architecture, described in RFC 2571 [1].
o RFC 2571[1]中描述的总体架构。
o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, which consists of RFC 2578 [5], RFC 2579 [6] and RFC 2580 [7].
o 为管理目的描述和命名对象和事件的机制。这种管理信息结构（SMI）的第一个版本称为SMIv1，并在STD 16、RFC 1155[2]、STD 16、RFC 1212[3]和RFC 1215[4]中进行了描述。第二个版本称为SMIv2，在STD 58中有描述，其中包括RFC 2578[5]、RFC 2579[6]和RFC 2580[7]。
o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
o 用于传输管理信息的消息协议。SNMP消息协议的第一个版本称为SNMPv1，在STD 15、RFC 1157[8]中进行了描述。SNMP消息协议的第二个版本不是互联网标准跟踪协议，称为SNMPv2c，在RFC 1901[9]和RFC 1906[10]中进行了描述。消息协议的第三个版本称为SNMPv3，在RFC 1906[10]、RFC 2572[11]和RFC 2574[12]中进行了描述。
o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
o 访问管理信息的协议操作。STD 15、RFC 1157[8]中描述了第一组协议操作和相关PDU格式。RFC 1905[13]中描述了第二组协议操作和相关PDU格式。
o A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
o RFC 2573[14]中描述的一组基本应用程序和RFC 2575[15]中描述的基于视图的访问控制机制。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [22].
有关当前SNMP管理框架的更详细介绍，请参见RFC 2570[22]。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
托管对象通过虚拟信息存储（称为管理信息库或MIB）进行访问。MIB中的对象是使用SMI中定义的机制定义的。
This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (e.g., use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.
此备忘录指定了符合SMIv2的MIB模块。通过适当的翻译，可以生成符合SMIv1的MIB。生成的已翻译MIB必须在语义上等效，除非由于无法翻译而省略了对象或事件（例如，使用计数器64）。在翻译过程中，SMIv2中的一些机器可读信息将转换为SMIv1中的文本描述。但是，这种机器可读信息的丢失不被认为会改变MIB的语义。
One of the strengths of internetwork-layer protocols such as IP [18] is that they are designed to run over any network interface. In achieving this, IP considers any and all protocols it runs over as a single "network interface" layer. A similar view is taken by other internetwork-layer protocols. This concept is represented in MIB-II by the 'interfaces' group which defines a generic set of managed objects such that any network interface can be managed in an interface-independent manner through these managed objects. The ' interfaces' group provides the means for additional managed objects specific to particular types of network interface (e.g., a specific medium such as Ethernet) to be defined as extensions to the ' interfaces' group for media-specific management. Since the standardization of MIB-II, many such media-specific MIB modules have been defined.
互联网层协议（如IP[18]）的优点之一是，它们被设计为可以在任何网络接口上运行。在实现这一点时，IP将其运行的任何和所有协议视为一个“网络接口”层。其他网络层协议也持类似观点。该概念在MIB-II中由“接口”组表示，该组定义了一组通用的受管对象，使得任何网络接口都可以通过这些受管对象以独立于接口的方式进行管理。“接口”组提供了特定于特定类型网络接口（例如，以太网等特定介质）的附加受管对象的方法，这些对象将被定义为“接口”组的扩展，用于特定介质的管理。自从MIB-II标准化以来，已经定义了许多此类特定于介质的MIB模块。
Experience in defining these media-specific MIB modules has shown that the model defined by MIB-II is too simplistic and/or static for some types of media-specific management. As a result, some of these media-specific MIB modules assume an evolution or loosening of the
定义这些特定于介质的MIB模块的经验表明，对于某些特定于介质的管理类型，MIB-II定义的模型过于简单和/或静态。因此，其中一些特定于介质的MIB模块假定
model. This memo documents and standardizes that evolution of the model and fills in the gaps caused by that evolution. This memo also incorporates the interfaces group extensions documented in RFC 1229 [19].
模型本备忘录记录并标准化了模型的演变，并填补了该演变造成的空白。本备忘录还包含RFC 1229[19]中记录的接口组扩展。
There are several areas for which experience has indicated that clarification, revision, or extension of the model would be helpful. The following sections discuss the changes in the interfaces group adopted by this memo in each of these areas.
有几个领域的经验表明，澄清、修订或扩展模型将有所帮助。以下各节讨论了本备忘录所采用的接口组在这些领域中的变化。
In some sections, one or more paragraphs contain discussion of rejected alternatives to the model adopted in this memo. Readers not familiar with the MIB-II model and not interested in the rationale behind the new model may want to skip these paragraphs.
在某些章节中，一个或多个段落包含对本备忘录所采用模型的被拒绝替代方案的讨论。不熟悉MIB-II模型且对新模型背后的原理不感兴趣的读者可能希望跳过这些段落。
Experience in defining media-specific management information has shown the need to distinguish between the multiple sub-layers beneath the internetwork-layer. In addition, there is a need to manage these sub-layers in devices (e.g., MAC-layer bridges) which are unaware of which, if any, internetwork protocols run over these sub-layers. As such, a model of having a single conceptual row in the interfaces table (MIB-II's ifTable) represent a whole interface underneath the internetwork-layer, and having a single associated media-specific MIB module (referenced via the ifType object) is too simplistic. A further problem arises with the value of the ifType object which has enumerated values for each type of interface.
定义媒体特定管理信息的经验表明，需要区分网络层下的多个子层。此外，需要管理设备（例如，MAC层网桥）中的这些子层，这些设备不知道在这些子层上运行哪些（如果有的话）互联网协议。因此，在接口表（MIB-II的ifTable）中有一个概念行的模型表示网络层下的整个接口，并且有一个关联的特定于媒体的MIB模块（通过ifType对象引用）的模型过于简单。ifType对象的值还存在另一个问题，该对象为每种类型的接口枚举了值。
Consider, for example, an interface with PPP running over an HDLC link which uses a RS232-like connector. Each of these sub-layers has its own media-specific MIB module. If all of this is represented by a single conceptual row in the ifTable, then an enumerated value for ifType is needed for that specific combination which maps to the specific combination of media-specific MIBs. Furthermore, such a model still lacks a method to describe the relationship of all the sub-layers of the MIB stack.
例如，考虑使用PPP在HDLC链路上运行的接口，该链路使用RS232型连接器。每个子层都有自己的媒体特定MIB模块。如果所有这些都由ifTable中的一个概念行表示，则该特定组合需要ifType的枚举值，该组合映射到特定于媒体的MIB的特定组合。此外，这种模型仍然缺乏描述MIB堆栈所有子层之间关系的方法。
An associated problem is that of upward and downward multiplexing of the sub-layers. An example of upward multiplexing is MLP (Multi-Link-Procedure) which provides load-sharing over several serial lines by appearing as a single point-to-point link to the sub-layer(s) above. An example of downward multiplexing would be several instances of PPP, each framed within a separate X.25 virtual circuit,
相关联的问题是子层的向上和向下复用。向上多路复用的一个例子是MLP（多链路过程），它通过显示为到上面的子层的单个点到点链路，在多条串行线路上提供负载共享。下行多路复用的一个例子是PPP的几个实例，每个实例都在一个单独的X.25虚拟电路中帧，
all of which run over one fractional T1 channel, concurrently with other uses of the T1 link. The MIB structure must allow these sorts of relationships to be described.
所有这些都运行在一个分数T1通道上，与T1链路的其他用途同时运行。MIB结构必须允许描述这些类型的关系。
Several solutions for representing multiple sub-layers were rejected. One was to retain the concept of one conceptual row for all the sub-layers of an interface and have each media-specific MIB module identify its "superior" and "subordinate" sub-layers through OBJECT IDENTIFIER "pointers". This scheme would have several drawbacks: the superior/subordinate pointers would be contained in the media-specific MIB modules; thus, a manager could not learn the structure of an interface without inspecting multiple pointers in different MIB modules; this would be overly complex and only possible if the manager had knowledge of all the relevant media-specific MIB modules; MIB modules would all need to be retrofitted with these new "pointers"; this scheme would not adequately address the problem of upward and downward multiplexing; and finally, enumerated values of ifType would be needed for each combination of sub-layers. Another rejected solution also retained the concept of one conceptual row for all the sub-layers of an interface but had a new separate MIB table to identify the "superior" and "subordinate" sub-layers and to contain OBJECT IDENTIFIER "pointers" to the media-specific MIB module for each sub-layer. Effectively, one conceptual row in the ifTable would represent each combination of sub-layers between the internetwork-layer and the wire. While this scheme has fewer drawbacks, it still would not support downward multiplexing, such as PPP over MLP: observe that MLP makes two (or more) serial lines appear to the layers above as a single physical interface, and thus PPP over MLP should appear to the internetwork-layer as a single interface; in contrast, this scheme would result in two (or more) conceptual rows in the ifTable, both of which the internetwork-layer would run over. This scheme would also require enumerated values of ifType for each combination of sub-layers.
表示多个子层的几种解决方案被拒绝。一个是为接口的所有子层保留一个概念行的概念，并让每个媒体特定MIB模块通过对象标识符“指针”标识其“上级”和“下级”子层。这种方案有几个缺点：上级/下级指针将包含在特定于媒体的MIB模块中；因此，管理者如果不检查不同MIB模块中的多个指针，就无法了解接口的结构；这将过于复杂，只有在经理了解所有相关媒体特定MIB模块的情况下才有可能实现；MIB模块都需要用这些新的“指针”进行改装；该方案不能充分解决上行和下行多路复用的问题；最后，每个子层组合都需要ifType的枚举值。另一个被拒绝的解决方案还保留了接口所有子层的一个概念行的概念，但有一个新的单独MIB表，用于标识“上级”和“下级”子层，并包含指向每个子层的媒体特定MIB模块的对象标识符“指针”。实际上，ifTable中的一个概念行将表示网络层和导线之间的每个子层组合。虽然该方案的缺点较少，但它仍然不支持向下复用，例如MLP上的PPP：观察到MLP使两条（或更多）串行线作为单个物理接口出现在上面的层上，因此MLP上的PPP应该作为单个接口出现在网络层上；相反，此方案将在ifTable中产生两个（或更多）概念行，这两个概念行都将被internetwork层覆盖。该方案还要求每个子层组合的ifType枚举值。
The solution adopted by this memo is to have an individual conceptual row in the ifTable to represent each sub-layer, and have a new separate MIB table (the ifStackTable, see section 6 below) to identify the "superior" and "subordinate" sub-layers through INTEGER "pointers" to the appropriate conceptual rows in the ifTable. This solution supports both upward and downward multiplexing, allows the IANAifType to Media-Specific MIB mapping to identify the media-specific MIB module for that sub-layer, such that the new table need only be referenced to obtain information about layering, and it only requires enumerated values of ifType for each sub-layer, not for combinations of them. However, it does require that the descriptions of some objects in the ifTable (specifically, ifType, ifPhysAddress, ifInUcastPkts, and ifOutUcastPkts) be generalized so as to apply to any sub-layer (rather than only to a sub-layer immediately beneath
本备忘录采用的解决方案是在ifTable中有一个单独的概念行来表示每个子层，并有一个新的单独MIB表（ifStackTable，见下文第6节），通过指向ifTable中相应概念行的整数“指针”来识别“上级”和“下级”子层。此解决方案支持向上和向下复用，允许IANAifType到特定于媒体的MIB映射来标识该子层的特定于媒体的MIB模块，因此只需引用新表以获取有关分层的信息，并且只需要为每个子层枚举ifType值，不适用于它们的组合。但是，它确实要求对ifTable中的某些对象（特别是ifType、ifPhysAddress、ifInUcastPkts和ifOutUcastPkts）的描述进行泛化，以便应用于任何子层（而不仅仅是紧靠其下的子层）
the network layer as previously), plus some (specifically, ifSpeed) which need to have appropriate values identified for use when a generalized definition does not apply to a particular sub-layer.
网络层（如前所述），加上一些（特别是ifSpeed），当通用定义不适用于特定子层时，需要确定适当的值以供使用。
In addition, this adopted solution makes no requirement that a device, in which a sub-layer is instrumented by a conceptual row of the ifTable, be aware of whether an internetwork protocol runs on top of (i.e., at some layer above) that sub-layer. In fact, the counters of packets received on an interface are defined as counting the number "delivered to a higher-layer protocol". This meaning of "higher-layer" includes:
此外，这种采用的解决方案不要求设备（其中子层由ifTable的概念行进行检测）知道是否在该子层之上（即，在上面的某一层）运行网络间协议。事实上，接口上接收的数据包计数器被定义为计算“传送到更高层协议”的数量。“更高层”的含义包括：
(1) Delivery to a forwarding module which accepts packets/frames/octets and forwards them on at the same protocol layer. For example, for the purposes of this definition, the forwarding module of a MAC-layer bridge is considered as a "higher-layer" to the MAC-layer of each port on the bridge.
(1) 传送到转发模块，该模块接受数据包/帧/八位字节，并在同一协议层上转发它们。例如，出于该定义的目的，MAC层网桥的转发模块被视为网桥上每个端口的MAC层的“更高层”。
(2) Delivery to a higher sub-layer within a interface stack. For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be considered the higher sub-layer to the serial interface.
(2) 交付到接口堆栈中的更高子层。例如，就本定义而言，如果PPP模块直接在串行接口上运行，则PPP模块将被视为串行接口的较高子层。
(3) Delivery to a higher protocol layer which does not do packet forwarding for sub-layers that are "at the top of" the interface stack. For example, for the purposes of this definition, the local IP module would be considered the higher layer to a SLIP serial interface.
(3) 传送到更高的协议层，该协议层不对处于接口堆栈顶部的子层进行数据包转发。例如，就本定义而言，本地IP模块将被视为SLIP串行接口的更高层。
Similarly, for output, the counters of packets transmitted out an interface are defined as counting the number "that higher-level protocols requested to be transmitted". This meaning of "higher-layer" includes:
类似地，对于输出，从接口发送的包的计数器被定义为计数“请求发送的更高级别协议”的数目。“更高层”的含义包括：
(1) A forwarding module, at the same protocol layer, which transmits packets/frames/octets that were received on an different interface. For example, for the purposes of this definition, the forwarding module of a MAC-layer bridge is considered as a "higher-layer" to the MAC-layer of each port on the bridge.
(1) 位于同一协议层的转发模块，用于传输在不同接口上接收的数据包/帧/八位字节。例如，出于该定义的目的，MAC层网桥的转发模块被视为网桥上每个端口的MAC层的“更高层”。
(2) The next higher sub-layer within an interface stack. For example, for the purposes of this definition, if a PPP module operated directly over a serial interface, the PPP module would be a "higher layer" to the serial interface.
(2) 接口堆栈中的下一个更高的子层。例如，就本定义而言，如果PPP模块直接在串行接口上运行，则PPP模块将是串行接口的“更高层”。
(3) For sub-layers that are "at the top of" the interface stack, a higher element in the network protocol stack. For example, for the purposes of this definition, the local IP module would be considered the higher layer to an Ethernet interface.
(3) 对于“位于”接口堆栈顶部的子层，网络协议堆栈中的较高元素。例如，就本定义而言，本地IP模块将被视为以太网接口的更高层。
The designer of a media-specific MIB must decide whether to divide the interface into sub-layers or not, and if so, how to make the divisions. The following guidance is offered to assist the media-specific MIB designer in these decisions.
特定于媒体的MIB的设计者必须决定是否将接口划分为子层，如果是，如何划分。以下指南旨在帮助媒体特定MIB设计者做出这些决策。
In general, the number of entries in the ifTable should be kept to the minimum required for network management. In particular, a group of related interfaces should be treated as a single interface with one entry in the ifTable providing that:
通常，ifTable中的条目数应保持在网络管理所需的最小值。特别是，一组相关接口应被视为一个接口，在ifTable中有一个条目，前提是：
(1) None of the group of interfaces performs multiplexing for any other interface in the agent,
(1) 接口组中没有一个为代理中的任何其他接口执行多路复用，
(2) There is a meaningful and useful way for all of the ifTable's information (e.g., the counters, and the status variables), and all of the ifTable's capabilities (e.g., write access to ifAdminStatus), to apply to the group of interfaces as a whole.
(2) 对于ifTable的所有信息（例如计数器和状态变量）以及ifTable的所有功能（例如对ifAdminStatus的写入访问），都有一种有意义且有用的方法应用于整个接口组。
Under these circumstances, there should be one entry in the ifTable for such a group of interfaces, and any internal structure which needs to be represented to network management should be captured in a MIB module specific to the particular type of interface.
在这些情况下，对于这样一组接口，ifTable中应该有一个条目，需要向网络管理表示的任何内部结构都应该在特定于特定接口类型的MIB模块中捕获。
Note that application of bullet 2 above to the ifTable's ifType object requires that there is a meaningful media-specific MIB and a meaningful ifType value which apply to the group of interfaces as a whole. For example, it is not appropriate to treat an HDLC sub-layer and an RS-232 sub-layer as a single ifTable entry when the media-specific MIBs and the ifType values for HDLC and RS-232 are separate (rather than combined).
请注意，将上面的项目符号2应用于ifTable的ifType对象需要有一个有意义的媒体特定MIB和一个有意义的ifType值，该值应用于整个接口组。例如，当HDLC和RS-232的媒体特定mib和ifType值是分开的（而不是组合的）时，将HDLC子层和RS-232子层视为单个ifTable条目是不合适的。
Subject to the above, it is appropriate to assign an ifIndex value to any interface that can occur in an interface stack (in the ifStackTable) where the bottom of the stack is a physical interface (ifConnectorPresent has the value 'true') and there is a layer-3 or other application that "points down" to the top of this stack. An example of an application that points down to the top of the stack is the Character MIB [21].
根据上述规定，宜将ifIndex值分配给接口堆栈（在ifStackTable中）中可能出现的任何接口，其中堆栈的底部是物理接口（ifConnectorPresent的值为“true”），并且有一个第3层或其他应用程序“指向”该堆栈的顶部。指向堆栈顶部的应用程序示例是字符MIB[21]。
Note that the sub-layers of an interface on one device will sometimes be different from the sub-layers of the interconnected interface of another device; for example, for a frame-relay DTE interface connected a frameRelayService interface, the inter-connected DTE and DCE interfaces have different ifType values and media-specific MIBs.
注意，一个设备上接口的子层有时会与另一个设备的互连接口的子层不同；例如，对于连接到frameRelayService接口的帧中继DTE接口，相互连接的DTE和DCE接口具有不同的ifType值和特定于媒体的MIB。
These guidelines are just that, guidelines. The designer of a media-specific MIB is free to lay out the MIB in whatever SMI conformant manner is desired. However, in doing so, the media-specific MIB MUST completely specify the sub-layering model used for the MIB, and provide the assumptions, reasoning, and rationale used to develop that model.
这些指导方针就是，指导方针。特定于媒体的MIB的设计者可以自由地以任何符合SMI的方式布置MIB。但是，在这样做时，特定于媒体的MIB必须完全指定用于MIB的子层模型，并提供用于开发该模型的假设、推理和基本原理。
Several of the sub-layers for which media-specific MIB modules have been defined are connection oriented (e.g., Frame Relay, X.25). Experience has shown that each effort to define such a MIB module revisits the question of whether separate conceptual rows in the ifTable are needed for each virtual circuit. Most, if not all, of these efforts to date have decided to have all virtual circuits reference a single conceptual row in the ifTable.
为其定义了媒体特定MIB模块的若干子层是面向连接的（例如，帧中继，X.25）。经验表明，定义这样一个MIB模块的每一次努力都会重新考虑一个问题，即每个虚拟电路是否需要ifTable中单独的概念行。迄今为止，这些工作中的大多数（如果不是全部的话）都决定让所有虚拟电路引用ifTable中的单个概念行。
This memo strongly recommends that connection-oriented sub-layers do not have a conceptual row in the ifTable for each virtual circuit. This avoids the proliferation of conceptual rows, especially those which have considerable redundant information. (Note, as a comparison, that connection-less sub-layers do not have conceptual rows for each remote address.) There may, however, be circumstances under which it is appropriate for a virtual circuit of a connection-oriented sub-layer to have its own conceptual row in the ifTable; an example of this might be PPP over an X.25 virtual circuit. The MIB in section 6 of this memo supports such circumstances.
此备忘录强烈建议面向连接的子层在每个虚拟电路的ifTable中不要有概念行。这避免了概念行的扩散，尤其是那些具有大量冗余信息的概念行。（作为比较，请注意，无连接子层不具有每个远程地址的概念行。）然而，在某些情况下，面向连接的子层的虚拟电路在ifTable中具有其自己的概念行是合适的；这方面的一个例子可能是X.25虚拟电路上的PPP。本备忘录第6节中的MIB支持此类情况。
If a media-specific MIB wishes to assign an entry in the ifTable to each virtual circuit, the MIB designer must present the rationale for this decision in the media-specific MIB's specification.
如果特定于介质的MIB希望在ifTable中为每个虚拟电路分配一个条目，MIB设计者必须在特定于介质的MIB规范中说明此决定的基本原理。
RS-232 is an example of a character-oriented sub-layer over which (e.g., through use of PPP) IP datagrams can be sent. Due to the packet-based nature of many of the objects in the ifTable, experience has shown that it is not appropriate to have a character-oriented sub-layer represented by a whole conceptual row in the ifTable.
RS-232是面向字符的子层的一个示例，在该子层上（例如，通过使用PPP）可以发送IP数据报。由于ifTable中的许多对象都是基于数据包的，经验表明，在ifTable中使用一个完整的概念行表示面向字符的子层是不合适的。
Experience has also shown that it is sometimes desirable to have some management information for bit-oriented interfaces, which are similarly difficult to represent by a whole conceptual row in the ifTable. For example, to manage the channels of a DS1 circuit, where only some of the channels are carrying packet-based data.
经验还表明，有时需要为面向位的接口提供一些管理信息，这些信息同样难以用ifTable中的整个概念行表示。例如，管理DS1电路的信道，其中只有一些信道承载基于分组的数据。
A further complication is that some subnetwork technologies transmit data in fixed length transmission units. One example of such a technology is cell relay, and in particular Asynchronous Transfer Mode (ATM), which transmits data in fixed-length cells. Representing such a interface as a packet-based interface produces redundant objects if the relationship between the number of packets and the number of octets in either direction is fixed by the size of the transmission unit (e.g., the size of a cell).
更复杂的是，一些子网技术以固定长度的传输单元传输数据。这种技术的一个例子是信元中继，特别是异步传输模式（ATM），它在固定长度的信元中传输数据。如果在任一方向上的分组数量和八位字节数量之间的关系由传输单元的大小（例如，小区的大小）固定，则将这样的接口表示为基于分组的接口产生冗余对象。
About half the objects in the ifTable are applicable to every type of interface: packet-oriented, character-oriented, and bit-oriented. Of the other half, two are applicable to both character-oriented and packet-oriented interfaces, and the rest are applicable only to packet-oriented interfaces. Thus, while it is desirable for consistency to be able to represent any/all types of interfaces in the ifTable, it is not possible to implement the full ifTable for bit- and character-oriented sub-layers.
ifTable中大约一半的对象适用于每种类型的接口：面向包、面向字符和面向位。在另一半中，两个适用于面向字符和面向数据包的接口，其余的仅适用于面向数据包的接口。因此，尽管一致性希望能够表示ifTable中的任何/所有类型的接口，但不可能实现面向位和面向字符的子层的完整ifTable。
A rejected solution to this problem would be to split the ifTable into two (or more) new MIB tables, one of which would contain objects that are relevant only to packet-oriented interfaces (e.g., PPP), and another that may be used by all interfaces. This is highly undesirable since it would require changes in every agent implementing the ifTable (i.e., just about every existing SNMP agent).
此问题的一个被拒绝的解决方案是将ifTable拆分为两个（或多个）新MIB表，其中一个将包含仅与面向数据包的接口（例如PPP）相关的对象，另一个可由所有接口使用。这是非常不可取的，因为它需要在实现ifTable的每个代理（即，几乎每个现有的SNMP代理）中进行更改。
The solution adopted in this memo builds upon the fact that compliance statements in SMIv2 (in contrast to SMIv1) refer to object groups, where object groups are explicitly defined by listing the objects they contain. Thus, with SMIv2, multiple compliance statements can be specified, one for all interfaces and additional ones for specific types of interfaces. The separate compliance statements can be based on separate object groups, where the object group for all interfaces can contain only those objects from the ifTable which are appropriate for every type of interfaces. Using this solution, every sub-layer can have its own conceptual row in the ifTable.
本备忘录中采用的解决方案基于这样一个事实，即SMIv2（与SMIv1相反）中的符合性声明指的是对象组，其中对象组通过列出它们所包含的对象来明确定义。因此，使用SMIv2，可以指定多个符合性声明，一个用于所有接口，另一个用于特定类型的接口。单独的符合性声明可以基于单独的对象组，其中所有接口的对象组只能包含ifTable中适用于每种接口类型的对象。使用此解决方案，每个子层在ifTable中都可以有自己的概念行。
Thus, section 6 of this memo contains definitions of the objects of the existing 'interfaces' group of MIB-II, in a manner which is both SNMPv2-compliant and semantically-equivalent to the existing MIB-II definitions. With equivalent semantics, and with the BER ("on the
因此，本备忘录第6节包含MIB-II现有“接口”组对象的定义，其方式符合SNMPv2，并且在语义上等同于现有MIB-II定义。具有等效语义，并且在
wire") encodings unchanged, these definitions retain the same OBJECT IDENTIFIER values as assigned by MIB-II. Thus, in general, no rewrite of existing agents which conform to MIB-II and the ifExtensions MIB is required.
wire”）编码不变，这些定义保留MIB-II分配的相同对象标识符值。因此，通常不需要重写符合MIB-II和IFM-MIB的现有代理。
In addition, this memo defines several object groups for the purposes of defining which objects apply to which types of interface:
此外，本备忘录还定义了几个对象组，用于定义哪些对象适用于哪些类型的接口：
(1) the ifGeneralInformationGroup. This group contains those objects applicable to all types of network interfaces, including bit-oriented interfaces.
(1) IFGeneralInformation组。该组包含适用于所有类型网络接口的对象，包括面向位的接口。
(2) the ifPacketGroup. This group contains those objects applicable to packet-oriented network interfaces.
(2) ifPacketGroup。该组包含适用于面向数据包的网络接口的对象。
(3) the ifFixedLengthGroup. This group contains the objects applicable not only to character-oriented interfaces, such as RS-232, but also to those subnetwork technologies, such as cell-relay/ATM, which transmit data in fixed length transmission units. As well as the octet counters, there are also a few other counters (e.g., the error counters) which are useful for this type of interface, but are currently defined as being packet-oriented. To accommodate this, the definitions of these counters are generalized to apply to character-oriented interfaces and fixed-length-transmission interfaces.
(3) 不固定长度组。该组包含的对象不仅适用于面向字符的接口（如RS-232），还适用于以固定长度传输单元传输数据的子网技术（如信元中继/ATM）。除了八位字节计数器外，还有一些其他计数器（例如，错误计数器），它们对这种类型的接口很有用，但目前被定义为面向数据包的计数器。为了适应这种情况，这些计数器的定义被推广应用于面向字符的接口和固定长度的传输接口。
It should be noted that the octet counters in the ifTable aggregate octet counts for unicast and non-unicast packets into a single octet counter per direction (received/transmitted). Thus, with the above definition of fixed-length-transmission interfaces, where such interfaces which support non-unicast packets, separate counts of unicast and multicast/broadcast transmissions can only be maintained in a media-specific MIB module.
应该注意的是，ifTable聚合八位组中的八位组计数器将单播和非单播分组计数为每个方向（接收/发送）的单个八位组计数器。因此，在上述固定长度传输接口的定义中，支持非单播分组的此类接口只能在媒体特定MIB模块中维护单播和多播/广播传输的单独计数。
MIB-II defines an object, ifNumber, whose value represents:
MIB-II定义了一个对象ifNumber，其值表示：
"The number of network interfaces (regardless of their current state) present on this system."
“此系统上存在的网络接口数（无论其当前状态如何）。”
Each interface is identified by a unique value of the ifIndex object, and the description of ifIndex constrains its value as follows:
每个接口由ifIndex对象的唯一值标识，ifIndex的描述对其值的约束如下：
"Its value ranges between 1 and the value of ifNumber. The value for each interface must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization."
“其值范围在1和ifNumber的值之间。从实体的网络管理系统的一次重新初始化到下一次重新初始化，每个接口的值必须至少保持不变。”
This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. However, an increasing number of devices allow for the dynamic addition/removal of network interfaces. One example of this is a dynamic ability to configure the use of SLIP/PPP over a character-oriented port. For such dynamic additions/removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic.
对特定接口的ifIndex值的恒定性要求对于有效管理至关重要。然而，越来越多的设备允许动态添加/删除网络接口。这方面的一个例子是通过面向字符的端口配置SLIP/PPP使用的动态能力。对于这种动态添加/删除，恒定性要求和ifIndex值小于ifNumber的限制的结合是有问题的。
Redefining ifNumber to be the largest value of ifIndex was rejected since it would not help. Such a re-definition would require ifNumber to be deprecated and the utility of the redefined object would be questionable. Alternatively, ifNumber could be deprecated and not replaced. However, the deprecation of ifNumber would require a change to that portion of ifIndex's definition which refers to ifNumber. So, since the definition of ifIndex must be changed anyway in order to solve the problem, changes to ifNumber do not benefit the solution.
将ifNumber重新定义为ifIndex的最大值被拒绝，因为这没有帮助。这样的重新定义将需要弃用ifNumber，并且重新定义的对象的实用性将受到质疑。或者，可以不推荐使用ifNumber，而不替换它。但是，ifNumber的弃用需要对ifIndex定义中引用ifNumber的部分进行更改。因此，由于无论如何都必须更改ifIndex的定义才能解决问题，因此更改ifNumber对解决方案没有好处。
The solution adopted in this memo is just to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition. This is a minor change in the semantics of ifIndex; however, all existing agent implementations conform to this new definition, and in the interests of not requiring changes to existing agent implementations and to the many existing media-specific MIBs, this memo assumes that this change does not require ifIndex to be deprecated. Experience indicates that this assumption does "break" a few management applications, but this is considered preferable to breaking all agent implementations.
本备忘录中采用的解决方案只是删除ifIndex值必须小于ifNumber值的要求，并保留ifNumber的当前定义。这是ifIndex语义上的一个小变化；但是，所有现有代理实现都符合此新定义，并且为了不需要更改现有代理实现和许多现有媒体特定的MIB，本备忘录假设此更改不需要弃用iIndex。经验表明，这种假设确实“破坏”了一些管理应用程序，但这被认为比破坏所有代理实现更可取。
This solution also results in the possibility of "holes" in the ifTable, i.e., the ifIndex values of conceptual rows in the ifTable are not necessarily contiguous, but SNMP's GetNext (and GetBulk) operation easily deals with such holes. The value of ifNumber still represents the number of conceptual rows, which increases/decreases as new interfaces are dynamically added/removed.
此解决方案还可能导致ifTable中出现“漏洞”，即ifTable中概念行的ifIndex值不一定是连续的，但SNMP的GetNext（和GetBulk）操作可以轻松处理此类漏洞。ifNumber的值仍然表示概念行的数量，随着新接口的动态添加/删除，概念行的数量会增加/减少。
The requirement for constancy (between re-initializations) of an interface's ifIndex value is met by requiring that after an interface is dynamically removed, its ifIndex value is not re-used by a *different* dynamically added interface until after the following re-initialization of the network management system. This avoids the need for assignment (in advance) of ifIndex values for all possible interfaces that might be added dynamically. The exact meaning of a "different" interface is hard to define, and there will be gray areas. Any firm definition in this document would likely turn out to be inadequate. Instead, implementors must choose what it means in their particular situation, subject to the following rules:
接口的ifIndex值的恒定性（重新初始化之间）要求在动态删除接口后，其ifIndex值不被*其他*动态添加的接口重新使用，直到网络管理系统的以下重新初始化之后。这避免了（提前）为所有可能动态添加的接口分配ifIndex值的需要。“不同”界面的确切含义很难定义，而且会出现灰色区域。本文件中的任何明确定义都可能不充分。相反，实施者必须根据以下规则选择其在特定情况下的含义：
(1) a previously-unused value of ifIndex must be assigned to a dynamically added interface if an agent has no knowledge of whether the interface is the "same" or "different" to a previously incarnated interface.
(1) 如果代理不知道该接口与以前体现的接口是“相同”还是“不同”，则必须将以前未使用的ifIndex值分配给动态添加的接口。
(2) a management station, not noticing that an interface has gone away and another has come into existence, must not be confused when calculating the difference between the counter values retrieved on successive polls for a particular ifIndex value.
(2) 如果管理站没有注意到一个接口已经消失，另一个接口已经存在，则在计算针对特定ifIndex值的连续轮询中检索到的计数器值之间的差值时，不得混淆。
When the new interface is the same as an old interface, but a discontinuity in the value of the interface's counters cannot be avoided, the ifTable has (until now) required that a new ifIndex value be assigned to the returning interface. That is, either all counter values have had to be retained during the absence of an interface in order to use the same ifIndex value on that interface's return, or else a new ifIndex value has had to be assigned to the returning interface. Both alternatives have proved to be burdensome to some implementations:
当新接口与旧接口相同，但无法避免接口计数器值的不连续性时，ifTable（直到现在）要求为返回接口分配新的ifIndex值。也就是说，在没有接口的情况下，必须保留所有计数器值，以便在该接口的返回上使用相同的ifIndex值，或者必须为返回接口分配新的ifIndex值。事实证明，这两种备选方案对某些实现来说都很麻烦：
(1) maintaining the counter values may not be possible (e.g., if they are maintained on removable hardware),
(1) 可能无法保持计数器值（例如，如果计数器值保持在可移动硬件上），
(2) using a new ifIndex value presents extra work for management applications. While the potential need for such extra work is unavoidable on agent re-initializations, it is desirable to avoid it between re-initializations.
(2) 使用新的ifIndex值会为管理应用程序带来额外的工作。虽然在代理重新初始化时不可避免地需要额外的工作，但最好在重新初始化之间避免。
To address this, a new object, ifCounterDiscontinuityTime, has been defined to record the time of the last discontinuity in an interface's counters. By monitoring the value of this new object, a management application can now detect counter discontinuities without the ifIndex value of the interface being changed. Thus, an agent which implements this new object should, when a new interface is the same as an old interface, retain that interface's ifIndex value and update if necessary the interface's value of ifCounterDiscontinuityTime. With this new object, a management application must, when calculating differences between counter values retrieved on successive polls, discard any calculated difference for which the value of ifCounterDiscontinuityTime is different for the two polls. (Note that this test must be performed in addition to the normal checking of sysUpTime to detect an agent re-initialization.) Since such discards are a waste of network management processing and bandwidth, an agent should not update the value of ifCounterDiscontinuityTime unless absolutely necessary.
为了解决这个问题，定义了一个新对象ifcounterinterruptiontime来记录接口计数器中最后一次不连续的时间。通过监视此新对象的值，管理应用程序现在可以检测计数器不连续性，而无需更改接口的ifIndex值。因此，当新接口与旧接口相同时，实现此新对象的代理应保留该接口的ifIndex值，并在必要时更新接口的IFCounteryTime值。使用此新对象，管理应用程序在计算连续轮询中检索到的计数器值之间的差异时，必须放弃两次轮询的ifCounterIntercontinuctionTime值不同的任何计算差异。（请注意，除了正常检查sysUpTime以检测代理重新初始化外，还必须执行此测试。）由于此类丢弃是对网络管理处理和带宽的浪费，除非绝对必要，否则代理不应更新ifcounterytime的值。
While defining this new object is a change in the semantics of the ifTable counter objects, it is impractical to deprecate and redefine
虽然定义这个新对象是ifTable计数器对象语义的一个变化，但不推荐和重新定义它是不切实际的
all these counters because of their wide deployment and importance. Also, a survey of implementations indicates that many agents and management applications do not correctly implement this aspect of the current semantics (because of the burdensome issues mentioned above), such that the practical implications of such a change is small. Thus, this breach of the SMI's rules is considered to be acceptable.
所有这些计数器都是因为它们的广泛部署和重要性。此外，对实现的调查表明，许多代理和管理应用程序没有正确实现当前语义的这一方面（因为上面提到的繁重问题），因此这种更改的实际影响很小。因此，这种违反SMI规则的行为被认为是可以接受的。
Note, however, that the addition of ifCounterDiscontinuityTime does not change the fact that:
但是，请注意，添加IFCounteryTime不会改变以下事实：
it is necessary at certain times for the assignment of ifIndex values to change on a re-initialization of the agent (such as a reboot).
在某些时候，重新初始化代理（如重新启动）时，ifIndex值的分配必须更改。
The possibility of ifIndex value re-assignment must be accommodated by a management application whenever the value of sysUpTime is reset to zero.
每当sysUpTime的值重置为零时，管理应用程序必须考虑ifIndex值重新分配的可能性。
Note also that some agents support multiple "naming scopes", e.g., for an SNMPv1 agent, multiple values of the SNMPv1 community string. For such an agent (e.g., a CNM agent which supports a different subset of interfaces for different customers), there is no required relationship between the ifIndex values which identify interfaces in one naming scope and those which identify interfaces in another naming scope. It is the agent's choice as to whether the same or different ifIndex values identify the same or different interfaces in different naming scopes.
还请注意，一些代理支持多个“命名范围”，例如，对于SNMPv1代理，SNMPv1社区字符串的多个值。对于此类代理（例如，支持不同客户的不同接口子集的CNM代理），标识一个命名范围内接口的ifIndex值与标识另一个命名范围内接口的ifIndex值之间没有必要的关系。相同或不同的ifIndex值在不同的命名范围内标识相同或不同的接口，这是代理的选择。
Because of the restriction of the value of ifIndex to be less than ifNumber, interfaces have been numbered with small integer values. This has led to the ability by humans to use the ifIndex values as (somewhat) user-friendly names for network interfaces (e.g., "interface number 3"). With the relaxation of the restriction on the value of ifIndex, there is now the possibility that ifIndex values could be assigned as very large numbers (e.g., memory addresses). Such numbers would be much less user-friendly. Therefore, this memo recommends that ifIndex values still be assigned as (relatively) small integer values starting at 1, even though the values in use at any one time are not necessarily contiguous. (Note that this makes remembering which values have been assigned easy for agents which dynamically add new interfaces)
由于ifIndex的值限制为小于ifNumber，因此已使用小整数值对接口进行编号。这使得人类能够使用ifIndex值作为（某种程度上）网络接口的用户友好名称（例如，“接口编号3”）。随着对ifIndex值限制的放宽，现在有可能将ifIndex值指定为非常大的数字（例如，内存地址）。这样的数字对用户来说就不那么友好了。因此，本备忘录建议ifIndex值仍然从1开始分配为（相对）较小的整数值，即使在任何时候使用的值不一定是连续的。（请注意，这使得动态添加新接口的代理很容易记住已分配的值）
A new problem is introduced by representing each sub-layer as an ifTable entry. Previously, there usually was a simple, direct, mapping of interfaces to the physical ports on systems. This mapping would be based on the ifIndex value. However, by having an ifTable entry for each interface sub-layer, mapping from interfaces to physical ports becomes increasingly problematic.
通过将每个子层表示为ifTable条目，引入了一个新问题。以前，系统上通常有一个简单、直接的接口到物理端口的映射。此映射将基于ifIndex值。但是，由于每个接口子层都有一个ifTable条目，因此从接口到物理端口的映射变得越来越困难。
To address this issue, a new object, ifName, is added to the MIB. This object contains the device's local name (e.g., the name used at the device's local console) for the interface of which the relevant entry in the ifTable is a component. For example, consider a router having an interface composed of PPP running over an RS-232 port. If the router uses the name "wan1" for the (combined) interface, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would both have the value "wan1". On the other hand, if the router uses the name "wan1.1" for the PPP interface and "wan1.2" for the RS-232 port, then the ifName objects for the corresponding PPP and RS-232 entries in the ifTable would have the values "wan1.1" and "wan1.2", respectively. As an another example, consider an agent which responds to SNMP queries concerning an interface on some other (proxied) device: if such a proxied device associates a particular identifier with an interface, then it is appropriate to use this identifier as the value of the interface's ifName, since the local console in this case is that of the proxied device.
为了解决这个问题，在MIB中添加了一个新对象ifName。此对象包含设备的本地名称（例如，设备本地控制台上使用的名称），ifTable中的相关条目是接口的一个组件。例如，考虑一个路由器，该路由器具有一个由PP-P在RS-232端口上运行的接口。如果路由器为（组合）接口使用名称“wan1”，则ifTable中对应PPP和RS-232条目的ifName对象都将具有值“wan1”。另一方面，如果路由器对PPP接口使用名称“wan1.1”，对RS-232端口使用名称“wan1.2”，则ifTable中对应PPP和RS-232条目的ifName对象将分别具有值“wan1.1”和“wan1.2”。作为另一个示例，考虑一个响应SNMP查询的代理，该SNMP查询与其他（代理）设备上的接口有关：如果这样的代理设备将特定标识符与接口相关联，则使用该标识符作为接口的IFNITE的值是合适的，因为本例中的本地控制台是代理设备的控制台。
In contrast, the existing ifDescr object is intended to contain a description of an interface, whereas another new object, ifAlias, provides a location in which a network management application can store a non-volatile interface-naming value of its own choice. The ifAlias object allows a network manager to give one or more interfaces their own unique names, irrespective of any interface-stack relationship. Further, the ifAlias name is non-volatile, and thus an interface must retain its assigned ifAlias value across reboots, even if an agent chooses a new ifIndex value for the interface.
相比之下，现有的ifDescr对象旨在包含接口的描述，而另一个新对象ifAlias提供了一个位置，网络管理应用程序可以在其中存储自己选择的非易失性接口命名值。ifAlias对象允许网络管理器为一个或多个接口指定其自己的唯一名称，而不考虑任何接口堆栈关系。此外，ifAlias名称是非易失性的，因此即使代理为接口选择了新的ifIndex值，接口在重新启动期间也必须保留其分配的ifAlias值。
As the speed of network media increase, the minimum time in which a 32 bit counter will wrap decreases. For example, a 10Mbs stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes; at 100Mbs, the minimum wrap time is 5.7 minutes, and at 1Gbs, the minimum is 34 seconds. Requiring that interfaces be polled frequently enough not to miss a counter wrap is increasingly problematic.
随着网络媒体速度的增加，32位计数器的最小换行时间缩短。例如，一个10Mbs的背对背、全尺寸数据包流会导致IFinocts在57分钟内完成打包；100Mbs时，最小换行时间为5.7分钟，1Gbs时，最小换行时间为34秒。要求对接口进行足够频繁的轮询，以避免遗漏计数器包装，这一点越来越成问题。
A rejected solution to this problem was to scale the counters; for example, ifInOctets could be changed to count received octets in, say, 1024 byte blocks. While it would provide acceptable functionality at high rates of the counted-events, at low rates it suffers. If there is little traffic on an interface, there might be a significant interval before enough of the counted-events occur to cause the scaled counter to be incremented. Traffic would then appear to be very bursty, leading to incorrect conclusions of the network's performance.
这个问题的一个被拒绝的解决方案是缩放计数器；例如，ifInOctets可以更改为在1024字节块中计算接收到的八位字节。虽然它可以在高计数率的情况下提供可接受的功能，但在低计数率的情况下，它会受到影响。如果接口上的通信量很少，则在发生足够多的已计数事件以导致缩放计数器递增之前，可能会有一段很长的时间间隔。然后，流量会显得非常突发，导致对网络性能的错误结论。
Instead, this memo adopts expanded, 64 bit, counters. These counters are provided in new "high capacity" groups. The old, 32-bit, counters have not been deprecated. The 64-bit counters are to be used only when the 32-bit counters do not provide enough capacity; that is, when the 32 bit counters could wrap too fast.
相反，此备忘录采用扩展的64位计数器。这些计数器以新的“高容量”组提供。旧的32位计数器尚未弃用。仅当32位计数器不能提供足够的容量时，才使用64位计数器；也就是说，当32位计数器包装得太快时。
For interfaces that operate at 20,000,000 (20 million) bits per second or less, 32-bit byte and packet counters MUST be supported. For interfaces that operate faster than 20,000,000 bits/second, and slower than 650,000,000 bits/second, 32-bit packet counters MUST be supported and 64-bit octet counters MUST be supported. For interfaces that operate at 650,000,000 bits/second or faster, 64-bit packet counters AND 64-bit octet counters MUST be supported.
对于每秒运行20000000（2000万）位或更少的接口，必须支持32位字节和数据包计数器。对于操作速度超过20000000位/秒、速度低于650000000位/秒的接口，必须支持32位数据包计数器，并且必须支持64位八位字节计数器。对于以650000000位/秒或更快速度运行的接口，必须支持64位数据包计数器和64位八位字节计数器。
These speed thresholds were chosen as reasonable compromises based on the following:
选择这些速度阈值作为合理的折衷方案，依据如下：
(1) The cost of maintaining 64-bit counters is relatively high, so minimizing the number of agents which must support them is desirable. Common interfaces (such as 10Mbs Ethernet) should not require them.
(1) 维护64位计数器的成本相对较高，因此尽可能减少必须支持它们的代理的数量是可取的。通用接口（如10Mbs以太网）不需要它们。
(2) 64-bit counters are a new feature, introduced in the SMIv2. It is reasonable to expect that support for them will be spotty for the immediate future. Thus, we wish to limit them to as few systems as possible. This, in effect, means that 64-bit counters should be limited to higher speed interfaces. Ethernet (10,000,000 bps) and Token Ring (16,000,000 bps) are fairly wide-spread so it seems reasonable to not require 64-bit counters for these interfaces.
(2) 64位计数器是SMIv2中引入的一项新功能。有理由预计，在不久的将来，对他们的支持将是不稳定的。因此，我们希望将它们限制在尽可能少的系统中。实际上，这意味着64位计数器应限于更高速度的接口。以太网（10000000 bps）和令牌环（16000000 bps）分布相当广泛，因此这些接口不需要64位计数器似乎是合理的。
(3) The 32-bit octet counters will wrap in the following times, for the following interfaces (when transmitting maximum-sized packets back-to-back):
(3) 对于以下接口，32位八位计数器将在以下时间内换行（在背对背传输最大大小的数据包时）：
- 10Mbs Ethernet: 57 minutes,
- 10Mbs以太网：57分钟，
- 16Mbs Token Ring: 36 minutes,
- 16Mbs令牌环：36分钟，
- a US T3 line (45 megabits): 12 minutes,
- 美国T3线路（45兆位）：12分钟，
- FDDI: 5.7 minutes
- FDDI:5.7分钟
(4) The 32-bit packet counters wrap in about 57 minutes when 64- byte packets are transmitted back-to-back on a 650,000,000 bit/second link.
(4) 当64字节的数据包在650000000位/秒的链路上背靠背传输时，32位数据包计数器大约需要57分钟。
As an aside, a 1-terabit/second (1,000 Gbs) link will cause a 64 bit octet counter to wrap in just under 5 years. Conversely, an 81,000,000 terabit/second link is required to cause a 64-bit counter to wrap in 30 minutes. We believe that, while technology rapidly marches forward, this link speed will not be achieved for at least several years, leaving sufficient time to evaluate the introduction of 96 bit counters.
另一方面，1TB/秒（1000Gbs）的链路将导致64位八位字节计数器在不到5年的时间内完成封装。相反，需要81000000 TB/秒的链路才能使64位计数器在30分钟内结束。我们相信，在技术飞速发展的同时，这种链路速度至少在几年内无法实现，因此有足够的时间来评估96位计数器的引入。
When 64-bit counters are in use, the 32-bit counters MUST still be available. They will report the low 32-bits of the associated 64-bit count (e.g., ifInOctets will report the least significant 32 bits of ifHCInOctets). This enhances inter-operability with existing implementations at a very minimal cost to agents.
使用64位计数器时，32位计数器必须仍然可用。它们将报告相关64位计数的低32位（例如，ifInOctets将报告ifHCInOctets的最低有效32位）。这增强了与现有实现的互操作性，而代理的成本非常低。
The new "high capacity" groups are:
新的“高容量”组包括：
(1) the ifHCFixedLengthGroup for character-oriented/fixed-length interfaces, and the ifHCPacketGroup for packet-based interfaces; both of these groups include 64 bit counters for octets, and
(1) 面向字符/固定长度接口的ifHCFixedLengthGroup和基于数据包接口的ifHCPacketGroup；这两个组都包括用于八位字节的64位计数器，以及
(2) the ifVHCPacketGroup for packet-based interfaces; this group includes 64 bit counters for octets and packets.
(2) 用于基于分组的接口的ifVHCPacketGroup；该组包括用于八位字节和数据包的64位计数器。
Network speeds are increasing. The range of ifSpeed is limited to reporting a maximum speed of (2**31)-1 bits/second, or approximately 2.2Gbs. SONET defines an OC-48 interface, which is defined at operating at 48 times 51 Mbs, which is a speed in excess of 2.4Gbs. Thus, ifSpeed is insufficient for the future, and this memo defines an additional object: ifHighSpeed.
网络速度正在提高。ifSpeed的范围限于报告最大速度（2**31）-1位/秒，或约2.2Gbs。SONET定义了一个OC-48接口，定义为以48乘以51 Mbs的速度运行，即超过2.4Gbs的速度。因此，ifSpeed对于未来是不够的，本备忘录定义了一个额外的对象：ifHighSpeed。
The ifHighSpeed object reports the speed of the interface in 1,000,000 (1 million) bits/second units. Thus, the true speed of the interface will be the value reported by this object, plus or minus 500,000 bits/second.
ifHighSpeed对象以1000000（一百万）位/秒为单位报告接口速度。因此，接口的真实速度将是该对象报告的值，加上或减去500000位/秒。
Other alternatives considered (but rejected) were:
考虑（但被拒绝）的其他备选方案包括：
(1) Making the interface speed a 64-bit gauge. This was rejected since the current SMI does not allow such a syntax.
(1) 使接口速度成为64位标准。这被拒绝，因为当前SMI不允许这种语法。
Furthermore, even if 64-bit gauges were available, their use would require additional complexity in agents due to an increased requirement for 64-bit operations.
此外，即使64位仪表可用，由于对64位操作的要求增加，它们的使用也需要在代理中增加复杂性。
(2) We also considered making "high-32 bit" and "low-32-bit" objects which, when combined, would be a 64-bit value. This simply seemed overly complex for what we are trying to do.
(2) 我们还考虑制作“高32位”和“低32位”对象，当组合起来时，它们将是64位值。对于我们正在尝试做的事情来说，这似乎过于复杂了。
Furthermore, a full 64-bits of precision does not seem necessary. The value of ifHighSpeed will be the only report of interface speed for interfaces that are faster than 4,294,967,295 bits per second. At this speed, the granularity of ifHighSpeed will be 1,000,000 bits per second, thus the error will be 1/4294, or about 0.02%. This seems reasonable.
此外，完整的64位精度似乎没有必要。ifHighSpeed的值将是速度超过每秒4294967295位的接口的唯一接口速度报告。在此速度下，ifHighSpeed的粒度将为每秒1000000位，因此误差将为1/4294，或约0.02%。这似乎是合理的。
(3) Adding a "scale" object, which would define the units which ifSpeed's value is.
(3) 添加一个“缩放”对象，该对象将定义ifSpeed值的单位。
This would require two additional objects; one for the scaling object, and one to replace the current ifSpeed. This later object is required since the semantics of ifSpeed would be significantly altered, and manager stations which do not understand the new semantics would be confused.
这将需要两个额外的对象；一个用于缩放对象，另一个用于替换当前ifSpeed。由于ifSpeed的语义将发生显著变化，因此需要使用后面的对象，并且不理解新语义的管理站将被混淆。
In MIB-II, the ifTable counters for multicast and broadcast packets are combined as counters of non-unicast packets. In contrast, the ifExtensions MIB [19] defined one set of counters for multicast, and a separate set for broadcast packets. With the separate counters, the original combined counters become redundant. To avoid this redundancy, the non-unicast counters are deprecated.
在MIB-II中，多播和广播数据包的ifTable计数器组合为非单播数据包的计数器。相反，ifExtensions MIB[19]为多播定义了一组计数器，为广播数据包定义了一组单独的计数器。使用单独的计数器时，原始的组合计数器将变得冗余。为了避免这种冗余，不推荐使用非单播计数器。
For the output broadcast and multicast counters defined in RFC 1229, their definitions varied slightly from the packet counters in the ifTable, in that they did not count errors/discarded packets. Thus, this memo defines new objects with better aligned definitions. Counters with 64 bits of range are also needed, as explained above.
对于RFC 1229中定义的输出广播和多播计数器，它们的定义与ifTable中的包计数器略有不同，因为它们不计算错误/丢弃的包。因此，本备忘录定义了具有更好对齐定义的新对象。如上所述，还需要具有64位范围的计数器。
In the multi-layer interface model, each sub-layer for which there is an entry in the ifTable can generate linkUp/linkDown Traps. Since interface state changes would tend to propagate through the interface (from top to bottom, or bottom to top), it is likely that several traps would be generated for each linkUp/linkDown occurrence.
在多层接口模型中，ifTable中有条目的每个子层都可以生成linkUp/linkDown陷阱。由于接口状态更改将倾向于通过接口传播（从上到下，或从下到上），因此很可能会为每个linkUp/linkDown事件生成多个陷阱。
It is desirable to provide a mechanism for manager stations to control the generation of these traps. To this end, the ifLinkUpDownTrapEnable object has been added. This object allows managers to limit generation of traps to just the sub-layers of interest.
希望为管理站提供一种机制来控制这些陷阱的产生。为此，添加了iflinkupdowntrappenable对象。此对象允许管理员将陷阱的生成限制为仅感兴趣的子层。
The default setting should limit the number of traps generated to one per interface per linkUp/linkDown event. Furthermore, it seems that the state changes of most interest to network managers occur at the lowest level of an interface stack. Therefore we specify that by default, only the lowest sub-layer of the interface generate traps.
默认设置应将每个linkUp/linkDown事件每个接口生成的陷阱数量限制为一个。此外，网络管理器最感兴趣的状态更改似乎发生在接口堆栈的最低级别。因此，我们指定默认情况下，只有接口的最低子层生成陷阱。
Over time, there is the need to add new ifType enumerated values for new interface types. If the syntax of ifType were defined in the MIB in section 6, then a new version of this MIB would have to be re-issued in order to define new values. In the past, re-issuing of a MIB has occurred only after several years.
随着时间的推移，需要为新接口类型添加新的ifType枚举值。如果在第6节的MIB中定义了ifType的语法，则必须重新发布此MIB的新版本，以便定义新值。在过去，只有在几年之后才重新发布MIB。
Therefore, the syntax of ifType is changed to be a textual convention, such that the enumerated integer values are now defined in the textual convention, IANAifType, defined in a different document. This allows additional values to be documented without having to re-issue a new version of this document. The Internet Assigned Number Authority (IANA) is responsible for the assignment of all Internet numbers, including various SNMP-related numbers, and specifically, new ifType values.
因此，ifType的语法更改为文本约定，因此枚举的整数值现在在不同文档中定义的文本约定IANAifType中定义。这允许记录附加值，而无需重新发布本文件的新版本。Internet分配号码管理局（IANA）负责分配所有Internet号码，包括各种SNMP相关号码，特别是新的ifType值。
A new textual convention, InterfaceIndex, has been defined. This textual convention "contains" all of the semantics of the ifIndex object. This allows other MIB modules to easily import the semantics of ifIndex.
定义了一个新的文本约定InterfaceIndex。此文本约定“包含”ifIndex对象的所有语义。这允许其他MIB模块轻松导入ifIndex的语义。
Three new states have been added to ifOperStatus: 'dormant', 'notPresent', and 'lowerLayerDown'.
iOperStatus中添加了三个新状态：“休眠”、“不存在”和“lowerLayerDown”。
The dormant state indicates that the relevant interface is not actually in a condition to pass packets (i.e., it is not 'up') but is in a "pending" state, waiting for some external event. For "on-demand" interfaces, this new state identifies the situation where the interface is waiting for events to place it in the up state. Examples of such events might be:
休眠状态表示相关接口实际上不处于传递数据包的状态（即，它不是“启动”），而是处于“挂起”状态，等待某些外部事件。对于“按需”接口，此新状态标识接口等待事件将其置于启动状态的情况。此类事件的例子可能是：
(1) having packets to transmit before establishing a connection to a remote system;
(1) 在建立到远程系统的连接之前具有要传输的分组；
(2) having a remote system establish a connection to the interface (e.g. dialing up to a slip-server).
(2) 让远程系统与接口建立连接（例如，拨打slip服务器）。
The notPresent state is a refinement on the down state which indicates that the relevant interface is down specifically because some component (typically, a hardware component) is not present in the managed system. Examples of use of the notPresent state are:
notPresent状态是对down状态的细化，表示相关接口关闭，具体原因是某些组件（通常是硬件组件）不在受管系统中。使用notPresent状态的示例有：
(1) to allow an interface's conceptual row including its counter values to be retained across a "hot swap" of a card/module, and/or
(1) 允许在卡/模块的“热插拔”中保留接口的概念行（包括其计数器值），和/或
(2) to allow an interface's conceptual row to be created, and thereby enable interfaces to be pre-configured prior to installation of the hardware needed to make the interface operational.
(2) 允许创建接口的概念行，从而允许在安装使接口运行所需的硬件之前预先配置接口。
Agents are not required to support interfaces in the notPresent state. However, from a conceptual viewpoint, when a row in the ifTable is created, it first enters the notPresent state and then subsequently transitions into the down state; similarly, when a row in the ifTable is deleted, it first enters the notPresent state and then subsequently the object instances are deleted. For an agent with no support for notPresent, both of these transitions (from the notPresent state to the down state, and from the notPresent state to the instances being removed) are immediate, i.e., the transition does not last long enough to be recorded by ifOperStatus. Even for those agents which do support interfaces in the notPresent state, the length of time and conditions under which an interface stays in the notPresent state is implementation-specific.
代理不需要支持notPresent状态下的接口。然而，从概念上看，当ifTable中的一行被创建时，它首先进入notPresent状态，然后过渡到down状态；类似地，删除ifTable中的行时，它首先进入notPresent状态，然后删除对象实例。对于不支持notPresent的代理，这两种转换（从notPresent状态到down状态，以及从notPresent状态到要删除的实例）都是即时的，即转换持续的时间不足以由iOperStatus记录。即使对于那些支持notPresent状态下接口的代理，接口保持notPresent状态的时间长度和条件也是特定于实现的。
The lowerLayerDown state is also a refinement on the down state. This new state indicates that this interface runs "on top of" one or more other interfaces (see ifStackTable) and that this interface is down specifically because one or more of these lower-layer interfaces are down.
lowerLayerDown状态也是对down状态的改进。此新状态表示此接口在一个或多个其他接口（请参见ifStackTable）的“顶部”运行，并且此接口处于关闭状态，具体原因是一个或多个较低层接口处于关闭状态。
The down state of ifOperStatus now has two meanings, depending on the value of ifAdminStatus.
ifOperStatus的关闭状态现在有两种含义，具体取决于ifAdminStatus的值。
(1) if ifAdminStatus is not down and ifOperStatus is down then a fault condition is presumed to exist on the interface.
(1) 如果ifAdminStatus未关闭且IFOperatStatus关闭，则假定接口上存在故障。
(2) if ifAdminStatus is down, then ifOperStatus will normally also be down (or notPresent) i.e., there is not (necessarily) a fault condition on the interface.
(2) 如果ifAdminStatus关闭，则IFOperatStatus通常也会关闭（或不存在），即接口上不存在（必然）故障。
Note that when ifAdminStatus transitions to down, ifOperStatus will normally also transition to down. In this situation, it is possible
请注意，当ifAdminStatus转换为down时，ifOperStatus通常也会转换为down。在这种情况下，这是可能的
that ifOperStatus's transition will not occur immediately, but rather after a small time lag to complete certain operations before going "down"; for example, it might need to finish transmitting a packet. If a manager station finds that ifAdminStatus is down and ifOperStatus is not down for a particular interface, the manager station should wait a short while and check again. If the condition still exists, only then should it raise an error indication. Naturally, it should also ensure that ifLastChange has not changed during this interval.
ifOperStatus的转换不会立即发生，而是在一个小的时间间隔后完成某些操作，然后再“下降”；例如，它可能需要完成数据包的传输。如果管理站发现特定接口的ifAdminStatus已关闭且IFOperatStatus未关闭，则管理站应稍等片刻，然后再次检查。如果该情况仍然存在，则只有在该情况下才会发出错误指示。当然，它还应该确保ifLastChange在此期间没有发生变化。
Whenever an interface table entry is created (usually as a result of system initialization), the relevant instance of ifAdminStatus is set to down, and ifOperStatus will be down or notPresent.
每当创建接口表条目时（通常是系统初始化的结果），ifAdminStatus的相关实例将设置为down，而ifOperStatus将为down或notPresent。
An interface may be enabled in two ways: either as a result of explicit management action (e.g. setting ifAdminStatus to up) or as a result of the managed system's initialization process. When ifAdminStatus changes to the up state, the related ifOperStatus should do one of the following:
接口可以通过两种方式启用：一种是由于明确的管理操作（例如，将ifAdminStatus设置为up），另一种是由于受管系统的初始化过程。当ifAdminStatus更改为up状态时，相关ifOperStatus应执行以下操作之一：
(1) Change to the up state if and only if the interface is able to send and receive packets.
(1) 当且仅当接口能够发送和接收数据包时，才更改为up状态。
(2) Change to the lowerLayerDown state if and only if the interface is prevented from entering the up state because of the state of one or more of the interfaces beneath it in the interface stack.
(2) 当且仅当由于接口堆栈中其下方的一个或多个接口的状态而阻止接口进入向上状态时，才更改为lowerLayerDown状态。
(3) Change to the dormant state if and only if the interface is found to be operable, but the interface is waiting for other, external, events to occur before it can transmit or receive packets. Presumably when the expected events occur, the interface will then change to the up state.
(3) 当且仅当发现接口可操作，但接口在发送或接收数据包之前正在等待其他外部事件发生时，才更改为休眠状态。假设在预期事件发生时，接口将更改为up状态。
(4) Remain in the down state if an error or other fault condition is detected on the interface.
(4) 如果在接口上检测到错误或其他故障情况，则保持关闭状态。
(5) Change to the unknown state if, for some reason, the state of the interface can not be ascertained.
(5) 如果由于某种原因无法确定接口的状态，则更改为未知状态。
(6) Change to the testing state if some test(s) must be performed on the interface. Presumably after completion of the test, the interface's state will change to up, dormant, or down, as appropriate.
(6) 如果必须对接口执行某些测试，则更改为测试状态。大概在测试完成后，接口的状态将根据需要更改为up、休眠或down。
(7) Remain in the notPresent state if interface components are missing.
(7) 如果缺少接口组件，则保持notPresent状态。
When an interface is a part of an interface-stack, but is not the lowest interface in the stack, then:
如果接口是接口堆栈的一部分，但不是堆栈中的最低接口，则：
(1) ifOperStatus has the value 'up' if it is able to pass packets due to one or more interfaces below it in the stack being 'up', irrespective of whether other interfaces below it are 'down', ' dormant', 'notPresent', 'lowerLayerDown', 'unknown' or ' testing'.
(1) 如果由于堆栈中它下面的一个或多个接口处于“向上”状态，而不管它下面的其他接口是“向下”、“休眠”、“不存在”、“lowerLayerDown”、“未知”还是“测试”，ifOperStatus能够传递数据包，则其值为“向上”。
(2) ifOperStatus may have the value 'up' or 'dormant' if one or more interfaces below it in the stack are 'dormant', and all others below it are either 'down', 'dormant', 'notPresent', ' lowerLayerDown', 'unknown' or 'testing'.
(2) 如果栈中其下方的一个或多个接口处于“休眠”状态，且其下方的所有其他接口处于“关闭”、“休眠”、“不存在”、“lowerLayerDown”、“未知”或“测试”状态，则ifOperStatus的值可能为“向上”或“休眠”。
(3) ifOperStatus has the value 'lowerLayerDown' while all interfaces below it in the stack are either 'down', ' notPresent', 'lowerLayerDown', or 'testing'.
(3) ifOperStatus的值为“lowerLayerDown”，而堆栈中它下面的所有接口都是“down”、“notPresent”、“lowerLayerDown”或“testing”。
The exact definition of when linkUp and linkDown traps are generated has been changed to reflect the changes to ifAdminStatus and ifOperStatus. Operational experience indicates that management stations are most concerned with an interface being in the down state and the fact that this state may indicate a failure. Thus, it is most useful to instrument transitions into/out of either the up state or the down state.
关于何时生成linkUp和linkDown陷阱的确切定义已更改，以反映对ifAdminStatus和ifOperStatus的更改。运行经验表明，管理站最关心的是处于关闭状态的接口，以及该状态可能指示故障的事实。因此，最有用的是对进入/退出上升状态或下降状态的转换进行检测。
Instrumenting transitions into or out of the up state was rejected since it would have the drawback that a demand interface might have many transitions between up and dormant, leading to many linkUp traps and no linkDown traps. Furthermore, if a node's only interface is the demand interface, then a transition to dormant would entail generation of a linkDown trap, necessitating bringing the link to the up state (and a linkUp trap)!!
检测进入或退出up状态的转换被拒绝，因为这将有一个缺点，即请求接口可能在up和休眠之间有许多转换，从而导致许多链接陷阱而没有链接陷阱。此外，如果节点的唯一接口是demand接口，那么向休眠状态的转换将导致产生链路断开陷阱，从而使链路进入上行状态（和链路断开陷阱）！！
On the other hand, instrumenting transitions into or out of the down state (to/from all other states except notPresent) has the advantages:
另一方面，检测进入或退出关闭状态（到/来自除notPresent之外的所有其他状态）的转换具有以下优点：
(1) A transition into the down state (from a state other than notPresent) will occur when an error is detected on an interface. Error conditions are presumably of great interest to network managers.
(1) 当在接口上检测到错误时，将发生向下状态（从notPresent以外的状态）的转换。网络管理员可能对错误条件非常感兴趣。
(2) Departing the down state (to a state other than the notPresent state) generally indicates that the interface is going to either up or dormant, both of which are considered "healthy" states.
(2) 离开down状态（到notPresent状态以外的状态）通常表示接口将进入up或休眠状态，这两种状态都被视为“健康”状态。
Furthermore, it is believed that generating traps on transitions into or out of the down state (except to/from the notPresent state) is generally consistent with current usage and interpretation of these traps by manager stations.
此外，人们认为，在进入或离开关闭状态（除了到/从不存在状态）的转换上生成陷阱通常与管理站对这些陷阱的当前使用和解释一致。
Transitions to/from the notPresent state are concerned with the insertion and removal of hardware, and are outside the scope of these traps.
从notPresent状态到notPresent状态的转换与硬件的插入和移除有关，不在这些陷阱的范围之内。
Therefore, this memo defines that LinkUp and linkDown traps are generated just after ifOperStatus leaves, or just before it enters, the down state, respectively; except that LinkUp and linkDown traps are never generated on transitions to/from the notPresent state. For the purpose of deciding when these traps occur, the lowerLayerDown state and the down state are considered to be equivalent, i.e., there is no trap on transition from lowerLayerDown into down, and there is a trap on transition from any other state except down (and notPresent) into lowerLayerDown.
因此，此备忘录定义了LinkUp和linkDown陷阱分别在iOperStatus离开后或进入down状态前生成；除了在转换到notPresent状态或从notPresent状态转换到notPresent状态时从不生成LinkUp和linkDown陷阱。为了确定这些陷阱何时出现，lowerLayerDown状态和down状态被认为是等效的，即从lowerLayerDown过渡到down时没有陷阱，从down（且不存在）到lowerLayerDown之外的任何其他状态过渡时都有陷阱。
Note that this definition allows a node with only one interface to transmit a linkDown trap before that interface goes down. (Of course, when the interface is going down because of a failure condition, the linkDown trap probably cannot be successfully transmitted anyway.)
请注意，此定义允许只有一个接口的节点在该接口关闭之前发送链路关闭陷阱。（当然，当接口因故障条件而关闭时，链路关闭陷阱可能无论如何都无法成功传输。）
Some interfaces perform a link "training" function when trying to bring the interface up. In the event that such an interface were defective, then the training function would fail and the interface would remain down, and the training function might be repeated at appropriate intervals. If the interface, while performing this training function, were considered to the in the testing state, then linkUp and linkDown traps would be generated for each start and end of the training function. This is not the intent of the linkUp and linkDown traps, and therefore, while performing such a training function, the interface's state should be represented as down.
某些接口在尝试打开接口时执行链接“培训”功能。如果这样的接口有缺陷，那么培训功能将失败，接口将保持关闭状态，培训功能可能会在适当的时间间隔重复。如果在执行此培训功能时，接口被认为处于测试状态，则将为培训功能的每个开始和结束生成linkUp和linkDown陷阱。这不是linkUp和linkDown陷阱的目的，因此，在执行此类培训功能时，接口的状态应表示为down。
An exception to the above generation of linkUp/linkDown traps on changes in ifOperStatus, occurs when an interface is "flapping", i.e., when it is rapidly oscillating between the up and down states. If traps were generated for each such oscillation, the network and the network management system would be flooded with unnecessary traps. In such a situation, the agent should limit the rate at which it generates traps.
当接口“拍打”时，即当接口在向上和向下状态之间快速振荡时，会发生ifOperStatus变化时上述生成的linkUp/linkDown陷阱的例外情况。如果每次振荡都产生陷阱，那么网络和网络管理系统将充满不必要的陷阱。在这种情况下，代理应限制其生成陷阱的速率。
The original definition of the OBJECT IDENTIFIER value of ifSpecific
was not sufficiently clear. As a result, different implementors used
it differently, and confusion resulted. Some implementations set the
value of ifSpecific to the OBJECT IDENTIFIER that defines the media-
specific MIB, i.e., the "foo" of:
foo OBJECT IDENTIFIER ::= { transmission xxx }
The original definition of the OBJECT IDENTIFIER value of ifSpecific
was not sufficiently clear. As a result, different implementors used
it differently, and confusion resulted. Some implementations set the
value of ifSpecific to the OBJECT IDENTIFIER that defines the media-
specific MIB, i.e., the "foo" of:
foo OBJECT IDENTIFIER ::= { transmission xxx }
while others set it to be OBJECT IDENTIFIER of the specific table or entry in the appropriate media-specific MIB (i.e., fooTable or fooEntry), while still others set it be the OBJECT IDENTIFIER of the index object of the table's row, including instance identifier, (i.e., fooIfIndex.ifIndex). A definition based on the latter would not be sufficient unless it also allowed for media-specific MIBs which include several tables, where each table has its own (different) indexing.
其他人将其设置为相应媒体特定MIB中特定表或条目的对象标识符（即fooTable或fooEntry），而其他人将其设置为表行的索引对象的对象标识符，包括实例标识符（即FooiIndex.ifIndex）。基于后者的定义是不够的，除非它还允许包含多个表的媒体特定MIB，其中每个表都有自己的（不同的）索引。
The only definition that can both be made explicit and can cover all the useful situations is to have ifSpecific be the most general value for the media-specific MIB module (the first example given above). This effectively makes it redundant because it contains no more information than is provided by ifType. Thus, ifSpecific has been deprecated.
唯一一个既可以明确又可以涵盖所有有用情况的定义是将ifSpecific作为媒体特定MIB模块的最通用值（上面给出的第一个示例）。这实际上是多余的，因为它所包含的信息并不比ifType提供的信息多。因此，ifSpecific已被弃用。
While some interfaces, for example, most physical interfaces, cannot be created via network management, other interfaces such as logical interfaces sometimes can be. The ifTable contains only generic information about an interface. Almost all 'create-able' interfaces have other, media-specific, information through which configuration parameters may be supplied prior to creating such an interface. Thus, the ifTable does not itself support the creation or deletion of an interface (specifically, it has no RowStatus [6] column). Rather, if a particular interface type supports the dynamic creation and/or deletion of an interface of that type, then that media-specific MIB should include an appropriate RowStatus object (see the ATM LAN-Emulation Client MIB [20] for an example of a MIB which does this). Typically, when such a RowStatus object is created/deleted, then the conceptual row in the ifTable appears/disappears as a by-product, and an ifIndex value (chosen by the agent) is stored in an appropriate object in the media-specific MIB.
虽然某些接口（例如，大多数物理接口）无法通过网络管理创建，但其他接口（如逻辑接口）有时也可以创建。ifTable仅包含有关接口的一般信息。几乎所有“可创建”接口都有其他特定于媒体的信息，在创建此类接口之前，可以通过这些信息提供配置参数。因此，ifTable本身不支持创建或删除接口（具体来说，它没有RowStatus[6]列）。相反，如果特定接口类型支持动态创建和/或删除该类型的接口，则特定于媒体的MIB应包括适当的RowStatus对象（参见ATM LAN仿真客户机MIB[20]，了解执行此操作的MIB示例）。通常，当创建/删除此类RowStatus对象时，ifTable中的概念行作为副产品出现/消失，并且ifIndex值（由代理选择）存储在媒体特定MIB中的适当对象中。
There are a number of situations where an agent does not know the value of one or more objects for a particular interface. In all such circumstances, an agent MUST NOT instantiate an object with an incorrect value; rather, it MUST respond with the appropriate error/exception condition (e.g., noSuchInstance or noSuchName).
在许多情况下，代理不知道特定接口的一个或多个对象的值。在所有这些情况下，代理不能用错误的值实例化对象；相反，它必须使用适当的错误/异常条件（例如，noSuchInstance或noSuchName）进行响应。
One example is where an agent is unable to count the occurrences defined by one (or more) of the ifTable counters. In this circumstance, the agent MUST NOT instantiate the particular counter with a value of, say, zero. To do so would be to provide mis-information to a network management application reading the zero value, and thereby assuming that there have been no occurrences of the event (e.g., no input errors because ifInErrors is always zero).
一个示例是，代理无法统计由一个（或多个）ifTable计数器定义的事件。在这种情况下，代理不能实例化值为零的特定计数器。这样做就是向网络管理应用程序提供mis信息，读取零值，从而假设没有发生事件（例如，没有输入错误，因为IFinerror始终为零）。
Sometimes the lack of knowledge of an object's value is temporary. For example, when the MTU of an interface is a configured value and a device dynamically learns the configured value through (after) exchanging messages over the interface (e.g., ATM LAN-Emulation [20]). In such a case, the value is not known until after the ifTable entry has already been created. In such a case, the ifTable entry should be created without an instance of the object whose value is unknown; later, when the value becomes known, the missing object can then be instantiated (e.g., the instance of ifMtu is only instantiated once the interface's MTU becomes known).
有时，对一个对象的价值缺乏了解是暂时的。例如，当接口的MTU是配置值，并且设备通过（在）在接口上交换消息（例如，ATM LAN仿真[20]）来动态地学习配置值时。在这种情况下，在创建ifTable条目之前，该值是未知的。在这种情况下，应创建ifTable条目，而不创建值未知的对象实例；稍后，当值变为已知时，可以实例化缺少的对象（例如，只有在接口的MTU变为已知时，才会实例化ifMtu实例）。
As a result of this "known values" rule, management applications MUST be able to cope with the responses to retrieving the object instances within a conceptual row of the ifTable revealing that some of the row's columnar objects are missing/not available.
作为此“已知值”规则的结果，管理应用程序必须能够处理在ifTable的概念行中检索对象实例的响应，这表明该行的某些列对象丢失/不可用。
The exact use and semantics of many objects in this MIB are open to some interpretation. This is a result of the generic nature of this MIB. It is not always possible to come up with specific, unambiguous, text that covers all cases and yet preserves the generic nature of the MIB.
此MIB中许多对象的确切用法和语义可以进行一些解释。这是此MIB的通用性的结果。并非总是能够提出具体、明确的文本来涵盖所有情况，同时保留MIB的通用性。
Therefore, it is incumbent upon a media-specific MIB designer to, wherever necessary, clarify the use of the objects in this MIB with respect to the media-specific MIB.
因此，媒体特定MIB设计者有责任在必要时澄清该MIB中的对象相对于媒体特定MIB的使用。
Specific areas of clarification include
澄清的具体领域包括
Layering Model The media-specific MIB designer MUST completely and unambiguously specify the layering model used. Each individual sub-layer must be identified, as must the ifStackTable's portrayal of the relationship(s) between the sub-layers.
分层模型特定于媒体的MIB设计器必须完全明确地指定所使用的分层模型。必须识别每个单独的子层，以及ifStackTable对子层之间关系的描述。
Virtual Circuits The media-specific MIB designer MUST specify whether virtual circuits are assigned entries in the ifTable or not. If they are, compelling rationale must be presented.
虚拟电路特定于介质的MIB设计器必须指定是否在ifTable中为虚拟电路分配了条目。如果是，则必须提出令人信服的理由。
ifRcvAddressTable The media-specific MIB designer MUST specify the applicability of the ifRcvAddressTable.
ifRcvAddressTable特定于媒体的MIB设计器必须指定ifRcvAddressTable的适用性。
ifType For each of the ifType values to which the media-specific MIB applies, it must specify the mapping of ifType values to media-specific MIB module(s) and instances of MIB objects within those modules.
ifType对于媒体特定MIB应用的每个ifType值，必须指定ifType值到媒体特定MIB模块的映射以及这些模块中MIB对象的实例。
ifXxxOctets The definitions of ifInOctets and ifOutOctets (and similarly, ifHCInOctets and ifHCOutOctets) specify that their values include framing characters. The media-specific MIB designer MUST specify any special conditions of the media concerning the inclusion of framing characters, especially with respect to frames with errors.
ifXxxOctets IFNOCTTETS和IFOUTPOCTETS（类似地，ifHCInOctets和IFHCOUTPOCTETS）的定义指定其值包括帧字符。特定于媒体的MIB设计器必须指定与包含帧字符有关的媒体的任何特殊条件，特别是关于有错误的帧。
However, wherever this interface MIB is specific in the semantics, DESCRIPTION, or applicability of objects, the media-specific MIB designer MUST NOT change said semantics, DESCRIPTION, or applicability.
但是，只要此接口MIB在对象的语义、描述或适用性方面是特定的，则特定于媒体的MIB设计器不得更改所述语义、描述或适用性。
This MIB consists of 4 tables:
此MIB由4个表组成：
ifTable This table is the ifTable from MIB-II.
ifTable此表是MIB-II的ifTable。
ifXTable This table contains objects that have been added to the Interface MIB as a result of the Interface Evolution effort, or replacements for objects of the original (MIB-II) ifTable that were deprecated
ifXTable此表包含由于接口演化工作而添加到接口MIB的对象，或替换已弃用的原始（MIB-II）ifTable对象
because the semantics of said objects have significantly changed. This table also contains objects that were previously in the ifExtnsTable.
因为所述对象的语义发生了显著变化。此表还包含以前在ifExtnsTable中的对象。
ifStackTable This table contains objects that define the relationships among the sub-layers of an interface.
ifStackTable此表包含定义接口子层之间关系的对象。
ifRcvAddressTable This table contains objects that are used to define the media-level addresses which this interface will receive. This table is a generic table. The designers of media-specific MIBs must define exactly how this table applies to their specific MIB.
ifRcvAddressTable此表包含用于定义此接口将接收的媒体级地址的对象。此表是通用表。媒体特定MIB的设计者必须准确定义此表如何应用于其特定MIB。
IF-MIB DEFINITIONS ::= BEGIN
IF-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, Counter64, Integer32, TimeTicks, mib-2, NOTIFICATION-TYPE FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString, PhysAddress, TruthValue, RowStatus, TimeStamp, AutonomousType, TestAndIncr FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF snmpTraps FROM SNMPv2-MIB IANAifType FROM IANAifType-MIB;
从SNMPv2中导入MODULE-IDENTITY、OBJECT-TYPE、Counter32、Gauge32、Counter64、Integer32、TimeTicks、mib-2、NOTIFICATION-TYPE和SNMPv2中的SMI文本约定、DisplayString、PhysAddress、TruthValue、RowStatus、TimeStamp、AutonomousType、TestAndIncr和对象组，SNMPv2 CONF snmpTraps FROM SNMPv2 MIB IANAifType FROM IANAifType MIB的通知组；
ifMIB MODULE-IDENTITY LAST-UPDATED "200006140000Z" ORGANIZATION "IETF Interfaces MIB Working Group" CONTACT-INFO " Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
ifMIB模块标识最新更新“200006140000Z”组织“IETF接口MIB工作组”联系方式“Keith McCloghrie Cisco Systems，Inc.美国加利福尼亚州圣何塞市西塔斯曼大道170号，邮编95134-1706
408-526-5260 kzm@cisco.com" DESCRIPTION "The MIB module to describe generic objects for network interface sub-layers. This MIB is an updated version of MIB-II's ifTable, and incorporates the extensions defined in RFC 1229."
408-526-5260 kzm@cisco.com“描述”用于描述网络接口子层的通用对象的MIB模块。此MIB是MIB-II ifTable的更新版本，并包含RFC 1229中定义的扩展。”
REVISION "200006140000Z"
DESCRIPTION
"Clarifications agreed upon by the Interfaces MIB WG, and
published as RFC 2863."
REVISION "199602282155Z"
DESCRIPTION
"Revisions made by the Interfaces MIB WG, and published in
RFC 2233."
REVISION "199311082155Z"
DESCRIPTION
"Initial revision, published as part of RFC 1573."
::= { mib-2 31 }
REVISION "200006140000Z"
DESCRIPTION
"Clarifications agreed upon by the Interfaces MIB WG, and
published as RFC 2863."
REVISION "199602282155Z"
DESCRIPTION
"Revisions made by the Interfaces MIB WG, and published in
RFC 2233."
REVISION "199311082155Z"
DESCRIPTION
"Initial revision, published as part of RFC 1573."
::= { mib-2 31 }
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
ifMIBObjects OBJECT IDENTIFIER ::= { ifMIB 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
-- -- Textual Conventions --
----文本约定--
-- OwnerString has the same semantics as used in RFC 1271
--OwnerString与RFC1271中使用的语义相同
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS deprecated
DESCRIPTION
"This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
OwnerString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS deprecated
DESCRIPTION
"This data type is used to model an administratively
assigned name of the owner of a resource. This information
is taken from the NVT ASCII character set. It is suggested
that this name contain one or more of the following: ASCII
form of the manager station's transport address, management
station name (e.g., domain name), network management
personnel's name, location, or phone number. In some cases
the agent itself will be the owner of an entry. In these
cases, this string shall be set to a string starting with
'agent'."
SYNTAX OCTET STRING (SIZE(0..255))
-- InterfaceIndex contains the semantics of ifIndex and should be used
-- for any objects defined in other MIB modules that need these semantics.
-- InterfaceIndex contains the semantics of ifIndex and should be used
-- for any objects defined in other MIB modules that need these semantics.
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
InterfaceIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface or interface sub-layer in the managed system. It is recommended that values are assigned contiguously starting from 1. The value for each interface sub-layer must remain constant at least from one re-initialization of the entity's network management system to the next re-initialization." SYNTAX Integer32 (1..2147483647)
管理系统中每个接口或接口子层的唯一值，大于零。建议从1开始连续分配值。从实体网络管理系统的一次重新初始化到下一次重新初始化，每个接口子层的值必须保持不变语法整数32（1..2147483647）
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
ifNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their
current state) present on this system."
::= { interfaces 1 }
ifNumber OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of network interfaces (regardless of their
current state) present on this system."
::= { interfaces 1 }
ifTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last creation or
deletion of an entry in the ifTable. If the number of
entries has been unchanged since the last re-initialization
of the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 5 }
ifTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last creation or
deletion of an entry in the ifTable. If the number of
entries has been unchanged since the last re-initialization
of the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 5 }
-- the Interfaces table
--接口表
-- The Interfaces table contains information on the entity's
--Interfaces表包含有关实体属性的信息
-- interfaces. Each sub-layer below the internetwork-layer
-- of a network interface is considered to be an interface.
-- interfaces. Each sub-layer below the internetwork-layer
-- of a network interface is considered to be an interface.
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber."
::= { interfaces 2 }
ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber."
::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable to a
particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing management information applicable to a
particular interface."
INDEX { ifIndex }
::= { ifTable 1 }
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex,
ifDescr DisplayString,
ifType IANAifType,
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, -- deprecated
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, -- deprecated
ifSpecific OBJECT IDENTIFIER -- deprecated
}
IfEntry ::=
SEQUENCE {
ifIndex InterfaceIndex,
ifDescr DisplayString,
ifType IANAifType,
ifMtu Integer32,
ifSpeed Gauge32,
ifPhysAddress PhysAddress,
ifAdminStatus INTEGER,
ifOperStatus INTEGER,
ifLastChange TimeTicks,
ifInOctets Counter32,
ifInUcastPkts Counter32,
ifInNUcastPkts Counter32, -- deprecated
ifInDiscards Counter32,
ifInErrors Counter32,
ifInUnknownProtos Counter32,
ifOutOctets Counter32,
ifOutUcastPkts Counter32,
ifOutNUcastPkts Counter32, -- deprecated
ifOutDiscards Counter32,
ifOutErrors Counter32,
ifOutQLen Gauge32, -- deprecated
ifSpecific OBJECT IDENTIFIER -- deprecated
}
ifIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization."
::= { ifEntry 1 }
ifIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique value, greater than zero, for each interface. It
is recommended that values are assigned contiguously
starting from 1. The value for each interface sub-layer
must remain constant at least from one re-initialization of
the entity's network management system to the next re-
initialization."
::= { ifEntry 1 }
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of the
manufacturer, the product name and the version of the
interface hardware/software."
::= { ifEntry 2 }
ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual string containing information about the
interface. This string should include the name of the
manufacturer, the product name and the version of the
interface hardware/software."
::= { ifEntry 2 }
ifType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of interface. Additional values for ifType are
assigned by the Internet Assigned Numbers Authority (IANA),
through updating the syntax of the IANAifType textual
convention."
::= { ifEntry 3 }
ifType OBJECT-TYPE
SYNTAX IANAifType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of interface. Additional values for ifType are
assigned by the Internet Assigned Numbers Authority (IANA),
through updating the syntax of the IANAifType textual
convention."
::= { ifEntry 3 }
ifMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The size of the largest packet which can be sent/received
on the interface, specified in octets. For interfaces that
are used for transmitting network datagrams, this is the
size of the largest network datagram that can be sent on the
interface."
::= { ifEntry 4 }
ifMtu OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The size of the largest packet which can be sent/received
on the interface, specified in octets. For interfaces that
are used for transmitting network datagrams, this is the
size of the largest network datagram that can be sent on the
interface."
::= { ifEntry 4 }
ifSpeed OBJECT-TYPE
ifSpeed对象类型
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in bits
per second. For interfaces which do not vary in bandwidth
or for those where no accurate estimation can be made, this
object should contain the nominal bandwidth. If the
bandwidth of the interface is greater than the maximum value
reportable by this object then this object should report its
maximum value (4,294,967,295) and ifHighSpeed must be used
to report the interace's speed. For a sub-layer which has
no concept of bandwidth, this object should be zero."
::= { ifEntry 5 }
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in bits
per second. For interfaces which do not vary in bandwidth
or for those where no accurate estimation can be made, this
object should contain the nominal bandwidth. If the
bandwidth of the interface is greater than the maximum value
reportable by this object then this object should report its
maximum value (4,294,967,295) and ifHighSpeed must be used
to report the interace's speed. For a sub-layer which has
no concept of bandwidth, this object should be zero."
::= { ifEntry 5 }
ifPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a MAC address. The interface's media-specific MIB
must define the bit and byte ordering and the format of the
value of this object. For interfaces which do not have such
an address (e.g., a serial line), this object should contain
an octet string of zero length."
::= { ifEntry 6 }
ifPhysAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The interface's address at its protocol sub-layer. For
example, for an 802.x interface, this object normally
contains a MAC address. The interface's media-specific MIB
must define the bit and byte ordering and the format of the
value of this object. For interfaces which do not have such
an address (e.g., a serial line), this object should contain
an octet string of zero length."
::= { ifEntry 6 }
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3) state
indicates that no operational packets can be passed. When a
managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state. As a result of either
explicit management action or per configuration information
retained by the managed system, ifAdminStatus is then
changed to either the up(1) or testing(3) states (or remains
in the down(2) state)."
::= { ifEntry 7 }
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3) state
indicates that no operational packets can be passed. When a
managed system initializes, all interfaces start with
ifAdminStatus in the down(2) state. As a result of either
explicit management action or per configuration information
retained by the managed system, ifAdminStatus is then
changed to either the up(1) or testing(3) states (or remains
in the down(2) state)."
::= { ifEntry 7 }
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3), -- in some test mode
unknown(4), -- status can not be determined
-- for some reason.
dormant(5),
notPresent(6), -- some component is missing
lowerLayerDown(7) -- down due to state of
-- lower-layer interface(s)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets can
be passed. If ifAdminStatus is down(2) then ifOperStatus
should be down(2). If ifAdminStatus is changed to up(1)
then ifOperStatus should change to up(1) if the interface is
ready to transmit and receive network traffic; it should
change to dormant(5) if the interface is waiting for
external actions (such as a serial line waiting for an
incoming connection); it should remain in the down(2) state
if and only if there is a fault that prevents it from going
to the up(1) state; it should remain in the notPresent(6)
state if the interface has missing (typically, hardware)
components."
::= { ifEntry 8 }
ifOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3), -- in some test mode
unknown(4), -- status can not be determined
-- for some reason.
dormant(5),
notPresent(6), -- some component is missing
lowerLayerDown(7) -- down due to state of
-- lower-layer interface(s)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current operational state of the interface. The
testing(3) state indicates that no operational packets can
be passed. If ifAdminStatus is down(2) then ifOperStatus
should be down(2). If ifAdminStatus is changed to up(1)
then ifOperStatus should change to up(1) if the interface is
ready to transmit and receive network traffic; it should
change to dormant(5) if the interface is waiting for
external actions (such as a serial line waiting for an
incoming connection); it should remain in the down(2) state
if and only if there is a fault that prevents it from going
to the up(1) state; it should remain in the notPresent(6)
state if the interface has missing (typically, hardware)
components."
::= { ifEntry 8 }
ifLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the interface entered
its current operational state. If the current state was
entered prior to the last re-initialization of the local
network management subsystem, then this object contains a
zero value."
::= { ifEntry 9 }
ifLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time the interface entered
its current operational state. If the current state was
entered prior to the last re-initialization of the local
network management subsystem, then this object contains a
zero value."
::= { ifEntry 9 }
ifInOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface,
ifInOctets对象类型语法计数器32 MAX-ACCESS只读状态当前描述“接口上接收的八位字节总数，
including framing characters.
包括框架字符。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 10 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 10 }
ifInUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer.
ifInUcastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前描述“此子层传递到更高（子）层的数据包数量，这些数据包未寻址到此子层的多播或广播地址。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 11 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 11 }
ifInNUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast or broadcast address at this sub-layer.
ifInNUcastPkts对象类型语法计数器32 MAX-ACCESS只读状态弃用说明“此子层传递到更高（子）层的数据包数，这些数据包被寻址到此子层的多播或广播地址。
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.
此计数器的值可能在管理系统重新初始化时出现不连续，也可能在IFCounterInterruptionTime值指示的其他时间出现不连续。
This object is deprecated in favour of ifInMulticastPkts and
ifInBroadcastPkts."
::= { ifEntry 12 }
This object is deprecated in favour of ifInMulticastPkts and
ifInBroadcastPkts."
::= { ifEntry 12 }
ifInDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of inbound packets which were chosen to be discarded even though no errors had been detected to prevent
ifInDiscards OBJECT-TYPE SYNTAX counter 32 MAX-ACCESS只读状态current DESCRIPTION“即使未检测到任何错误，仍选择丢弃的入站数据包数，以防止
their being deliverable to a higher-layer protocol. One possible reason for discarding such a packet could be to free up buffer space.
它们可以交付给更高层的协议。丢弃此类数据包的一个可能原因是释放缓冲区空间。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 13 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 13 }
ifInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of inbound packets that contained errors preventing them from being deliverable to a higher-layer protocol. For character-oriented or fixed-length interfaces, the number of inbound transmission units that contained errors preventing them from being deliverable to a higher-layer protocol.
ifInErrors对象类型语法计数器32 MAX-ACCESS只读状态当前说明“对于面向数据包的接口，包含错误的入站数据包的数量，这些错误使它们无法交付给更高层协议。”。对于面向字符或固定长度的接口，包含错误的入站传输单元的数量，这些错误使它们无法交付给更高层协议。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 14 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 14 }
ifInUnknownProtos OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of packets received via the interface which were discarded because of an unknown or unsupported protocol. For character-oriented or fixed-length interfaces that support protocol multiplexing the number of transmission units received via the interface which were discarded because of an unknown or unsupported protocol. For any interface that does not support protocol multiplexing, this counter will always be 0.
ifInUnknownProtos对象类型语法计数器32 MAX-ACCESS只读状态当前说明“对于面向数据包的接口，指通过接口接收的由于未知或不受支持的协议而被丢弃的数据包数。对于支持协议多路复用的面向字符或固定长度接口，由于未知或不受支持的协议而丢弃的通过接口接收的传输单元数。对于不支持协议多路复用的任何接口，此计数器将始终为0。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 15 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 15 }
ifOutOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters.
IFOUTPOCTETS对象类型语法计数器32 MAX-ACCESS只读状态当前描述“从接口传输的八位字节总数，包括帧字符。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 16 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 16 }
ifOutUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.
ifOutUcastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前描述“请求传输更高级别协议且未寻址到此子层的多播或广播地址的数据包总数，包括丢弃或未发送的数据包。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 17 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 17 }
ifOutNUcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS deprecated DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent.
ifOutNUcastPkts对象类型语法计数器32 MAX-ACCESS只读状态弃用说明“高级协议请求传输的数据包总数，这些数据包被发送到该子层的多播或广播地址，包括被丢弃或未发送的数据包。
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime.
此计数器的值可能在管理系统重新初始化时出现不连续，也可能在IFCounterInterruptionTime值指示的其他时间出现不连续。
This object is deprecated in favour of ifOutMulticastPkts
and ifOutBroadcastPkts."
::= { ifEntry 18 }
This object is deprecated in favour of ifOutMulticastPkts
and ifOutBroadcastPkts."
::= { ifEntry 18 }
ifOutDiscards OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of outbound packets which were chosen to be discarded even though no errors had been detected to prevent their being transmitted. One possible reason for discarding such a packet could be to free up buffer space.
IFOUTDARDS对象类型语法计数器32 MAX-ACCESS只读状态当前描述“即使未检测到阻止传输的错误，仍选择丢弃的出站数据包数。丢弃此类数据包的一个可能原因可能是释放缓冲区空间。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 19 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 19 }
ifOutErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "For packet-oriented interfaces, the number of outbound packets that could not be transmitted because of errors. For character-oriented or fixed-length interfaces, the number of outbound transmission units that could not be transmitted because of errors.
ifOutErrors对象类型语法计数器32 MAX-ACCESS只读状态当前描述“对于面向数据包的接口，由于错误而无法传输的出站数据包数。对于面向字符或固定长度的接口，由于错误而无法传输的出站传输单元数。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 20 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifEntry 20 }
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }
ifOutQLen OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The length of the output packet queue (in packets)."
::= { ifEntry 21 }
ifSpecific OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "A reference to MIB definitions specific to the particular media being used to realize the interface. It is
ifSpecific OBJECT-TYPE语法OBJECT IDENTIFIER MAX-ACCESS只读状态不推荐的描述“对特定于用于实现接口的特定媒体的MIB定义的引用。它是
recommended that this value point to an instance of a MIB
object in the media-specific MIB, i.e., that this object
have the semantics associated with the InstancePointer
textual convention defined in RFC 2579. In fact, it is
recommended that the media-specific MIB specify what value
ifSpecific should/can take for values of ifType. If no MIB
definitions specific to the particular media are available,
the value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }
recommended that this value point to an instance of a MIB
object in the media-specific MIB, i.e., that this object
have the semantics associated with the InstancePointer
textual convention defined in RFC 2579. In fact, it is
recommended that the media-specific MIB specify what value
ifSpecific should/can take for values of ifType. If no MIB
definitions specific to the particular media are available,
the value should be set to the OBJECT IDENTIFIER { 0 0 }."
::= { ifEntry 22 }
--
-- Extension to the interface table
--
-- This table replaces the ifExtnsTable table.
--
--
-- Extension to the interface table
--
-- This table replaces the ifExtnsTable table.
--
ifXTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber. This table contains
additional objects for the interface table."
::= { ifMIBObjects 1 }
ifXTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of interface entries. The number of entries is
given by the value of ifNumber. This table contains
additional objects for the interface table."
::= { ifMIBObjects 1 }
ifXEntry OBJECT-TYPE
SYNTAX IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional management information
applicable to a particular interface."
AUGMENTS { ifEntry }
::= { ifXTable 1 }
ifXEntry OBJECT-TYPE
SYNTAX IfXEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry containing additional management information
applicable to a particular interface."
AUGMENTS { ifEntry }
::= { ifXTable 1 }
IfXEntry ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
IfXEntry ::=
SEQUENCE {
ifName DisplayString,
ifInMulticastPkts Counter32,
ifInBroadcastPkts Counter32,
ifOutMulticastPkts Counter32,
ifOutBroadcastPkts Counter32,
ifHCInOctets Counter64,
ifHCInUcastPkts Counter64,
ifHCInMulticastPkts Counter64,
ifHCInBroadcastPkts Counter64, ifHCOutOctets Counter64, ifHCOutUcastPkts Counter64, ifHCOutMulticastPkts Counter64, ifHCOutBroadcastPkts Counter64, ifLinkUpDownTrapEnable INTEGER, ifHighSpeed Gauge32, ifPromiscuousMode TruthValue, ifConnectorPresent TruthValue, ifAlias DisplayString, ifCounterDiscontinuityTime TimeStamp }
ifHCInBroadcastPkts计数器64、ifHCOutOctets计数器64、ifHCOutUcastPkts计数器64、ifHCOutMulticastPkts计数器64、ifHCOutBroadcastPkts计数器64、IFLinkUpDowntrable INTEGER、ifHighSpeed Gauge 32、ifPromiscuousMode TruthValue、ifConnectorPresent TruthValue、ifAlias DisplayString、IFCounterInterructyTime时间戳}
ifName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The textual name of the interface. The value of this object should be the name of the interface as assigned by the local device and should be suitable for use in commands entered at the device's `console'. This might be a text name, such as `le0' or a simple port number, such as `1', depending on the interface naming syntax of the device. If several entries in the ifTable together represent a single interface as named by the device, then each will have the same value of ifName. Note that for an agent which responds to SNMP queries concerning an interface on some other (proxied) device, then the value of ifName for such an interface is the proxied device's local name for it.
ifName对象类型语法DisplayString MAX-ACCESS只读状态当前说明“接口的文本名称。此对象的值应为本地设备分配的接口名称，并应适合在设备“控制台”输入的命令中使用。根据设备的接口命名语法，这可能是一个文本名称，如“le0”，也可能是一个简单的端口号，如“1”。如果ifTable中的多个条目一起表示设备命名的单个接口，则每个条目都具有相同的ifName值。请注意，对于响应与某个其他（代理）设备上的接口有关的SNMP查询的代理，该接口的ifName值是代理设备的本地名称。
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string."
::= { ifXEntry 1 }
If there is no local name, or this object is otherwise not
applicable, then this object contains a zero-length string."
::= { ifXEntry 1 }
ifInMulticastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses.
ifInMulticastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前描述“此子层传送到更高（子）层的数据包数量，这些数据包被寻址到此子层的多播地址。对于MAC层协议，这包括组地址和功能地址。
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
在管理系统重新初始化时以及在其他情况下，此计数器的值可能会出现不连续
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 2 }
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 2 }
ifInBroadcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer.
ifInBroadcastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前描述“此子层传送到更高（子）层的数据包数量，这些数据包被寻址到此子层的广播地址。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 3 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 3 }
ifOutMulticastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses.
ifOutMulticastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前说明“高级协议请求传输的数据包总数，这些数据包被发送到该子层的多播地址，包括被丢弃或未发送的数据包。对于MAC层协议，这包括组地址和功能地址。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 4 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 4 }
ifOutBroadcastPkts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent.
ifOutBroadcastPkts对象类型语法计数器32 MAX-ACCESS只读状态当前描述“请求传输更高级别协议的数据包总数，这些数据包被发送到该子层的广播地址，包括被丢弃或未发送的数据包。
Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other
在管理系统重新初始化时以及在其他情况下，此计数器的值可能会出现不连续
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 5 }
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 5 }
--
-- High Capacity Counter objects. These objects are all
-- 64 bit versions of the "basic" ifTable counters. These
-- objects all have the same basic semantics as their 32-bit
-- counterparts, however, their syntax has been extended
-- to 64 bits.
--
--
-- High Capacity Counter objects. These objects are all
-- 64 bit versions of the "basic" ifTable counters. These
-- objects all have the same basic semantics as their 32-bit
-- counterparts, however, their syntax has been extended
-- to 64 bits.
--
ifHCInOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets received on the interface, including framing characters. This object is a 64-bit version of ifInOctets.
ifHCInOctets对象类型语法计数器64 MAX-ACCESS只读状态当前描述“接口上接收的八位字节总数，包括帧字符。此对象是IFinocts的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 6 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 6 }
ifHCInUcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were not addressed to a multicast or broadcast address at this sub-layer. This object is a 64-bit version of ifInUcastPkts.
ifHCInUcastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前描述“此子层传递到更高（子）层的数据包数，这些数据包未寻址到此子层的多播或广播地址。此对象是ifInUcastPkts的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 7 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 7 }
ifHCInMulticastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION
ifHCInMulticastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前说明
"The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a multicast address at this sub-layer. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifInMulticastPkts.
“此子层传递到更高（子）层的数据包数，这些数据包被寻址到此子层的多播地址。对于MAC层协议，这包括组地址和功能地址。此对象是ifInMulticastPkts的64位版本。”。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 8 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 8 }
ifHCInBroadcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets, delivered by this sub-layer to a higher (sub-)layer, which were addressed to a broadcast address at this sub-layer. This object is a 64-bit version of ifInBroadcastPkts.
ifHCInBroadcastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前描述“此子层传送到更高（子）层的数据包数量，这些数据包被寻址到此子层的广播地址。此对象是ifInBroadcastPkts的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 9 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 9 }
ifHCOutOctets OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of octets transmitted out of the interface, including framing characters. This object is a 64-bit version of ifOutOctets.
ifHCOutOctets对象类型语法计数器64 MAX-ACCESS只读状态当前描述“从接口传输的八位字节总数，包括帧字符。此对象是ifOutOctets的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 10 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 10 }
ifHCOutUcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION
ifHCOutUcastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前说明
"The total number of packets that higher-level protocols requested be transmitted, and which were not addressed to a multicast or broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutUcastPkts.
“高级协议请求传输的数据包总数，这些数据包没有发送到该子层的多播或广播地址，包括被丢弃或未发送的数据包。此对象是ifOutUcastPkts的64位版本。”。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 11 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 11 }
ifHCOutMulticastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a multicast address at this sub-layer, including those that were discarded or not sent. For a MAC layer protocol, this includes both Group and Functional addresses. This object is a 64-bit version of ifOutMulticastPkts.
ifHCOutMulticastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前说明“高级协议请求传输的数据包总数，这些数据包被发送到该子层的多播地址，包括被丢弃或未发送的数据包。对于MAC层协议，这包括组地址和功能地址。此对象是ifOutMulticastPkts的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 12 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 12 }
ifHCOutBroadcastPkts OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of packets that higher-level protocols requested be transmitted, and which were addressed to a broadcast address at this sub-layer, including those that were discarded or not sent. This object is a 64-bit version of ifOutBroadcastPkts.
ifHCOutBroadcastPkts对象类型语法计数器64 MAX-ACCESS只读状态当前说明“高级协议请求传输的数据包的总数，这些数据包被发送到该子层的广播地址，包括被丢弃或未发送的数据包。此对象是ifOutBroadcastPkts的64位版本。
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 13 }
Discontinuities in the value of this counter can occur at
re-initialization of the management system, and at other
times as indicated by the value of
ifCounterDiscontinuityTime."
::= { ifXEntry 13 }
ifLinkUpDownTrapEnable OBJECT-TYPE
iFlinkUpDowntrappenable对象类型
SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether linkUp/linkDown traps should be generated for this interface.
语法整数{enabled（1），disabled（2）}MAX-ACCESS read-write STATUS current DESCRIPTION“指示是否应为此接口生成linkUp/linkDown陷阱。
By default, this object should have the value enabled(1) for
interfaces which do not operate on 'top' of any other
interface (as defined in the ifStackTable), and disabled(2)
otherwise."
::= { ifXEntry 14 }
By default, this object should have the value enabled(1) for
interfaces which do not operate on 'top' of any other
interface (as defined in the ifStackTable), and disabled(2)
otherwise."
::= { ifXEntry 14 }
ifHighSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in units
of 1,000,000 bits per second. If this object reports a
value of `n' then the speed of the interface is somewhere in
the range of `n-500,000' to `n+499,999'. For interfaces
which do not vary in bandwidth or for those where no
accurate estimation can be made, this object should contain
the nominal bandwidth. For a sub-layer which has no concept
of bandwidth, this object should be zero."
::= { ifXEntry 15 }
ifHighSpeed OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of the interface's current bandwidth in units
of 1,000,000 bits per second. If this object reports a
value of `n' then the speed of the interface is somewhere in
the range of `n-500,000' to `n+499,999'. For interfaces
which do not vary in bandwidth or for those where no
accurate estimation can be made, this object should contain
the nominal bandwidth. For a sub-layer which has no concept
of bandwidth, this object should be zero."
::= { ifXEntry 15 }
ifPromiscuousMode OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "This object has a value of false(2) if this interface only accepts packets/frames that are addressed to this station. This object has a value of true(1) when the station accepts all packets/frames transmitted on the media. The value true(1) is only legal on certain types of media. If legal, setting this object to a value of true(1) may require the interface to be reset before becoming effective.
ifPromiscuousMode对象类型语法TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION“如果此接口仅接受发送到此站点的数据包/帧，则此对象的值为false（2）。当站点接受媒体上传输的所有数据包/帧时，此对象的值为true（1）。值为true（1）仅在某些类型的媒体上合法。如果合法，将此对象的值设置为true（1）可能需要重置接口才能生效。
The value of ifPromiscuousMode does not affect the reception
of broadcast and multicast packets/frames by the interface."
::= { ifXEntry 16 }
The value of ifPromiscuousMode does not affect the reception
of broadcast and multicast packets/frames by the interface."
::= { ifXEntry 16 }
ifConnectorPresent OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only
ifConnectorPresent对象类型语法TruthValue MAX-ACCESS只读
STATUS current
DESCRIPTION
"This object has the value 'true(1)' if the interface
sublayer has a physical connector and the value 'false(2)'
otherwise."
::= { ifXEntry 17 }
STATUS current
DESCRIPTION
"This object has the value 'true(1)' if the interface
sublayer has a physical connector and the value 'false(2)'
otherwise."
::= { ifXEntry 17 }
ifAlias OBJECT-TYPE SYNTAX DisplayString (SIZE(0..64)) MAX-ACCESS read-write STATUS current DESCRIPTION "This object is an 'alias' name for the interface as specified by a network manager, and provides a non-volatile 'handle' for the interface.
ifAlias对象类型语法DisplayString（大小（0..64））MAX-ACCESS读写状态当前描述“此对象是网络管理器指定的接口的“别名”，并为接口提供非易失性的“句柄”。
On the first instantiation of an interface, the value of ifAlias associated with that interface is the zero-length string. As and when a value is written into an instance of ifAlias through a network management set operation, then the agent must retain the supplied value in the ifAlias instance associated with the same interface for as long as that interface remains instantiated, including across all re-initializations/reboots of the network management system, including those which result in a change of the interface's ifIndex value.
在接口的第一次实例化时，与该接口关联的ifAlias的值为零长度字符串。当通过网络管理集操作将值写入ifAlias实例时，代理必须在与同一接口相关联的ifAlias实例中保留提供的值，只要该接口保持实例化，包括网络管理系统的所有重新初始化/重新启动，包括那些导致接口的ifIndex值发生变化的。
An example of the value which a network manager might store in this object for a WAN interface is the (Telco's) circuit number/identifier of the interface.
网络管理器可能为WAN接口存储在该对象中的值的一个示例是接口的（电信公司）电路号/标识符。
Some agents may support write-access only for interfaces
having particular values of ifType. An agent which supports
write access to this object is required to keep the value in
non-volatile storage, but it may limit the length of new
values depending on how much storage is already occupied by
the current values for other interfaces."
::= { ifXEntry 18 }
Some agents may support write-access only for interfaces
having particular values of ifType. An agent which supports
write access to this object is required to keep the value in
non-volatile storage, but it may limit the length of new
values depending on how much storage is already occupied by
the current values for other interfaces."
::= { ifXEntry 18 }
ifCounterDiscontinuityTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime on the most recent occasion at which any one or more of this interface's counters suffered a discontinuity. The relevant counters are the specific instances associated with this interface of any Counter32 or
IfCounterInterruptyTime对象类型语法时间戳MAX-ACCESS只读状态当前描述“此接口的任何一个或多个计数器最近发生中断时的sysUpTime值。相关计数器是与任何计数器32或
Counter64 object contained in the ifTable or ifXTable. If
no such discontinuities have occurred since the last re-
initialization of the local management subsystem, then this
object contains a zero value."
::= { ifXEntry 19 }
Counter64 object contained in the ifTable or ifXTable. If
no such discontinuities have occurred since the last re-
initialization of the local management subsystem, then this
object contains a zero value."
::= { ifXEntry 19 }
-- The Interface Stack Group
--
-- Implementation of this group is optional, but strongly recommended
-- for all systems
--
-- The Interface Stack Group
--
-- Implementation of this group is optional, but strongly recommended
-- for all systems
--
ifStackTable OBJECT-TYPE SYNTAX SEQUENCE OF IfStackEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table containing information on the relationships between the multiple sub-layers of network interfaces. In particular, it contains information on which sub-layers run 'on top of' which other sub-layers, where each sub-layer corresponds to a conceptual row in the ifTable. For example, when the sub-layer with ifIndex value x runs over the sub-layer with ifIndex value y, then this table contains:
IfStackEntry MAX-ACCESS的ifStackTable对象类型语法序列不可访问状态当前描述“包含网络接口多个子层之间关系信息的表。特别是，它包含关于哪些子层“在”哪些其他子层之上运行的信息，其中每个子层对应于ifTable中的一个概念行。例如，当ifIndex值为x的子层在ifIndex值为y的子层上运行时，此表包含：
ifStackStatus.x.y=active
ifStackStatus.x.y=活动
For each ifIndex value, I, which identifies an active interface, there are always at least two instantiated rows in this table associated with I. For one of these rows, I is the value of ifStackHigherLayer; for the other, I is the value of ifStackLowerLayer. (If I is not involved in multiplexing, then these are the only two rows associated with I.)
对于标识活动接口的每个ifIndex值I，该表中始终至少有两个实例化行与I关联。对于其中一个行，I是ifStackHigherLayer的值；对于另一个，I是ifStackLowerLayer的值。（如果I不参与多路复用，则这是与I关联的仅有两行。）
For example, two rows exist even for an interface which has no others stacked on top or below it:
例如，即使对于顶部或下方没有其他堆叠的界面，也存在两行：
ifStackStatus.0.x=active
ifStackStatus.x.0=active "
::= { ifMIBObjects 2 }
ifStackStatus.0.x=active
ifStackStatus.x.0=active "
::= { ifMIBObjects 2 }
ifStackEntry OBJECT-TYPE SYNTAX IfStackEntry MAX-ACCESS not-accessible STATUS current
ifStackEntry对象类型语法ifStackEntry MAX-ACCESS不可访问状态当前
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer runs on 'top' of the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer runs on 'top' of the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer InterfaceIndexOrZero,
ifStackLowerLayer InterfaceIndexOrZero,
ifStackStatus RowStatus
}
IfStackEntry ::=
SEQUENCE {
ifStackHigherLayer InterfaceIndexOrZero,
ifStackLowerLayer InterfaceIndexOrZero,
ifStackStatus RowStatus
}
ifStackHigherLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher sub-layer
of the relationship, i.e., the sub-layer which runs on 'top'
of the sub-layer identified by the corresponding instance of
ifStackLowerLayer. If there is no higher sub-layer (below
the internetwork layer), then this object has the value 0."
::= { ifStackEntry 1 }
ifStackHigherLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the higher sub-layer
of the relationship, i.e., the sub-layer which runs on 'top'
of the sub-layer identified by the corresponding instance of
ifStackLowerLayer. If there is no higher sub-layer (below
the internetwork layer), then this object has the value 0."
::= { ifStackEntry 1 }
ifStackLowerLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-layer
of the relationship, i.e., the sub-layer which runs 'below'
the sub-layer identified by the corresponding instance of
ifStackHigherLayer. If there is no lower sub-layer, then
this object has the value 0."
::= { ifStackEntry 2 }
ifStackLowerLayer OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The value of ifIndex corresponding to the lower sub-layer
of the relationship, i.e., the sub-layer which runs 'below'
the sub-layer identified by the corresponding instance of
ifStackHigherLayer. If there is no lower sub-layer, then
this object has the value 0."
::= { ifStackEntry 2 }
ifStackStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION
ifStackStatus对象类型语法RowStatus MAX-ACCESS read create STATUS当前说明
"The status of the relationship between two sub-layers.
“两个子层之间关系的状态。
Changing the value of this object from 'active' to
'notInService' or 'destroy' will likely have consequences up
and down the interface stack. Thus, write access to this
object is likely to be inappropriate for some types of
interfaces, and many implementations will choose not to
support write-access for any type of interface."
::= { ifStackEntry 3 }
Changing the value of this object from 'active' to
'notInService' or 'destroy' will likely have consequences up
and down the interface stack. Thus, write access to this
object is likely to be inappropriate for some types of
interfaces, and many implementations will choose not to
support write-access for any type of interface."
::= { ifStackEntry 3 }
ifStackLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last change of
the (whole) interface stack. A change of the interface
stack is defined to be any creation, deletion, or change in
value of any instance of ifStackStatus. If the interface
stack has been unchanged since the last re-initialization of
the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 6 }
ifStackLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last change of
the (whole) interface stack. A change of the interface
stack is defined to be any creation, deletion, or change in
value of any instance of ifStackStatus. If the interface
stack has been unchanged since the last re-initialization of
the local network management subsystem, then this object
contains a zero value."
::= { ifMIBObjects 6 }
-- Generic Receive Address Table
--
-- This group of objects is mandatory for all types of
-- interfaces which can receive packets/frames addressed to
-- more than one address.
--
-- This table replaces the ifExtnsRcvAddr table. The main
-- difference is that this table makes use of the RowStatus
-- textual convention, while ifExtnsRcvAddr did not.
-- Generic Receive Address Table
--
-- This group of objects is mandatory for all types of
-- interfaces which can receive packets/frames addressed to
-- more than one address.
--
-- This table replaces the ifExtnsRcvAddr table. The main
-- difference is that this table makes use of the RowStatus
-- textual convention, while ifExtnsRcvAddr did not.
ifRcvAddressTable OBJECT-TYPE SYNTAX SEQUENCE OF IfRcvAddressEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains an entry for each address (broadcast, multicast, or uni-cast) for which the system will receive packets/frames on a particular interface, except as follows:
ifRcvAddressTable IFRCVADDRESSSETRY MAX-ACCESS not ACCESS STATUS current DESCRIPTION ifRcvAddressTable对象类型语法序列“此表包含系统将在特定接口上接收数据包/帧的每个地址（广播、多播或单播）的条目，以下情况除外：
- for an interface operating in promiscuous mode, entries are only required for those addresses for which the system would receive frames were it not operating in promiscuous mode.
- 对于在混杂模式下运行的接口，只有在系统未在混杂模式下运行的情况下接收帧的地址才需要输入项。
- for 802.5 functional addresses, only one entry is required, for the address which has the functional address bit ANDed with the bit mask of all functional addresses for which the interface will accept frames.
- 对于802.5功能地址，对于具有功能地址位且带有接口将接受帧的所有功能地址的位掩码的地址，只需要一个条目。
A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address."
::= { ifMIBObjects 4 }
A system is normally able to use any unicast address which
corresponds to an entry in this table as a source address."
::= { ifMIBObjects 4 }
ifRcvAddressEntry OBJECT-TYPE
SYNTAX IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of objects identifying an address for which the
system will accept packets/frames on the particular
interface identified by the index value ifIndex."
INDEX { ifIndex, ifRcvAddressAddress }
::= { ifRcvAddressTable 1 }
ifRcvAddressEntry OBJECT-TYPE
SYNTAX IfRcvAddressEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of objects identifying an address for which the
system will accept packets/frames on the particular
interface identified by the index value ifIndex."
INDEX { ifIndex, ifRcvAddressAddress }
::= { ifRcvAddressTable 1 }
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
IfRcvAddressEntry ::=
SEQUENCE {
ifRcvAddressAddress PhysAddress,
ifRcvAddressStatus RowStatus,
ifRcvAddressType INTEGER
}
ifRcvAddressAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An address for which the system will accept packets/frames
on this entry's interface."
::= { ifRcvAddressEntry 1 }
ifRcvAddressAddress OBJECT-TYPE
SYNTAX PhysAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An address for which the system will accept packets/frames
on this entry's interface."
::= { ifRcvAddressEntry 1 }
ifRcvAddressStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is used to create and delete rows in the ifRcvAddressTable."
ifRcvAddressStatus对象类型语法RowStatus MAX-ACCESS read create STATUS current DESCRIPTION“此对象用于创建和删除ifRcvAddressTable中的行。”
::= { ifRcvAddressEntry 2 }
::= { ifRcvAddressEntry 2 }
ifRcvAddressType OBJECT-TYPE SYNTAX INTEGER {
ifRcvAddressType对象类型语法整数{
other(1), volatile(2), nonVolatile(3) }
其他（1）、挥发性（2）、非挥发性（3）}
MAX-ACCESS read-create STATUS current DESCRIPTION "This object has the value nonVolatile(3) for those entries in the table which are valid and will not be deleted by the next restart of the managed system. Entries having the value volatile(2) are valid and exist, but have not been saved, so that will not exist after the next restart of the managed system. Entries having the value other(1) are valid and exist but are not classified as to whether they will continue to exist after the next restart."
MAX-ACCESS read create STATUS current DESCRIPTION“对于表中的有效条目，此对象具有非易失性（3）值，并且在下次重新启动托管系统时不会被删除。具有值volatile（2）的条目有效且存在，但尚未保存，因此在下次重新启动托管系统后将不存在。值为“other”（1）的条目有效且存在，但未分类为在下次重新启动后是否继续存在。”
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }
DEFVAL { volatile }
::= { ifRcvAddressEntry 3 }
-- definition of interface-related traps.
--接口相关陷阱的定义。
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus."
::= { snmpTraps 3 }
linkDown NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkDown trap signifies that the SNMP entity, acting in
an agent role, has detected that the ifOperStatus object for
one of its communication links is about to enter the down
state from some other state (but not from the notPresent
state). This other state is indicated by the included value
of ifOperStatus."
::= { snmpTraps 3 }
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
linkUp NOTIFICATION-TYPE
OBJECTS { ifIndex, ifAdminStatus, ifOperStatus }
STATUS current
DESCRIPTION
"A linkUp trap signifies that the SNMP entity, acting in an
agent role, has detected that the ifOperStatus object for
one of its communication links left the down state and
transitioned into some other state (but not into the
notPresent state). This other state is indicated by the
included value of ifOperStatus."
::= { snmpTraps 4 }
-- conformance information
--一致性信息
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifConformance OBJECT IDENTIFIER ::= { ifMIB 2 }
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
ifGroups OBJECT IDENTIFIER ::= { ifConformance 1 }
ifCompliances OBJECT IDENTIFIER ::= { ifConformance 2 }
-- compliance statements
--合规声明
ifCompliance3 MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities which have network interfaces."
IFCompliance 3 MODULE-COMPLIANCE STATUS当前描述“具有网络接口的SNMP实体的符合性声明”
MODULE -- this module MANDATORY-GROUPS { ifGeneralInformationGroup, linkUpDownNotificationsGroup }
MODULE--此模块为必填组{IFGeneralInformation组，linkUpDownNotificationsGroup}
-- The groups:
-- ifFixedLengthGroup
-- ifHCFixedLengthGroup
-- ifPacketGroup
-- ifHCPacketGroup
-- ifVHCPacketGroup
-- are mutually exclusive; at most one of these groups is implemented
-- for a particular interface. When any of these groups is implemented
-- for a particular interface, then ifCounterDiscontinuityGroup must
-- also be implemented for that interface.
-- The groups:
-- ifFixedLengthGroup
-- ifHCFixedLengthGroup
-- ifPacketGroup
-- ifHCPacketGroup
-- ifVHCPacketGroup
-- are mutually exclusive; at most one of these groups is implemented
-- for a particular interface. When any of these groups is implemented
-- for a particular interface, then ifCounterDiscontinuityGroup must
-- also be implemented for that interface.
GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is less than or equal to 20,000,000 bits/second."
组ifFixedLengthGroup DESCRIPTION“此组对于面向字符或以固定长度传输单元传输数据的网络接口是必需的，并且对于这些网络接口，ifSpeed的相应实例的值小于或等于20000000位/秒。”
GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second."
GROUP ifHCFixedLengthGroup DESCRIPTION“对于面向字符或以固定长度传输单元传输数据的网络接口，以及ifSpeed的相应实例的值大于20000000位/秒的网络接口，此组是必需的。”
GROUP ifPacketGroup DESCRIPTION
组ifPacketGroup说明
"This group is mandatory for those network interfaces which are packet-oriented, and for which the value of the corresponding instance of ifSpeed is less than or equal to 20,000,000 bits/second."
此组对于面向数据包的网络接口是必需的，并且对应的ifSpeed实例的值小于或等于20000000位/秒
GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second but less than or equal to 650,000,000 bits/second."
GROUP ifHCPacketGroup DESCRIPTION“此组仅对于面向数据包且ifSpeed对应实例的值大于20000000位/秒但小于或等于650000000位/秒的网络接口是必需的。”
GROUP ifVHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second."
GROUP ifVHCPacketGroup DESCRIPTION“此组仅对于面向数据包且ifSpeed对应实例的值大于650000000位/秒的网络接口是必需的。”
GROUP ifCounterDiscontinuityGroup DESCRIPTION "This group is mandatory for those network interfaces that are required to maintain counters (i.e., those for which one of the ifFixedLengthGroup, ifHCFixedLengthGroup, ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup is mandatory)."
GROUP IfCounterInteractionyGroup DESCRIPTION“此组对于维护计数器所需的网络接口是必需的（即，对于其中一个ifFixedLengthGroup、ifHCFixedLengthGroup、ifPacketGroup、ifHCPacketGroup或ifVHCPacketGroup是必需的网络接口）。”
GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group."
GROUP IfrcvaAddressGroup DESCRIPTION“此组的适用性必须由特定于媒体的MIB定义。特定于媒体的MIB必须定义此组中地址的确切含义、用途和语义。”
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象ifLinkUpDownTrapEnable最小访问只读描述“不需要写访问”
OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象IFPROMISCUUSMODE MIN-ACCESS只读说明“不需要写访问权限。”
OBJECT ifAdminStatus
对象ifAdminStatus
SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)."
语法整数{up（1），down（2）}MIN-ACCESS只读描述“不需要写访问，也不支持值测试（3）”
OBJECT ifAlias MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象IFALIA的最小访问只读描述“不需要写入访问权限”
::= { ifCompliances 3 }
::= { ifCompliances 3 }
-- units of conformance
--一致性单位
ifGeneralInformationGroup OBJECT-GROUP
OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName, ifNumber, ifAlias,
ifTableLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information applicable to
all network interfaces."
::= { ifGroups 10 }
ifGeneralInformationGroup OBJECT-GROUP
OBJECTS { ifIndex, ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName, ifNumber, ifAlias,
ifTableLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information applicable to
all network interfaces."
::= { ifGroups 10 }
-- the following five groups are mutually exclusive; at most
-- one of these groups is implemented for any interface
-- the following five groups are mutually exclusive; at most
-- one of these groups is implemented for any interface
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) character-oriented or fixed-length-transmission
network interfaces."
::= { ifGroups 2 }
ifFixedLengthGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) character-oriented or fixed-length-transmission
network interfaces."
::= { ifGroups 2 }
ifHCFixedLengthGroup OBJECT-GROUP OBJECTS { ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors } STATUS current DESCRIPTION
ifHCFixedLengthGroup对象组对象{ifHCInOctets、ifHCOutOctets、ifInOctets、ifOutOctets、IFUnknownProtos、ifInErrors、ifOutErrors}状态当前描述
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second) character-
oriented or fixed-length-transmission network interfaces."
::= { ifGroups 3 }
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second) character-
oriented or fixed-length-transmission network interfaces."
::= { ifGroups 3 }
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 4 }
ifPacketGroup OBJECT-GROUP
OBJECTS { ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
non-high speed (non-high speed interfaces transmit and
receive at speeds less than or equal to 20,000,000
bits/second) packet-oriented network interfaces."
::= { ifGroups 4 }
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second but less
than or equal to 650,000,000 bits/second) packet-oriented
network interfaces."
::= { ifGroups 5 }
ifHCPacketGroup OBJECT-GROUP
OBJECTS { ifHCInOctets, ifHCOutOctets,
ifInOctets, ifOutOctets, ifInUnknownProtos,
ifInErrors, ifOutErrors,
ifMtu, ifInUcastPkts, ifInMulticastPkts,
ifInBroadcastPkts, ifInDiscards,
ifOutUcastPkts, ifOutMulticastPkts,
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
high speed (greater than 20,000,000 bits/second but less
than or equal to 650,000,000 bits/second) packet-oriented
network interfaces."
::= { ifGroups 5 }
ifVHCPacketGroup OBJECT-GROUP OBJECTS { ifHCInUcastPkts, ifHCInMulticastPkts, ifHCInBroadcastPkts, ifHCOutUcastPkts, ifHCOutMulticastPkts, ifHCOutBroadcastPkts, ifHCInOctets, ifHCOutOctets, ifInOctets, ifOutOctets, ifInUnknownProtos, ifInErrors, ifOutErrors, ifMtu, ifInUcastPkts, ifInMulticastPkts, ifInBroadcastPkts, ifInDiscards, ifOutUcastPkts, ifOutMulticastPkts,
ifVHCPacketGroup对象组对象{IfhcInCastPKTs、ifHCInMulticastPkts、IfhcOutCastPKTs、ifHCOutBroadcastPkts、ifHCInOctets、ifHCOutOctets、ifInOctets、IfOctets、IfUnknown-Protos、IfInRorror、IfOutCastPKTs、ifInMulticastPkts、ifInBroadcastPkts、ifInDiscards、IfUctUctTs、IfOutUcattPKTs、ifOutMulticastPkts，
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
higher speed (greater than 650,000,000 bits/second) packet-
oriented network interfaces."
::= { ifGroups 6 }
ifOutBroadcastPkts, ifOutDiscards,
ifPromiscuousMode }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
higher speed (greater than 650,000,000 bits/second) packet-
oriented network interfaces."
::= { ifGroups 6 }
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
ifRcvAddressGroup OBJECT-GROUP
OBJECTS { ifRcvAddressStatus, ifRcvAddressType }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
multiple addresses which an interface receives."
::= { ifGroups 7 }
ifStackGroup2 OBJECT-GROUP
OBJECTS { ifStackStatus, ifStackLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 11 }
ifStackGroup2 OBJECT-GROUP
OBJECTS { ifStackStatus, ifStackLastChange }
STATUS current
DESCRIPTION
"A collection of objects providing information on the
layering of MIB-II interfaces."
::= { ifGroups 11 }
ifCounterDiscontinuityGroup OBJECT-GROUP
OBJECTS { ifCounterDiscontinuityTime }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
interface counter discontinuities."
::= { ifGroups 13 }
ifCounterDiscontinuityGroup OBJECT-GROUP
OBJECTS { ifCounterDiscontinuityTime }
STATUS current
DESCRIPTION
"A collection of objects providing information specific to
interface counter discontinuities."
::= { ifGroups 13 }
linkUpDownNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { linkUp, linkDown }
STATUS current
DESCRIPTION
"The notifications which indicate specific changes in the
value of ifOperStatus."
::= { ifGroups 14 }
linkUpDownNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { linkUp, linkDown }
STATUS current
DESCRIPTION
"The notifications which indicate specific changes in the
value of ifOperStatus."
::= { ifGroups 14 }
-- Deprecated Definitions - Objects
--不推荐使用的定义-对象
--
-- The Interface Test Table
--
-- This group of objects is optional. However, a media-specific
--
-- The Interface Test Table
--
-- This group of objects is optional. However, a media-specific
-- MIB may make implementation of this group mandatory.
--
-- This table replaces the ifExtnsTestTable
--
-- MIB may make implementation of this group mandatory.
--
-- This table replaces the ifExtnsTestTable
--
ifTestTable OBJECT-TYPE SYNTAX SEQUENCE OF IfTestEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION "This table contains one entry per interface. It defines objects which allow a network manager to instruct an agent to test an interface for various faults. Tests for an interface are defined in the media-specific MIB for that interface. After invoking a test, the object ifTestResult can be read to determine the outcome. If an agent can not perform the test, ifTestResult is set to so indicate. The object ifTestCode can be used to provide further test-specific or interface-specific (or even enterprise-specific) information concerning the outcome of the test. Only one test can be in progress on each interface at any one time. If one test is in progress when another test is invoked, the second test is rejected. Some agents may reject a test when a prior test is active on another interface.
IfTestEntry MAX-ACCESS的ifTestTable对象类型语法序列不可访问状态不推荐的说明“此表包含每个接口的一个条目。它定义了允许网络管理器指示代理测试接口是否存在各种故障的对象。接口的测试在该接口的媒体特定MIB中定义。调用测试后，可以读取对象ifTestResult以确定结果。如果某个代理无法执行测试，则ifTestResult设置为指示。ObjectIFTestCode可用于提供有关测试结果的更多特定于测试或特定于接口（甚至特定于企业）的信息。在任何时候，每个接口上只能进行一次测试。如果调用另一个测试时一个测试正在进行，则第二个测试将被拒绝。当先前的测试在另一个接口上处于活动状态时，某些代理可能会拒绝测试。
Before starting a test, a manager-station must first obtain 'ownership' of the entry in the ifTestTable for the interface to be tested. This is accomplished with the ifTestId and ifTestStatus objects as follows:
在开始测试之前，manager工作站必须首先获得待测试接口的ifTestTable中条目的“所有权”。这是通过ifTestId和ifTestStatus对象实现的，如下所示：
try_again: get (ifTestId, ifTestStatus) while (ifTestStatus != notInUse) /* * Loop while a test is running or some other * manager is configuring a test. */ short delay get (ifTestId, ifTestStatus) }
重试：在测试正在运行或其他*管理器正在配置测试时，获取（ifTestId，ifTestStatus）while（ifTestStatus！=notInUse）/**循环。*/短延迟获取（ifTestId，ifTestStatus）}
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
/*
* Is not being used right now -- let's compete
* to see who gets it.
*/
lock_value = ifTestId
if ( set(ifTestId = lock_value, ifTestStatus = inUse,
如果（设置）（ifTestId=lock_值，ifTestStatus=inUse，
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
ifTestOwner = 'my-IP-address') == FAILURE)
/*
* Another manager got the ifTestEntry -- go
* try again
*/
goto try_again;
/*
* I have the lock
*/
set up any test parameters.
/*
* I have the lock
*/
set up any test parameters.
/*
* This starts the test
*/
set(ifTestType = test_to_run);
/*
* This starts the test
*/
set(ifTestType = test_to_run);
wait for test completion by polling ifTestResult
通过轮询ifTestResult等待测试完成
when test completes, agent sets ifTestResult agent also sets ifTestStatus = 'notInUse'
测试完成后，代理设置ifTestResult代理还设置ifTestStatus='notInUse'
retrieve any additional test results, and ifTestId
检索任何其他测试结果，然后单击ifTestId
if (ifTestId == lock_value+1) results are valid
if (ifTestId == lock_value+1) results are valid
A manager station first retrieves the value of the appropriate ifTestId and ifTestStatus objects, periodically repeating the retrieval if necessary, until the value of ifTestStatus is 'notInUse'. The manager station then tries to set the same ifTestId object to the value it just retrieved, the same ifTestStatus object to 'inUse', and the corresponding ifTestOwner object to a value indicating itself. If the set operation succeeds then the manager has obtained ownership of the ifTestEntry, and the value of the ifTestId object is incremented by the agent (per the semantics of TestAndIncr). Failure of the set operation indicates that some other manager has obtained ownership of the ifTestEntry.
管理器工作站首先检索适当的ifTestId和ifTestStatus对象的值，必要时定期重复检索，直到ifTestStatus的值为“notInUse”。然后，管理器工作站尝试将相同的ifTestId对象设置为刚检索到的值，将相同的ifTestStatus对象设置为“inUse”，并将相应的ifTestOwner对象设置为指示其自身的值。如果set操作成功，则管理器已获得ifTestEntry的所有权，并且ifTestId对象的值由代理递增（根据TestAndIncr的语义）。set操作失败表示其他管理器已获得ifTestEntry的所有权。
Once ownership is obtained, any test parameters can be setup, and then the test is initiated by setting ifTestType. On completion of the test, the agent sets ifTestStatus to 'notInUse'. Once this occurs, the manager can retrieve the results. In the (rare) event that the invocation of tests by two network managers were to overlap, then there would be a possibility that the first test's results might be overwritten by the second test's results prior to the first
一旦获得所有权，就可以设置任何测试参数，然后通过设置ifTestType启动测试。测试完成后，代理将ifTestStatus设置为“notInUse”。一旦发生这种情况，经理可以检索结果。在两个网络管理器调用测试发生重叠的（罕见）事件中，第一个测试的结果可能会在第一个测试之前被第二个测试的结果覆盖
results being read. This unlikely circumstance can be detected by a network manager retrieving ifTestId at the same time as retrieving the test results, and ensuring that the results are for the desired request.
正在读取结果。网络管理器在检索测试结果的同时检索ifTestId，并确保结果符合所需的请求，可以检测到这种不太可能的情况。
If ifTestType is not set within an abnormally long period of time after ownership is obtained, the agent should time-out the manager, and reset the value of the ifTestStatus object back to 'notInUse'. It is suggested that this time-out period be 5 minutes.
如果在获得所有权后的异常长时间内未设置ifTestType，则代理应暂停管理器，并将ifTestStatus对象的值重置回“notInUse”。建议此超时时间为5分钟。
In general, a management station must not retransmit a request to invoke a test for which it does not receive a response; instead, it properly inspects an agent's MIB to determine if the invocation was successful. Only if the invocation was unsuccessful, is the invocation request retransmitted.
一般来说，管理站不得重新传输调用其未收到响应的测试的请求；相反，它会正确地检查代理的MIB以确定调用是否成功。只有在调用失败时，才会重新传输调用请求。
Some tests may require the interface to be taken off-line in
order to execute them, or may even require the agent to
reboot after completion of the test. In these
circumstances, communication with the management station
invoking the test may be lost until after completion of the
test. An agent is not required to support such tests.
However, if such tests are supported, then the agent should
make every effort to transmit a response to the request
which invoked the test prior to losing communication. When
the agent is restored to normal service, the results of the
test are properly made available in the appropriate objects.
Note that this requires that the ifIndex value assigned to
an interface must be unchanged even if the test causes a
reboot. An agent must reject any test for which it cannot,
perhaps due to resource constraints, make available at least
the minimum amount of information after that test
completes."
::= { ifMIBObjects 3 }
Some tests may require the interface to be taken off-line in
order to execute them, or may even require the agent to
reboot after completion of the test. In these
circumstances, communication with the management station
invoking the test may be lost until after completion of the
test. An agent is not required to support such tests.
However, if such tests are supported, then the agent should
make every effort to transmit a response to the request
which invoked the test prior to losing communication. When
the agent is restored to normal service, the results of the
test are properly made available in the appropriate objects.
Note that this requires that the ifIndex value assigned to
an interface must be unchanged even if the test causes a
reboot. An agent must reject any test for which it cannot,
perhaps due to resource constraints, make available at least
the minimum amount of information after that test
completes."
::= { ifMIBObjects 3 }
ifTestEntry OBJECT-TYPE
SYNTAX IfTestEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry containing objects for invoking tests on an
interface."
AUGMENTS { ifEntry }
::= { ifTestTable 1 }
ifTestEntry OBJECT-TYPE
SYNTAX IfTestEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry containing objects for invoking tests on an
interface."
AUGMENTS { ifEntry }
::= { ifTestTable 1 }
IfTestEntry ::=
IfTestEntry ::=
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
ifTestOwner OwnerString
}
SEQUENCE {
ifTestId TestAndIncr,
ifTestStatus INTEGER,
ifTestType AutonomousType,
ifTestResult INTEGER,
ifTestCode OBJECT IDENTIFIER,
ifTestOwner OwnerString
}
ifTestId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object identifies the current invocation of the
interface's test."
::= { ifTestEntry 1 }
ifTestId OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object identifies the current invocation of the
interface's test."
::= { ifTestEntry 1 }
ifTestStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object indicates whether or not some manager currently
has the necessary 'ownership' required to invoke a test on
this interface. A write to this object is only successful
when it changes its value from 'notInUse(1)' to 'inUse(2)'.
After completion of a test, the agent resets the value back
to 'notInUse(1)'."
::= { ifTestEntry 2 }
ifTestStatus OBJECT-TYPE
SYNTAX INTEGER { notInUse(1), inUse(2) }
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"This object indicates whether or not some manager currently
has the necessary 'ownership' required to invoke a test on
this interface. A write to this object is only successful
when it changes its value from 'notInUse(1)' to 'inUse(2)'.
After completion of a test, the agent resets the value back
to 'notInUse(1)'."
::= { ifTestEntry 2 }
ifTestType OBJECT-TYPE SYNTAX AutonomousType MAX-ACCESS read-write STATUS deprecated DESCRIPTION "A control variable used to start and stop operator-initiated interface tests. Most OBJECT IDENTIFIER values assigned to tests are defined elsewhere, in association with specific types of interface. However, this document assigns a value for a full-duplex loopback test, and defines the special meanings of the subject identifier:
ifTestType对象类型语法自治类型MAX-ACCESS读写状态不推荐的说明“用于启动和停止操作员启动的接口测试的控制变量。分配给测试的大多数对象标识符值都在别处定义，与特定类型的接口相关联。但是，本文件为全双工环回测试分配了一个值，并定义了主题标识符的特殊含义：
noTest OBJECT IDENTIFIER ::= { 0 0 }
noTest OBJECT IDENTIFIER ::= { 0 0 }
When the value noTest is written to this object, no action is taken unless a test is in progress, in which case the test is aborted. Writing any other value to this object is
将值noTest写入此对象时，除非测试正在进行，否则不会采取任何操作，在这种情况下，测试将中止。向该对象写入任何其他值都是错误的
only valid when no test is currently in progress, in which case the indicated test is initiated.
仅在当前未进行任何测试时有效，在这种情况下，指示的测试将启动。
When read, this object always returns the most recent value
that ifTestType was set to. If it has not been set since
the last initialization of the network management subsystem
on the agent, a value of noTest is returned."
::= { ifTestEntry 3 }
When read, this object always returns the most recent value
that ifTestType was set to. If it has not been set since
the last initialization of the network management subsystem
on the agent, a value of noTest is returned."
::= { ifTestEntry 3 }
ifTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object contains the result of the most recently
requested test, or the value none(1) if no tests have been
requested since the last reset. Note that this facility
provides no provision for saving the results of one test
when starting another, as could be required if used by
multiple managers concurrently."
::= { ifTestEntry 4 }
ifTestResult OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no test yet requested
success(2),
inProgress(3),
notSupported(4),
unAbleToRun(5), -- due to state of system
aborted(6),
failed(7)
}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"This object contains the result of the most recently
requested test, or the value none(1) if no tests have been
requested since the last reset. Note that this facility
provides no provision for saving the results of one test
when starting another, as could be required if used by
multiple managers concurrently."
::= { ifTestEntry 4 }
ifTestCode OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS deprecated DESCRIPTION "This object contains a code which contains more specific information on the test result, for example an error-code after a failed test. Error codes and other values this object may take are specific to the type of interface and/or test. The value may have the semantics of either the AutonomousType or InstancePointer textual conventions as defined in RFC 2579. The identifier:
ifTestCode对象类型语法对象标识符MAX-ACCESS只读状态不推荐的说明“此对象包含一个代码，其中包含有关测试结果的更具体信息，例如测试失败后的错误代码。”。此对象可能采用的错误代码和其他值特定于接口和/或测试的类型。该值可能具有RFC 2579中定义的自治类型或InstancePointer文本约定的语义。标识符：
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }
is defined for use if no additional result code is
available."
::= { ifTestEntry 5 }
ifTestOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"The entity which currently has the 'ownership' required to
invoke a test on this interface."
::= { ifTestEntry 6 }
ifTestOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"The entity which currently has the 'ownership' required to
invoke a test on this interface."
::= { ifTestEntry 6 }
-- Deprecated Definitions - Groups
--不推荐使用的定义-组
ifGeneralGroup OBJECT-GROUP
OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName }
STATUS deprecated
DESCRIPTION
"A collection of objects deprecated in favour of
ifGeneralInformationGroup."
::= { ifGroups 1 }
ifGeneralGroup OBJECT-GROUP
OBJECTS { ifDescr, ifType, ifSpeed, ifPhysAddress,
ifAdminStatus, ifOperStatus, ifLastChange,
ifLinkUpDownTrapEnable, ifConnectorPresent,
ifHighSpeed, ifName }
STATUS deprecated
DESCRIPTION
"A collection of objects deprecated in favour of
ifGeneralInformationGroup."
::= { ifGroups 1 }
ifTestGroup OBJECT-GROUP
OBJECTS { ifTestId, ifTestStatus, ifTestType,
ifTestResult, ifTestCode, ifTestOwner }
STATUS deprecated
DESCRIPTION
"A collection of objects providing the ability to invoke
tests on an interface."
::= { ifGroups 8 }
ifTestGroup OBJECT-GROUP
OBJECTS { ifTestId, ifTestStatus, ifTestType,
ifTestResult, ifTestCode, ifTestOwner }
STATUS deprecated
DESCRIPTION
"A collection of objects providing the ability to invoke
tests on an interface."
::= { ifGroups 8 }
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS deprecated
DESCRIPTION
"The previous collection of objects providing information on
the layering of MIB-II interfaces."
::= { ifGroups 9 }
ifStackGroup OBJECT-GROUP
OBJECTS { ifStackStatus }
STATUS deprecated
DESCRIPTION
"The previous collection of objects providing information on
the layering of MIB-II interfaces."
::= { ifGroups 9 }
ifOldObjectsGroup OBJECT-GROUP OBJECTS { ifInNUcastPkts, ifOutNUcastPkts, ifOutQLen, ifSpecific } STATUS deprecated DESCRIPTION
ifOldObjectsGroup对象组对象{IFinnuCastPts、ifOutNUcastPkts、ifOutQLen、ifSpecific}状态已弃用说明
"The collection of objects deprecated from the original MIB-
II interfaces group."
::= { ifGroups 12 }
"The collection of objects deprecated from the original MIB-
II interfaces group."
::= { ifGroups 12 }
-- Deprecated Definitions - Compliance
--不推荐使用的定义-法规遵从性
ifCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "A compliance statement defined in a previous version of this MIB module, for SNMP entities which have network interfaces."
ifCompliance MODULE-COMPLIANCE STATUS Disprecated DESCRIPTION“此MIB模块的早期版本中定义的符合性声明，适用于具有网络接口的SNMP实体。”
MODULE -- this module MANDATORY-GROUPS { ifGeneralGroup, ifStackGroup }
MODULE--此模块为强制组{ifGeneralGroup，ifStackGroup}
GROUP ifFixedLengthGroup DESCRIPTION "This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units."
组ifFixedLengthGroup DESCRIPTION“此组对于所有面向字符或以固定长度传输单元传输数据的网络接口都是必需的。”
GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory only for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second."
GROUP ifHCFixedLengthGroup DESCRIPTION“此组仅对那些面向字符或以固定长度传输单元传输数据的网络接口是强制性的，并且对于这些网络接口，ifSpeed的相应实例的值大于20000000位/秒。”
GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented."
GROUP ifPacketGroup DESCRIPTION“此组对于所有面向数据包的网络接口都是必需的。”
GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second."
GROUP ifHCPacketGroup DESCRIPTION“此组仅对于面向数据包且ifSpeed对应实例的值大于650000000位/秒的网络接口是必需的。”
GROUP ifTestGroup DESCRIPTION "This group is optional. Media-specific MIBs which require interface tests are strongly encouraged to use this group for invoking tests and reporting results. A medium specific MIB which has mandatory tests may make implementation of
GROUP ifTestGroup DESCRIPTION“此组是可选的。强烈建议需要接口测试的媒体特定MIB使用此组调用测试和报告结果。具有强制测试的媒体特定MIB可以实现
this group mandatory."
此组是必需的。”
GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group."
GROUP IfrcvaAddressGroup DESCRIPTION“此组的适用性必须由特定于媒体的MIB定义。特定于媒体的MIB必须定义此组中地址的确切含义、用途和语义。”
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象ifLinkUpDownTrapEnable最小访问只读描述“不需要写访问”
OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象IFPROMISCUUSMODE MIN-ACCESS只读说明“不需要写访问权限。”
OBJECT ifStackStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)."
OBJECT ifStackStatus SYNTAX INTEGER{active（1）}——RowStatus MIN-ACCESS只读描述的子集“不需要写访问，并且只需要支持RowStatus文本约定的六个枚举值中的一个，特别是：active（1）”
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the value
testing(3)."
::= { ifCompliances 1 }
OBJECT ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, nor is support for the value
testing(3)."
::= { ifCompliances 1 }
ifCompliance2 MODULE-COMPLIANCE STATUS deprecated DESCRIPTION "A compliance statement defined in a previous version of this MIB module, for SNMP entities which have network interfaces."
ifCompliance2 MODULE-COMPLIANCE STATUS Disprecated DESCRIPTION“此MIB模块的早期版本中为具有网络接口的SNMP实体定义的符合性声明。”
MODULE -- this module MANDATORY-GROUPS { ifGeneralInformationGroup, ifStackGroup2, ifCounterDiscontinuityGroup }
MODULE--此模块为强制组{IFGeneralInformation组、ifStackGroup2、IFCounterInterructionGroup}
GROUP ifFixedLengthGroup DESCRIPTION
组IfixedLength组描述
"This group is mandatory for all network interfaces which are character-oriented or transmit data in fixed-length transmission units."
“对于所有面向字符或以固定长度传输单元传输数据的网络接口，此组是必需的。”
GROUP ifHCFixedLengthGroup DESCRIPTION "This group is mandatory only for those network interfaces which are character-oriented or transmit data in fixed-length transmission units, and for which the value of the corresponding instance of ifSpeed is greater than 20,000,000 bits/second."
GROUP ifHCFixedLengthGroup DESCRIPTION“此组仅对那些面向字符或以固定长度传输单元传输数据的网络接口是强制性的，并且对于这些网络接口，ifSpeed的相应实例的值大于20000000位/秒。”
GROUP ifPacketGroup DESCRIPTION "This group is mandatory for all network interfaces which are packet-oriented."
GROUP ifPacketGroup DESCRIPTION“此组对于所有面向数据包的网络接口都是必需的。”
GROUP ifHCPacketGroup DESCRIPTION "This group is mandatory only for those network interfaces which are packet-oriented and for which the value of the corresponding instance of ifSpeed is greater than 650,000,000 bits/second."
GROUP ifHCPacketGroup DESCRIPTION“此组仅对于面向数据包且ifSpeed对应实例的值大于650000000位/秒的网络接口是必需的。”
GROUP ifRcvAddressGroup DESCRIPTION "The applicability of this group MUST be defined by the media-specific MIBs. Media-specific MIBs must define the exact meaning, use, and semantics of the addresses in this group."
GROUP IfrcvaAddressGroup DESCRIPTION“此组的适用性必须由特定于媒体的MIB定义。特定于媒体的MIB必须定义此组中地址的确切含义、用途和语义。”
OBJECT ifLinkUpDownTrapEnable MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象ifLinkUpDownTrapEnable最小访问只读描述“不需要写访问”
OBJECT ifPromiscuousMode MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象IFPROMISCUUSMODE MIN-ACCESS只读说明“不需要写访问权限。”
OBJECT ifStackStatus SYNTAX INTEGER { active(1) } -- subset of RowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required, and only one of the six enumerated values for the RowStatus textual convention need be supported, specifically: active(1)."
OBJECT ifStackStatus SYNTAX INTEGER{active（1）}——RowStatus MIN-ACCESS只读描述的子集“不需要写访问，并且只需要支持RowStatus文本约定的六个枚举值中的一个，特别是：active（1）”
OBJECT ifAdminStatus SYNTAX INTEGER { up(1), down(2) } MIN-ACCESS read-only DESCRIPTION "Write access is not required, nor is support for the value testing(3)."
对象ifAdminStatus语法整数{up（1），down（2）}MIN-ACCESS只读说明“不需要写访问，也不支持值测试（3）”
OBJECT ifAlias MIN-ACCESS read-only DESCRIPTION "Write access is not required."
对象IFALIA的最小访问只读描述“不需要写入访问权限”
::= { ifCompliances 2 }
::= { ifCompliances 2 }
END
终止
This memo has been produced by the IETF's Interfaces MIB working-group.
本备忘录由IETF接口MIB工作组编制。
The original proposal evolved from conversations and discussions with many people, including at least the following: Fred Baker, Ted Brunner, Chuck Davin, Jeremy Greene, Marshall Rose, Kaj Tesink, and Dean Throop.
最初的提案是由与许多人的对话和讨论演变而来的，其中至少包括以下人士：弗雷德·贝克、特德·布伦纳、查克·戴文、杰里米·格林、马歇尔·罗斯、卡伊·特辛克和迪安·斯洛普。
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] Harrington，D.，Presohn，R.和B.Wijnen，“描述SNMP管理框架的体系结构”，RFC 2571，1999年4月。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[2] Rose，M.和K.McCloghrie，“基于TCP/IP的互联网管理信息的结构和识别”，STD 16，RFC 1155，1990年5月。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[3] Rose，M.和K.McCloghrie，“简明MIB定义”，STD 16，RFC 1212，1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[4] Rose，M.“定义用于SNMP的陷阱的约定”，RFC1215，1991年3月。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[6] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[7] McCloghrie，K.，Perkins，D.，Schoenwaeld，J.，Case，J.，Rose，M.和S.Waldbusser，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] Case，J.，Fedor，M.，Schoffstall，M.和J.Davin，“简单网络管理协议”，STD 15，RFC 1157，1990年5月。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[9] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 19011996年1月。
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[10] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, January 1998.
[11] Case，J.，Harrington D.，Presuhn R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1998年1月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, January 1998.
[12] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 2574，1998年1月。
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[13] Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SMPv3 Applications", RFC 2573, January 1998.
[14] Levi，D.，Meyer，P.和B.Stewart，“SMPv3应用”，RFC2573，1998年1月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, January 1998.
[15] Wijnen，B.，Presuhn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，RFC 2575，1998年1月。
[16] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", BCP 14, RFC 2119, March 1997.
[16] Bradner，S.“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[17] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets - MIB-II", STD 17. RFC 1213, March 1991.
[17] McCloghrie，K.和M.Rose，“基于TCP/IP的互联网网络管理的管理信息库-MIB-II”，STD 17。RFC 1213，1991年3月。
[18] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[18] Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[19] McCloghrie, K., "Extensions to the Generic-Interface MIB", RFC 1229, May 1991.
[19] 《通用接口MIB的扩展》，RFC1229，1991年5月。
[20] ATM Forum Technical Committee, "LAN Emulation Client Management: Version 1.0 Specification", af-lane-0044.000, ATM Forum, September 1995.
[20] ATM论坛技术委员会，“局域网仿真客户端管理：1.0版规范”，af-lane-0044.000，ATM论坛，1995年9月。
[21] Stewart, B., "Definitions of Managed Objects for Character Stream Devices using SMIv2", RFC 1658, July 1994.
[21] Stewart，B.“使用SMIv2的字符流设备的托管对象定义”，RFC1658，1994年7月。
[22] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[22] Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准网络管理框架第3版简介”，RFC 25701999年4月。
[23] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces Group of MIB-II", RFC 1573, January 1994.
[23] McCloghrie，K.和F.Kastenholz，“MIB-II接口组的演变”，RFC 1573，1994年1月。
[24] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[24] McCloghrie，K.和F.Kastenholz，“使用SMIv2的接口组MIB”，RFC 2233，1997年11月。
There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.
此MIB中定义了许多管理对象，它们的MAX-ACCESS子句为read-write和/或read-create。在某些网络环境中，此类对象可能被视为敏感或易受攻击。在没有适当保护的非安全环境中支持SET操作可能会对网络操作产生负面影响。
In particular, write-able objects allow an administrator to control the interfaces and to perform tests on the interfaces, and unauthorized access to these could cause a denial of service, or in combination with other (e.g., physical) security breaches, could cause unauthorized connectivity to a device.
特别是，可写对象允许管理员控制接口并对接口执行测试，未经授权的访问可能会导致拒绝服务，或者与其他（例如，物理）安全漏洞相结合，可能会导致未经授权的设备连接。
SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB.
SNMPv1本身不是一个安全的环境。即使网络本身是安全的（例如通过使用IPSec），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）此MIB中的对象。
It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [12] and the View- based Access Control Model RFC 2575 [15] is recommended.
建议实施者考虑SNMPv3框架提供的安全特性。具体而言，建议使用基于用户的安全模型RFC2574[12]和基于视图的访问控制模型RFC2575[15]。
It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
然后，客户/用户有责任确保授予对此MIB实例访问权限的SNMP实体被正确配置为仅授予那些拥有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）对对象的访问权限。
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706
Keith McCloghrie Cisco Systems，Inc.加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
Phone: 408-526-5260 EMail: kzm@cisco.com"
电话：408-526-5260电子邮件：kzm@cisco.com"
Frank Kastenholz Argon Networks 25 Porter Rd Littleton Ma 01460
马萨诸塞州利特尔顿波特路25号弗兰克·卡斯滕霍尔茨氩气网络公司01460
Phone: (508)685-4000 EMail: kasten@argon.com
电话：（508）685-4000电子邮件：kasten@argon.com
Added linkUpDownNotificationsGroup.
添加了linkUpDownNotificationsGroup。
Changed the status of the definition of OwnerString in this MIB to be deprecated, because it is only used by ifTestOwner, which is now deprecated, and because other MIBs should import OwnerString from RFC 1757 or its successors.
已将此MIB中OwnerString定义的状态更改为不推荐使用，因为它仅由ifTestOwner使用，而ifTestOwner现在已不推荐使用，并且其他MIB应从RFC 1757或其后续MIB导入OwnerString。
Added ifCompliance3 as a replacement for ifCompliance2 to omit the ifStackGroup2 group, and add linkUpDownNotificationsGroup. Also, corrected the omission of ifVHCPacketGroup, and typos in the DESCRIPTIONs of ifHCPacketGroup and ifFixedLengthGroup. Obsoleted ifCompliance2.
添加了IFCompliance 3作为IFCompliance 2的替代，以省略ifStackGroup2组，并添加linkUpDownNotificationsGroup。此外，还更正了ifVHCPacketGroup的遗漏以及ifHCPacketGroup和ifFixedLengthGroup描述中的打字错误。已过时的IF2合规性。
Modified syntax of ifStackHigherLayer and ifStackLowerLayer to be InterfaceIndexOrZero.
将ifStackHigherLayer和ifStackLowerLayer的语法修改为InterfaceIndexOrZero。
Added requirement that media-specific MIB designers specify any special conditions concerning the counting of framing characters in ifInOctets and ifOutOctets.
增加了特定于媒体的MIB设计人员指定有关ifInOctets和IFOUTPoctets中帧字符计数的任何特殊条件的要求。
Corrected a typo in the DESCRIPTION of the linkUp notification.
更正了链接通知说明中的键入错误。
Modified the introductory SNMP Network Management Framework boilerplate text.
修改了介绍性SNMP网络管理框架样板文本。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。