RFC2863标准_RFC2863资源-CSDN文库

MIB,

SNMP

需积分: 25 97 浏览量 2017-03-17 13:38:27 上传评论收藏 89KB PDF 举报

资源推荐

资源详情

资源评论

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

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.

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

McCloghrie & Kastenholz Standards Track [Page 1]

RFC 2863 The Interfaces Group MIB June 2000

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

1. Introduction

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.

The key words "MUST" and "MUST NOT" in this document are to be

interpreted as described in RFC 2119 [16].

2. The SNMP Network Management Framework

The SNMP Management Framework presently consists of five major

components:

o An overall architecture, described in 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 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].

McCloghrie & Kastenholz Standards Track [Page 2]

RFC 2863 The Interfaces Group MIB June 2000

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 A set of fundamental applications described in RFC 2573 [14]

and the view-based access control mechanism described in RFC

2575 [15].

A more detailed introduction to the current SNMP Management Framework

can be found in 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.

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.

3. Experience with the Interfaces Group

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.

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

McCloghrie & Kastenholz Standards Track [Page 3]

RFC 2863 The Interfaces Group MIB June 2000

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].

3.1. Clarifications/Revisions

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.

3.1.1. Interface Sub-Layers

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.

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.

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,

McCloghrie & Kastenholz Standards Track [Page 4]

RFC 2863 The Interfaces Group MIB June 2000

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.

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.

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

McCloghrie & Kastenholz Standards Track [Page 5]

剩余68页未读，继续阅读

评论收藏

内容反馈

focus_friends

粉丝: 2
资源: 6

RFC2863标准

RFC协议标准

RFC文档标准

RFC网络协议标准列表

RFC全部标准文档

HTTP RFC标准

RFC2617标准的Http认证（C和CPP两个工程）

RFC1035 DNS服务器标准 协议

rfc3640标准文档

RFC标准文档(全集0001-8191).zip

RFC2001~RFC3000（共999个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

SIP协议标准RFC3261-RFC2543

rfc2131pdf文档

SIP标准（RFC3261）

RFC4301(中文) IP安全架构(废除了RFC2401)

RFC中文文档全集【RFC1-3093】

RFC8001~RFC9000（共644个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC1001~RFC2000（共994个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

rfc 1928 标准文档

RFC7001~RFC8000（共996个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC1~RFC1000（共900个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及测试

RFC6001~RFC7000（共973个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC3001~RFC4000（共981个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC5001~RFC6000（共970个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC4001~RFC5000（共973个rfc标准的pdf文档） 计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

rfc全部文档离线下载rfc1-rfc8700

ASTM D2863 - 19 Standard Test Method for Measuring the Minimum

解决Win 10与不兼容VirtualBox操作过程文档+（附带软件）.zip

计算机网络知识点总结(谢希仁第八版).pdf

计算机网络第八版（谢希仁）课后习题答案

广联达3216锁终极授权 2024年

最新资源

RFC1035 DNS服务器标准协议

RFC2001~RFC3000（共999个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC8001~RFC9000（共644个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC1001~RFC2000（共994个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC7001~RFC8000（共996个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC1~RFC1000（共900个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及测试

RFC6001~RFC7000（共973个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC3001~RFC4000（共981个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC5001~RFC6000（共970个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及

RFC4001~RFC5000（共973个rfc标准的pdf文档）计算机网络+互联网标准+网络协议+RFC标准+网络协议开发及