Network Working Group D. Joyal, Ed. Request for Comments: 4750 Nortel Obsoletes: 1850 P. Galecki, Ed. Category: Standards Track Airvana S. Giacalone, Ed. CSFB Original Authors: R. Coltun Touch Acoustra F. Baker Cisco Systems December 2006 OSPF Version 2 Management Information Base 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. Copyright Notice Copyright (C) The IETF Trust (2006). 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 version 2 of the Open Shortest Path First Routing Protocol. Version 2 of the OSPF protocol is specific to the IPv4 address family. Version 3 of the OSPF protocol is specific to the IPv6 address family. This memo obsoletes RFC 1850; however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1850 are explained in Appendix B.
Table of Contents
1. Overview ........................................................3 1.1. The Internet-Standard Management Framework .................3 1.2. Conceptual Row Creation ....................................3 1.3. Default Configuration ......................................4 1.4. OSPF Counters ..............................................5 1.5. Multiple OSPF Instances ....................................5 1.6. Conventions ................................................6 2. Structure of This MIB ...........................................6 2.1. The Purposes of the Sections in This MIB ...................6 2.1.1. General Variables ...................................6 2.1.2. Area Data Structure and Area Stub Metric Table ......6 2.1.3. Link State Database and External Link State Database ............................................7 2.1.4. Address Table and Host Tables .......................7 2.1.5. Interface and Interface Metric Tables ...............7 2.1.6. Virtual Interface Table .............................7 2.1.7. Neighbor and Virtual Neighbor Tables ................7 2.1.8. Local Link State Database Table and Virtual Local Link State Database Table .....................7 2.1.9. AS-scope Link State Database Table ..................7 2.1.10. Area LSA Count Table ...............................7 3. OSPF MIB Module .................................................8 4. OSPF Trap Overview .............................................94 4.1. Introduction ..............................................94 4.2. Approach ..................................................95 4.3. Ignoring Initial Activity .................................95 4.4. Throttling Traps ..........................................95 4.5. One Trap Per OSPF Event ...................................96 4.6. Polling Event Counters ....................................96 4.7. Translating Notification Parameters .......................97 4.8. Historical Artifacts ......................................97 5. OSPF Trap Definitions ..........................................98 6. Security Considerations .......................................110 7. IANA Considerations ...........................................111 8. Acknowledgements ..............................................111 9. References ....................................................111 9.1. Normative References .....................................111 9.2. Informative References ...................................111 Appendix A. TOS Support ..........................................113 Appendix B. Changes from RFC 1850 ................................113 B.1. General Group Changes ....................................113 B.2. OSPF NSSA Enhancement Support ............................113 B.3. Opaque LSA Support .......................................114 B.4. Graceful Restart Support .................................116 B.5. OSPF Compliances .........................................116 B.6. OSPF Authentication and Security .........................117
B.7. OSPF Trap MIB ............................................117 B.8. Miscellaneous ............................................1181. Overview
1.1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].1.2. Conceptual Row Creation
For the benefit of row-creation in "conceptual" tables, DEFVAL (Default Value) clauses are included in the definitions in section 3, suggesting values that an agent should use for instances of variables that need to be created due to a Set-Request, but that are not specified in the Set-Request. DEFVAL clauses have not been specified for some objects that are read-only, implying that they are zeroed upon row creation. These objects are of the SYNTAX Counter32 or Gauge32. For those objects not having a DEFVAL clause, both management stations and agents should heed the Robustness Principle of the Internet (see [RFC791]): "be liberal in what you accept, conservative in what you send" Therefore, 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 columnar objects 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).
1.3. 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 (AS). 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. - ifSpeed is estimated by the interface drivers. - The OSPF process automatically discovers all IP interfaces and creates corresponding OSPF interfaces. - The OSPF process automatically creates the areas required for the interfaces. The simplest configuration of an OSPF process requires the following: - 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. Non-broadcast multi-access (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. - No addresses will be summarized. - Metrics, being a measure of bit duration, are unambiguous and intelligent. - No virtual links will be configured.1.4. OSPF Counters
This MIB defines several counters, namely: - ospfOriginateNewLsas, ospfRxNewLsas in the ospfGeneralGroup - ospfSpfRuns, ospfAreaNssaTranslatorEvents in the ospfAreaTable - ospfIfEvents in the ospfIfTable - ospfVirtIfEvents in the ospfVirtIfTable - ospfNbrEvents in the ospfNbrTable - ospfVirtNbrEvents in the ospfVirtNbrTable As a best practice, a management entity, when reading these counters, should use the discontinuity object, ospfDiscontinuityTime, to determine if an event that would invalidate the management entity understanding of the counters has occurred. A restart of the OSPF routing process is a possible example of a discontinuity event.1.5. Multiple OSPF Instances
SNMPv3 supports "Contexts" that can be used to implement MIB views on multiple OSPF instances on the same system. See [RFC3411] or its successors for details.
1.6. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].2. Structure of This MIB
This MIB is composed of the following sections: General Variables Area Data Structure Area Stub Metric Table Link State Database (LSDB) Address Range Table Host Table Interface Table Interface Metric Table Virtual Interface Table Neighbor Table Virtual Neighbor Table External Link State Database Aggregate Range Table Local Link State Database AS-scope Link State Database It supports the base OSPFv2 specification [RFC2328] and extensions to OSPFv2 such as [RFC1765], [RFC1793], [RFC2370], [RFC3101] and [RFC3623]. There exists a separate MIB for notifications ("traps"), which is entirely optional.2.1. The Purposes of the Sections in This MIB
2.1.1. General Variables
The general variables describe (as it may seem from the name) variables that are global to the OSPF Process.2.1.2. Area Data Structure and Area Stub Metric Table
The Area Data Structure describes all of the OSPF Areas that the router participates in. The Area Table includes data for Not-So- Stubby-Area (NSSA) translation. The Area Stub Metric Table describes the metrics advertised into a stub area by the default router(s).
2.1.3. Link State Database and External Link State Database
The link state database is provided primarily to provide detailed information for network debugging.2.1.4. Address Table and Host Tables
The Address Range Table and Host Table are provided to view configured Network Summary and host route information.2.1.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. The Interface table includes link-local (Opaque type-9) link state advertisement (LSA) statistics.2.1.6. Virtual Interface Table
The Virtual Interface Table describes virtual links to the OSPF Process, similarly to the (non-virtual) Interface Tables. This Table includes link-local (Opaque type-9) LSA statistics.2.1.7. Neighbor and Virtual Neighbor Tables
The Neighbor Table and the Virtual Neighbor Table describe the neighbors to the OSPF Process.2.1.8. Local Link State Database Table and Virtual Local Link State Database Table
The Local Link State Database Table and Virtual Local Link State Database Table are identical to the OSPF LSDB Table in format, but contain only link-local (Opaque type-9) link state advertisements for non-virtual and virtual links.2.1.9. AS-scope Link State Database Table
The AS-scope Link State Database Table is identical to the OSPF LSDB Table in format, but contains only AS-scoped link state advertisements.2.1.10. Area LSA Count Table
The table, which maintains number of link state advertisements on the per-area, per-LSA-type basis.