Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4750

OSPF Version 2 Management Information Base

Pages: 121
Proposed Standard
Errata
Obsoletes:  1850
Part 1 of 5 – Pages 1 to 7
None   None   Next

Top   ToC   RFC4750 - Page 1
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.
Top   ToC   RFC4750 - Page 2

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
Top   ToC   RFC4750 - Page 3
      B.7. OSPF Trap MIB ............................................117
      B.8. Miscellaneous ............................................118

1. 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).
Top   ToC   RFC4750 - Page 4

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.
Top   ToC   RFC4750 - Page 5
   - 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.
Top   ToC   RFC4750 - Page 6

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).
Top   ToC   RFC4750 - Page 7

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.


(next page on part 2)

Next Section