ietf-corpus

rfc-1850

OSPF Version 2 Management Information Base

F. Baker, R. Coltun
date1995-11 streamIETF areartg wgospf statusDRAFT STANDARD pages80 canonicalhttps://www.rfc-editor.org/rfc/rfc1850 doi10.17487/RFC1850
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 the Open Shortest Path First Routing Protocol. [STANDARDS-TRACK]

obsoleted by

obsoletes

Extracted elements (31)

design-rationale §2.4

For conceptual row creation, management stations should include as many read-write columnar objects as possible in a Set-Request; agents should accept a minimum (only objects for which no default can be intuited), following the Internet Robustness Principle of being liberal in what you accept and conservative in what you send.

snmp

design-rationale §2.3.5

Interface metrics are placed in a separate ospfIfMetricTable rather than directly in ospfIfTable to simplify handling of multiple types of service and to provide flexibility if the IP TOS definition changes in the future.

routing, snmp

design-rationale §2.1

ospfAuthType was moved from area-level to interface-level to match the granularity of the authentication key, and MD5 was added as an authentication type (value 2). The area-level ospfAuthType is now marked obsolete.

routing, security

design-rationale §2.1

PositiveInteger was changed from range 1..'FFFFFFFF'h to 1..'7FFFFFFF'h at the request of Marshall Rose to avoid values that are prone to interoperability issues in SNMPv2 signed integer handling.

snmp

design-rationale §2.1

The External Link State Database was split from the main ospfLsdbTable because AS External LSAs are typically very numerous and are replicated identically across all non-stub areas; keeping them separate prevents the main LSDB view from being dominated by external entries and simplifies management queries.

routing, snmp

design-rationale §2.5

The MIB is designed so that a single SET (ospfAdminStat := enabled) suffices to start an OSPF process with sensible defaults: RouterID from an interface address, all interfaces in area 0.0.0.0, no authentication, hello=10s, dead=40s, retransmit=5s, metrics derived from ifSpeed.

routing, snmp

design-rationale §4

Trap design follows three principles: (1) initial activity at startup is ignored to avoid trap floods during convergence; (2) traps are throttled to prevent storms; (3) one trap is sent per OSPF event rather than aggregating multiple events, with event counters available for polling to detect missed traps.

snmp, routing

interoperability-note §2.1

ospfAreaRangeTable is marked obsolete and replaced by ospfAreaAggregateTable, which adds ospfAreaAggregateLsdbType and ospfAreaAggregateMask indexes to accommodate NSSA aggregates and more precisely express address ranges. Implementations should migrate to the new table.

routing, snmp

interoperability-note §3.4

ospfLsdbType was extended to include multicastLink(6) for Group-membership LSAs and nssaExternalLink(7) for NSSA LSAs. AS External LSAs (type 5) remain valid in ospfLsdbTable for backward compatibility but should preferably appear in ospfExtLsdbTable.

routing

normative-requirement §3.1 MUST

ospfExtLsdbLimit MUST be set identically in all routers attached to the OSPF backbone and/or any regular OSPF area (stub areas and NSSAs are excluded). When the count of non-default AS-external-LSAs reaches this limit, the router enters OverflowState.

routing, snmp

normative-requirement §3.7 MUST

ospfIfHelloInterval must be the same for all routers attached to a common network. ospfIfRtrDeadInterval must likewise be the same for all routers on the common network and should be some multiple of the Hello interval.

routing

protocol-element §5.2

OSPF traps include ospfIfStateChange, ospfVirtIfStateChange, ospfNbrStateChange, ospfVirtNbrStateChange, ospfIfConfigError, ospfVirtIfConfigError, ospfIfAuthFailure, ospfVirtIfAuthFailure, ospfIfRxBadPacket, ospfVirtIfRxBadPacket, ospfTxRetransmit, ospfVirtIfTxRetransmit, ospfOriginateLsa, ospfMaxAgeLsa, ospfLsdbOverflow, and ospfLsdbApproachingOverflow.

routing, snmp

protocol-element §3.14

ospfAreaAggregateTable replaces the obsoleted ospfAreaRangeTable. It is indexed by ospfAreaAggregateAreaID, ospfAreaAggregateLsdbType (distinguishes type-3 vs. NSSA aggregates), ospfAreaAggregateNet, and ospfAreaAggregateMask. ospfAreaAggregateEffect controls whether matching subnets are advertised or suppressed.

routing, snmp

protocol-element §3.2

ospfAreaSummary controls import of summary LSAs into stub areas: noAreaSummary (default) means the router neither originates nor propagates summary LSAs and relies entirely on its default route; sendAreaSummary means the router both summarizes and propagates summary LSAs.

routing

protocol-element §3.2

ospfAreaTable describes configured parameters and cumulative statistics of each attached area, indexed by ospfAreaId. Fields include ospfAuthType (obsolete at area level), ospfImportAsExtern (importExternal/importNoExternal/importNssa), ospfSpfRuns, ospfAreaBdrRtrCount, ospfAreaLsaCount, ospfAreaLsaCksumSum, ospfAreaSummary, and ospfAreaStatus (RowStatus).

routing, snmp

protocol-element §3.1

ospfExitOverflowInterval specifies how many seconds after entering OverflowState a router will attempt to leave it and resume originating non-default AS-external-LSAs. A value of 0 (default) means the router will not leave OverflowState until restarted.

routing

protocol-element §3.12

ospfExtLsdbTable is a separate table for AS External LSAs (type 5), indexed by ospfExtLsdbType, ospfExtLsdbLsid, and ospfExtLsdbRouterId. It was split from ospfLsdbTable because external LSAs are numerous and replicated in all non-stub areas.

routing, snmp

protocol-element §3.1

ospfGeneralGroup contains global OSPF process variables including ospfRouterId (32-bit unique router identifier), ospfAdminStat (enabled/disabled), ospfVersionNumber (2), ospfAreaBdrRtrStatus, ospfASBdrRtrStatus, ospfExternLsaCount, ospfOriginateNewLsas, and ospfRxNewLsas.

snmp, routing

protocol-element §3.7

ospfIfAuthType at the interface level (0=none, 1=simplePassword, 2=MD5, >2 reserved for IANA) supersedes the obsolete area-level ospfAuthType. ospfIfAuthKey (OCTET STRING, up to 256 octets) always returns a zero-length string when read, regardless of the configured value.

routing, security, snmp

protocol-element §3.8

ospfIfMetricTable provides per-interface, per-TOS metrics indexed by interface address, addressless index, and TOSType. The default TOS 0 metric is computed as 10^8 / ifSpeed, yielding values such as 1 for >=100 Mbps, 10 for Ethernet, 65 for T1, and 10416 for 9.6 kbps.

routing, snmp

protocol-element §3.7

ospfIfTable describes OSPF interfaces indexed by ospfIfIpAddress and ospfAddressLessIf (0 for addressed interfaces, ifIndex for addressless). Key fields include ospfIfType (broadcast/nbma/pointToPoint/pointToMultipoint), ospfIfAdminStat, ospfIfRtrPriority (0 = ineligible for DR), ospfIfHelloInterval, ospfIfRtrDeadInterval, ospfIfState, ospfIfDesignatedRouter, ospfIfBackupDesignatedRouter, ospfIfAuthType, ospfIfAuthKey, ospfIfDemand, and ospfIfMulticastForwarding.

routing, snmp

protocol-element §3.4

ospfLsdbSequence is a signed 32-bit integer starting at 0x80000001 and incrementing to 0x7FFFFFFF, used to detect old and duplicate LSAs; larger values indicate more recent advertisements. ospfLsdbChecksum uses the Fletcher checksum over the complete advertisement excluding the age field so age can be incremented without recalculating.

routing

protocol-element §3.4

ospfLsdbTable represents the OSPF Link State Database (excluding AS External LSAs), indexed by ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid, and ospfLsdbRouterId. LSA types include routerLink(1), networkLink(2), summaryLink(3), asSummaryLink(4), asExternalLink(5), multicastLink(6), and nssaExternalLink(7). The full raw advertisement is exposed via ospfLsdbAdvertisement (OCTET STRING).

routing, snmp

protocol-element §3.1

ospfMulticastExtensions is a bit mask indicating the router's IP multicast forwarding capability: bit 0 = intra-area, bit 1 = inter-area, bit 2 = inter-AS. Only combinations 0, 1, 3, 5, and 7 are valid; default is 0 (no multicast forwarding).

routing, multicast

protocol-element §3.10

ospfNbrTable describes non-virtual OSPF neighbors indexed by ospfNbrIpAddr and ospfNbrAddressLessIndex. Fields include ospfNbrRtrId, ospfNbrOptions (bit mask for TOS support, external LSA capability, multicast, NSSA), ospfNbrPriority, ospfNbrState, ospfNbrLsRetransQLen, ospfNbmaNbrPermanence (dynamic/permanent), and ospfNbrHelloSuppressed.

routing, snmp

protocol-element §3.3

ospfStubAreaTable describes the metrics a default Area Border Router will advertise into a stub area, indexed by ospfStubAreaId and ospfStubTOS. ospfStubMetricType can be ospfMetric (OSPF internal), comparableCost (external type 1), or nonComparable (external type 2).

routing, snmp

protocol-element §3.9

ospfVirtIfTable describes virtual links indexed by ospfVirtIfAreaId (transit area, never 0.0.0.0) and ospfVirtIfNeighbor (router ID). Configurable parameters include transit delay, retransmission interval, hello interval (default 10s), and dead interval (default 60s). ospfVirtIfState has only two values: down(1) and pointToPoint(4).

routing, snmp

security-consideration §3.7

ospfIfAuthKey and ospfVirtIfAuthKey always return a zero-length OCTET STRING when read via SNMP, preventing authentication credential exposure through the MIB. Simple password authentication is limited to keys of at most 8 octets; larger keys are only useful with authentication mechanisms beyond this specification.

security, snmp, routing

security-consideration §8

Several MIB objects have read-write or read-create access and may be sensitive in some environments; implementations should control even GET access and consider encrypting values over the network. In the absence of a standard SNMP security architecture, read-write objects may be implemented as read-only with an alternative interface for modification.

security, snmp

state-machine §3.7

ospfIfState tracks OSPF interface states: down(1), loopback(2), waiting(3), pointToPoint(4), designatedRouter(5), backupDesignatedRouter(6), otherDesignatedRouter(7). Transitions are driven by interface events such as interface up/down, DR election completion, and neighbor discovery.

routing

state-machine §3.10

ospfNbrState tracks the OSPF neighbor relationship state machine with eight states: down(1), attempt(2), init(3), twoWay(4), exchangeStart(5), exchange(6), loading(7), full(8). Transitions are driven by Hello reception, database exchange events, and link failures.

routing