📄 rfc1252.txt
字号:
Network Working Group F. Baker
Request for Comments: 1252 ACC
Obsoletes: RFC 1248 R. Coltun
Computer Science Center
August 1991
OSPF Version 2 Management Information Base
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
This memo replaces RFC 1248 which contained some minor errors in
referring to "experimental" and "standard-mib" in Section 5.
Distribution of this memo is unlimited.
Table of Contents
1. Abstract ............................................. 2
2. The Network Management Framework...................... 2
3. Objects .............................................. 2
3.1 Format of Definitions ............................... 3
4. Overview ............................................. 3
4.1 Textual Conventions ................................. 3
4.2 Structure of MIB .................................... 3
4.2.1 General Variables ................................. 4
4.2.2 Area Data Structure and Area Stub Metric Table .... 4
4.2.3 Link State Database ............................... 4
4.2.4 Address Table and Host Tables ..................... 4
4.2.5 Interface and Interface Metric Tables ............. 4
4.2.6 Virtual Interface Table ........................... 4
4.2.7 Neighbor and Virtual Neighbor Tables .............. 4
4.3 Conceptual Row Creation ............................. 5
4.4 Default Configuration ............................... 5
5. Definitions .......................................... 7
5.1 OSPF General Variables .............................. 8
5.2 OSPF Area Data Structure ............................ 11
5.3 OSPF Area Default Metric Table ...................... 14
5.4 OSPF Link State Database ............................ 16
5.5 OSPF Address Range Table ............................ 19
5.6 OSPF Host Table ..................................... 21
5.7 OSPF Interface Table ................................ 23
5.8 OSPF Interface Metric Table ......................... 28
5.9 OSPF Virtual Interface Table ........................ 31
5.10 OSPF Neighbor Table ................................ 34
Baker & Coltun [Page 1]
RFC 1252 OSPF Version 2 MIB August 1991
5.11 OSPF Virtual Neighbor Table ........................ 38
6. Acknowledgements ..................................... 40
7. References ........................................... 40
8. Security Considerations............................... 41
9. Authors' Addresses.................................... 42
1. Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing OSPF Version 2.
2. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212
defines a more concise description mechanism, which is wholly
consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. RFC 1213, defines MIB-II, an
evolution of MIB-I based on implementation experience and new
operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
3. Objects
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI. In particular, each object has a name, a syntax,
and an encoding. The name is an object identifier, an
administratively assigned name, which specifies an object type. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the OBJECT
DESCRIPTOR, to also refer to the object type.
The syntax of an object type defines the abstract data structure
corresponding to that object type. The ASN.1 language is used for
Baker & Coltun [Page 2]
RFC 1252 OSPF Version 2 MIB August 1991
this purpose. However, the SMI [3] purposely restricts the ASN.1
constructs which may be used. These restrictions are explicitly made
for simplicity.
The encoding of an object type is simply how that object type is
represented using the object type's syntax. Implicitly tied to the
notion of an object type's syntax and encoding is how the object type
is represented when being transmitted on the network.
The SMI specifies the use of the basic encoding rules of ASN.1 [8],
subject to the additional requirements imposed by the SNMP.
3.1. Format of Definitions
Section 5 contains contains the specification of all object types
contained in this MIB module. The object types are defined using the
conventions defined in the SMI, as amended by the extensions
specified in [9].
4. Overview
4.1. Textual Conventions
Several new data types are introduced as a textual convention in this
MIB document. These textual conventions enhance the readability of
the specification and can ease comparison with other specifications
if appropriate. It should be noted that the introduction of the
these textual conventions has no effect on either the syntax nor the
semantics of any managed objects. The use of these is merely an
artifact of the explanatory method used. Objects defined in terms of
one of these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or the SNMP
are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers and writers in pursuit
of the elusive goal of clear, concise, and unambiguous MIB documents.
The new data types are AreaID, RouterID, TOSType, Metric, BigMetric,
TruthValue, Status, Validation, PositiveInteger, HelloRange,
UpToMaxAge, InterfaceIndex, and DesignatedRouterPriority.
4.2. Structure of MIB
The MIB is composed of the following sections:
General Variables
Area Data Structure
Area Stub Metric Table
Link State Database
Baker & Coltun [Page 3]
RFC 1252 OSPF Version 2 MIB August 1991
Address Range Table
Host Table
Interface Table
Interface Metric Table
Virtual Interface Table
Neighbor Table
Virtual Neighbor Table
4.2.1. General Variables
The General Variables are about what they sound like; variables which
are global to the OSPF Process.
4.2.2. Area Data Structure and Area Stub Metric Table
The Area Data Structure describes the OSPF Areas that the router
participates in. The Area Stub Metric Table describes the metrics
advertised into a stub area by the default router(s).
4.2.3. Link State Database
The Link State Database is provided primarily to provide detailed
information for network debugging.
4.2.4. Address Table and Host Tables
The Address Range Table and Host Table are provided to view
configured Network Summary and Host Route information.
4.2.5. Interface and Interface Metric Tables
The Interface Table and the Interface Metric Table together describe
the various IP interfaces to OSPF. The metrics are placed in
separate tables in order to simplify dealing with multiple types of
service, and to provide flexibility in the event that the IP TOS
definition is changed in the future. A Default Value specification
is supplied for the TOS 0 (default) metric.
4.2.6. Virtual Interface Table
Likewise, the Virtual Interface Table describe virtual links to the
OSPF Process.
4.2.7. Neighbor and Virtual Neighbor Tables
The Neighbor Table and the Virtual Neighbor Table describe the
neighbors to the OSPF Process.
Baker & Coltun [Page 4]
RFC 1252 OSPF Version 2 MIB August 1991
4.3. Conceptual Row Creation
For the benefit of row-creation in "conceptual" (see [9]) tables,
DEFVAL (Default Value) clauses are included in the definitions in
section 5, suggesting values which an agent should use for instances
of variables which need to be created due to a Set-Request, but which
are not specified in the Set- Request. DEFVAL clauses have not been
specified for some objects which are read-only, implying that they
are zeroed upon row creation. These objects are of the SYNTAX
Counter or Gauge.
For those objects not having a DEFVAL clause, both management
stations and agents should heed the Robustness Principle of the
Internet (see RFC-791):
"be liberal in what you accept, conservative in what
you send"
That is, management stations should include as many of these columnar
objects as possible (e.g., all read-write objects) in a Set-Request
when creating a conceptual row; agents should accept a Set-Request
with as few of these as they need (e.g., the minimum contents of a
row creating SET consists of those objects for which, as they cannot
be intuited, no default is specified.).
There are numerous read-write objects in this MIB, as it is designed
for SNMP management of the protocol, not just SNMP monitoring of its
state. However, in the absence of a standard SNMP Security
architecture, it is acceptable for implementations to implement these
as read-only with an alternative interface for their modification.
4.4. Default Configuration
OSPF is a powerful routing protocol, equipped with features to handle
virtually any configuration requirement that might reasonably be
found within an Autonomous System. With this power comes a fair
degree of complexity, which the sheer number of objects in the MIB
will attest to. Care has therefore been taken, in constructing this
MIB, to define default values for virtually every object, to minimize
the amount of parameterization required in the typical case. That
default configuration is as follows:
Given the following assumptions:
- IP has already been configured
- The ifTable has already been configured
Baker & Coltun [Page 5]
RFC 1252 OSPF Version 2 MIB August 1991
- ifSpeed is estimated by the interface drivers
- The OSPF Process automatically discovers all IP
Interfaces and creates corresponding OSPF Interfaces
- The TOS 0 metrics are autonomously derived from
ifSpeed
- The OSPF Process automatically creates the Areas
required for the Interfaces
The simplest configuration of an OSPF process requires that:
- The OSPF Process be Enabled.
This can be accomplished with a single SET:
ospfAdminStat := enabled.
The configured system will have the following attributes:
- The RouterID will be one of the IP addresses of the
device
- The device will be neither an Area Border Router nor
an Autonomous System Border Router.
- Every IP Interface, with or without an address, will
be an OSPF Interface.
- The AreaID of each interface will be 0.0.0.0, the
Backbone.
- Authentication will be disabled
- All Broadcast and Point to Point interfaces will be
operational. NBMA Interfaces require the configuration
of at least one neighbor.
- Timers on all direct interfaces will be:
Hello Interval: 10 seconds
Dead Timeout: 40 Seconds
Retransmission: 5 Seconds
Transit Delay: 1 Second
Poll Interval: 120 Seconds
- no direct links to hosts will be configured.
Baker & Coltun [Page 6]
RFC 1252 OSPF Version 2 MIB August 1991
- no addresses will be summarized
- Metrics, being a measure of bit duration, are
unambiguous and intelligent.
- No Virtual Links will be configured.
5. Definitions
RFC1252-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter, Gauge, IpAddress
FROM RFC1155-SMI
mib-2
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9].
ospf OBJECT IDENTIFIER ::= { mib-2 13 }
-- The Area ID, in OSPF, has the same format as an IP Address,
-- but has the function of defining a summarization point for
-- Link State Advertisements
AreaID ::= IpAddress
-- The Router ID, in OSPF, has the same format as an IP Address,
-- but identifies the router independent of its IP Address.
RouterID ::= IpAddress
-- The OSPF Metric is defined as an unsigned value in the range
Metric ::= INTEGER (1..'FFFF'h)
BigMetric ::= INTEGER (1..'FFFFFF'h)
-- Boolean Values
TruthValue ::= INTEGER { true (1), false (2) }
-- Status Values
Status ::= INTEGER { enabled (1), disabled (2) }
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -