Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4750

OSPF Version 2 Management Information Base

Pages: 121
Proposed Standard
Errata
Obsoletes:  1850
Part 5 of 5 – Pages 94 to 121
First   Prev   None

Top   ToC   RFC4750 - Page 94   prevText

4. OSPF Trap Overview

4.1. Introduction

OSPF is an event-driven routing protocol, where an event can be a change in an OSPF interface's link-level status, the expiration of an OSPF timer, or the reception of an OSPF protocol packet. Many of the actions that OSPF takes as a result of these events will result in a change of the routing topology. As routing topologies become large and complex, it is often difficult to locate the source of a topology change or unpredicted routing path by polling a large number or routers. Because of the difficulty of polling a large number of devices, a more prudent approach is for devices to notify a network manager of potentially critical OSPF events using SNMP traps. This section defines a set of traps, objects, and mechanisms to enhance the ability to manage IP internetworks that use OSPF as their Interior Gateway Protocol (IGP). It is an optional but very useful extension to the OSPF MIB.
Top   ToC   RFC4750 - Page 95

4.2. Approach

The mechanism for sending traps is straightforward. When an exception event occurs, the application notifies the local agent, who sends a trap to the appropriate SNMP management stations. The message includes the trap type and may include a list of trap- specific variables. Section 5 gives the trap definitions, which includes the variable lists. The Router ID of the originator of the trap is included in the variable list so that the network manager may easily determine the source of the trap. To limit the frequency of OSPF traps, the following additional mechanisms are suggested.

4.3. Ignoring Initial Activity

The majority of critical events occur when OSPF is enabled on a router, at which time the designated router is elected and neighbor adjacencies are formed. During this initial period, a potential flood of traps is unnecessary since the events are expected. To avoid unnecessary traps, a router should not originate expected OSPF interface-related traps until two of that interface's dead timer intervals have elapsed. The expected OSPF interface traps are ospfIfStateChange, ospfVirtIfStateChange, ospfNbrStateChange, ospfVirtNbrStateChange, ospfTxRetransmit, and ospfVirtIfTxRetransmit. Additionally, ospfMaxAgeLsa and ospfOriginateLsa traps should not be originated until two dead timer intervals have elapsed where the dead timer interval used should be the dead timer with the smallest value.

4.4. Throttling Traps

The mechanism for throttling the traps is similar to the mechanism explained in RFC 1224 [RFC1224]. The basic premise of the throttling mechanism is that of a sliding window, defined in seconds and an upper bound on the number of traps that may be generated within this window. Note that unlike RFC 1224, traps are not sent to inform the network manager that the throttling mechanism has kicked in. A single window should be used to throttle all OSPF trap types except for the ospfLsdbOverflow and the ospfLsdbApproachingOverflow traps, which should not be throttled. For example, with a window time of 3, an upper bound of 3, and events to cause trap types 1, 3, 5, and 7 (4 traps within a 3-second period), the type-7 (the 4th) trap should not be generated. Appropriate values are 7 traps with a window time of 10 seconds.
Top   ToC   RFC4750 - Page 96

4.5. One Trap Per OSPF Event

Several of the traps defined in section 5 are generated as the result of finding an unusual condition while parsing an OSPF packet or a processing a timer event. There may be more than one unusual condition detected while handling the event. For example, a link state update packet may contain several retransmitted link state advertisements (LSAs), or a retransmitted database description packet may contain several database description entries. To limit the number of traps and variables, OSPF should generate at most one trap per OSPF event. Only the variables associated with the first unusual condition should be included with the trap. Similarly, if more than one type of unusual condition is encountered while parsing the packet, only the first event will generate a trap.

4.6. Polling Event Counters

Many of the tables in the OSPF MIB contain generalized event counters. By enabling the traps defined in this document, a network manager can obtain more specific information about these events. A network manager may want to poll these event counters and enable specific OSPF traps when a particular counter starts increasing abnormally. The following table shows the relationship between the event counters defined in the OSPF MIB and the trap types. Counter32 Trap Type ----------------------- ------------------------ ospfOriginateNewLsas ospfOriginateLsa ospfIfEvents ospfIfStateChange ospfConfigError ospfIfAuthFailure ospfRxBadPacket ospfTxRetransmit ospfVirtIfEvents ospfVirtIfStateChange ospfVirtIfConfigError ospfVirtIfAuthFailure ospfVirtIfRxBadPacket ospfVirtIfTxRetransmit ospfNbrEvents ospfNbrStateChange ospfVirtNbrEvents ospfVirtNbrStateChange ospfExternLSACount ospfLsdbApproachingOverflow ospfExternLSACount ospfLsdbOverflow
Top   ToC   RFC4750 - Page 97

4.7. Translating Notification Parameters

The definition of the OSPF notifications pre-dates the RFC 2578 [RFC2578] requirement of having a zero value for the penultimate sub-identifier for translating SNMPv2/SNMPv3 trap parameters to SNMPv1 trap parameters. RFC 3584 [RFC3584], section 3, defines the translation rules that can be implemented by intermediate proxy- agents or multi-lingual agents to convert SNMPv2/SNMPv3 notifications to SNMPv1 notifications and vice versa. The conversion is not reversible, that is, a conversion to one SNMP version and then back again will result in an incorrectly formatted version of the notification. According to the rules specified in RFC 3584, section 3.1, translation of OSPF notifications from SNMPv1 to SNMPv2/SNMPv3 would result in the SNMPv2/SNMPv3 snmpTrapOID being the concatenation of the SNMPv1 'enterprise' parameter and two additional sub-identifiers, '0' and the SNMPv1 'specific-trap' parameter. According to the rules specified in RFC 3584, section 3.2, translation of OSPF notifications from SNMPv2/SNMPv3 to SNMPv1, as the notifications are defined in this MIB, would result in the SNMPv1 'enterprise' parameter being set to the SNMPv2/SNMPv3 snmpTrapOID parameter value with the last sub-identifier removed and the 'specific-trap' parameter being set to the last sub-identifier of the SNMPv2/SNMPv3 snmpTrapOID parameter. Note that a notification originated from an SNMPv1 agent will not be converted into the same notification that would be originated from a native SNMPv2/SNMPv3 agent.

4.8. Historical Artifacts

The MIB modules that are updated by this document were originally written in SMIv1 for SNMPv1 when only traps were used. Since this version of the MIB module is written in SMIv2, it should be understood that all types of notifications, trap and inform PDUs, may be used by native SNMPv2 and SNMPv3 agents, although only traps are mentioned. Also, for backwards compatibility, the OSPF Trap module remains rooted at {ospf 16}.
Top   ToC   RFC4750 - Page 98

5. OSPF Trap Definitions

OSPF-TRAP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF ospfRouterId, ospfIfIpAddress, ospfAddressLessIf, ospfIfState, ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState, ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrState, ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrState, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, ospfLsdbAreaId, ospfExtLsdbLimit, ospf, ospfAreaId, ospfAreaNssaTranslatorState, ospfRestartStatus, ospfRestartInterval, ospfRestartExitReason, ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, ospfNbrRestartHelperExitReason, ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, ospfVirtNbrRestartHelperExitReason FROM OSPF-MIB; ospfTrap MODULE-IDENTITY LAST-UPDATED "200611100000Z" -- November 10, 2006 00:00:00 EST ORGANIZATION "IETF OSPF Working Group" CONTACT-INFO "WG E-Mail: ospf@ietf.org WG Chairs: acee@cisco.com rohit@gmail.com Editors: Dan Joyal Nortel 600 Technology Park Drive Billerica, MA 01821 djoyal@nortel.com Piotr Galecki Airvana 19 Alpha Road Chelmsford, MA 01824 pgalecki@airvana.com Spencer Giacalone CSFB Eleven Madison Ave New York, NY 10010-3629
Top   ToC   RFC4750 - Page 99
                      spencer.giacalone@gmail.com"

          DESCRIPTION
             "The MIB module to describe traps for the OSPF
             Version 2 Protocol.

             Copyright (C) The IETF Trust (2006).
             This version of this MIB module is part of
             RFC 4750;  see the RFC itself for full legal
             notices."

          REVISION "200611100000Z" -- November 10, 2006 00:00:00 EST
          DESCRIPTION
             "Updated for latest changes to OSPFv2:
              -added graceful restart related traps
              -added new config error types
              -added ospfNssaTranslatorStatusChange trap.
              See Appendix B of RFC 4750 for more details.

             This version published as part of RFC 4750"

          REVISION "199501201225Z" -- Fri Jan 20 12:25:50 PST 1995
          DESCRIPTION
             "The initial SMIv2 revision of this MIB module, published
             in RFC 1850."

          ::= { ospf 16 }

   --  Trap Support Objects

   --  The following are support objects for the OSPF traps.

     ospfTrapControl OBJECT IDENTIFIER ::= { ospfTrap 1 }
     ospfTraps OBJECT IDENTIFIER ::= { ospfTrap 2 }

     ospfSetTrap OBJECT-TYPE
          SYNTAX       OCTET STRING (SIZE(4))
          MAX-ACCESS   read-write
          STATUS       current
          DESCRIPTION
             "A 4-octet string serving as a bit map for
             the trap events defined by the OSPF traps.  This
             object is used to enable and disable specific
             OSPF traps where a 1 in the bit field
             represents enabled.  The right-most bit (least
             significant) represents trap 0.

             This object is persistent and when written
Top   ToC   RFC4750 - Page 100
             the entity SHOULD save the change to non-volatile
             storage."
           ::= { ospfTrapControl 1 }

     ospfConfigErrorType OBJECT-TYPE
          SYNTAX       INTEGER {
                          badVersion (1),
                          areaMismatch (2),
                          unknownNbmaNbr (3), -- Router is DR eligible
                          unknownVirtualNbr (4),
                          authTypeMismatch(5),
                          authFailure (6),
                          netMaskMismatch (7),
                          helloIntervalMismatch (8),
                          deadIntervalMismatch (9),
                          optionMismatch (10),
                          mtuMismatch (11),
                          duplicateRouterId (12),
                          noError (13) }
          MAX-ACCESS   read-only
          STATUS   current
          DESCRIPTION
             "Potential types of configuration conflicts.
             Used by the ospfConfigError and
             ospfConfigVirtError traps.  When the last value
             of a trap using this object is needed, but no
             traps of that type have been sent, this value
             pertaining to this object should be returned as
             noError."
          ::= { ospfTrapControl 2 }

     ospfPacketType OBJECT-TYPE
          SYNTAX       INTEGER {
                          hello (1),
                          dbDescript (2),
                          lsReq (3),
                          lsUpdate (4),
                          lsAck (5),
                          nullPacket (6) }
          MAX-ACCESS   read-only
          STATUS       current
          DESCRIPTION
             "OSPF packet types.  When the last value of a trap
             using this object is needed, but no traps of
             that type have been sent, this value pertaining
             to this object should be returned as nullPacket."
          ::= { ospfTrapControl 3 }
Top   ToC   RFC4750 - Page 101
     ospfPacketSrc OBJECT-TYPE
          SYNTAX       IpAddress
          MAX-ACCESS   read-only
          STATUS       current
          DESCRIPTION
             "The IP address of an inbound packet that cannot
             be identified by a neighbor instance.  When
             the last value of a trap using this object is
             needed, but no traps of that type have been sent,
             this value pertaining to this object should
             be returned as 0.0.0.0."
          ::= { ospfTrapControl 4 }

   --  Traps

     ospfVirtIfStateChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfVirtIfAreaId,
             ospfVirtIfNeighbor,
             ospfVirtIfState  -- The new state
             }
          STATUS       current
          DESCRIPTION
             "An ospfVirtIfStateChange trap signifies that there
             has been a change in the state of an OSPF virtual
             interface.

             This trap should be generated when the interface
             state regresses (e.g., goes from Point-to-Point to Down)
             or progresses to a terminal state
             (i.e., Point-to-Point)."
          ::= { ospfTraps 1 }

     ospfNbrStateChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfNbrIpAddr,
             ospfNbrAddressLessIndex,
             ospfNbrRtrId,
             ospfNbrState  -- The new state
             }
          STATUS       current
          DESCRIPTION
             "An ospfNbrStateChange trap signifies that
             there has been a change in the state of a
             non-virtual OSPF neighbor.  This trap should be
             generated when the neighbor state regresses
             (e.g., goes from Attempt or Full to 1-Way or
             Down) or progresses to a terminal state (e.g.,
Top   ToC   RFC4750 - Page 102
             2-Way or Full).  When an neighbor transitions
             from or to Full on non-broadcast multi-access
             and broadcast networks, the trap should be
             generated by the designated router.  A designated
             router transitioning to Down will be noted by
             ospfIfStateChange."
          ::= { ospfTraps 2 }

     ospfVirtNbrStateChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfVirtNbrArea,
             ospfVirtNbrRtrId,
             ospfVirtNbrState  -- The new state
             }
          STATUS       current
          DESCRIPTION
             "An ospfVirtNbrStateChange trap signifies that there
             has been a change in the state of an OSPF virtual
             neighbor.  This trap should be generated
             when the neighbor state regresses (e.g., goes
             from Attempt or Full to 1-Way or Down) or
             progresses to a terminal state (e.g., Full)."
          ::= { ospfTraps 3 }

     ospfIfConfigError NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfPacketSrc,  -- The source IP address
             ospfConfigErrorType, -- Type of error
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfIfConfigError trap signifies that a
             packet has been received on a non-virtual
             interface from a router whose configuration
             parameters conflict with this router's
             configuration parameters.  Note that the event
             optionMismatch should cause a trap only if it
             prevents an adjacency from forming."
          ::= { ospfTraps 4 }

     ospfVirtIfConfigError NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfVirtIfAreaId,
             ospfVirtIfNeighbor,
             ospfConfigErrorType, -- Type of error
Top   ToC   RFC4750 - Page 103
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfVirtIfConfigError trap signifies that a
             packet has been received on a virtual interface
             from a router whose configuration parameters
             conflict with this router's configuration
             parameters.  Note that the event optionMismatch
             should cause a trap only if it prevents an
             adjacency from forming."
          ::= { ospfTraps 5 }

     ospfIfAuthFailure NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfPacketSrc,  -- The source IP address
             ospfConfigErrorType, -- authTypeMismatch or
                                  -- authFailure
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfIfAuthFailure trap signifies that a
             packet has been received on a non-virtual
             interface from a router whose authentication key
             or authentication type conflicts with this
             router's authentication key or authentication
             type."
          ::= { ospfTraps 6 }

     ospfVirtIfAuthFailure NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfVirtIfAreaId,
             ospfVirtIfNeighbor,
             ospfConfigErrorType, -- authTypeMismatch or
                                  -- authFailure
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfVirtIfAuthFailure trap signifies that a
             packet has been received on a virtual interface
             from a router whose authentication key or
             authentication type conflicts with this router's
             authentication key or authentication type."
Top   ToC   RFC4750 - Page 104
          ::= { ospfTraps 7 }

     ospfIfRxBadPacket NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfPacketSrc,  -- The source IP address
             ospfPacketType
             }
          STATUS       current
          DESCRIPTION
             "An ospfIfRxBadPacket trap signifies that an
             OSPF packet has been received on a non-virtual
             interface that cannot be parsed."
          ::= { ospfTraps 8 }

     ospfVirtIfRxBadPacket NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
            ospfVirtIfAreaId,
            ospfVirtIfNeighbor,
            ospfPacketType
            }
          STATUS       current
          DESCRIPTION
             "An ospfVirtIfRxBadPacket trap signifies that an OSPF
             packet has been received on a virtual interface
             that cannot be parsed."
          ::= { ospfTraps 9 }

     ospfTxRetransmit NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfNbrRtrId, -- Destination
             ospfPacketType,
             ospfLsdbType,
             ospfLsdbLsid,
             ospfLsdbRouterId
             }
           STATUS       current
           DESCRIPTION
              "An ospfTxRetransmit trap signifies than an
              OSPF packet has been retransmitted on a
              non-virtual interface.  All packets that may be
              retransmitted are associated with an LSDB entry.
              The LS type, LS ID, and Router ID are used to
              identify the LSDB entry."
           ::= { ospfTraps 10 }
Top   ToC   RFC4750 - Page 105
     ospfVirtIfTxRetransmit NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfVirtIfAreaId,
             ospfVirtIfNeighbor,
             ospfPacketType,
             ospfLsdbType,
             ospfLsdbLsid,
             ospfLsdbRouterId
             }
          STATUS       current
          DESCRIPTION
             "An ospfVirtIfTxRetransmit trap signifies than an
             OSPF packet has been retransmitted on a virtual
             interface.  All packets that may be retransmitted
             are associated with an LSDB entry.  The LS
             type, LS ID, and Router ID are used to identify
             the LSDB entry."
          ::= { ospfTraps 11 }

     ospfOriginateLsa NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfLsdbAreaId,  -- 0.0.0.0 for AS Externals
             ospfLsdbType,
             ospfLsdbLsid,
             ospfLsdbRouterId
             }
          STATUS       current
          DESCRIPTION
             "An ospfOriginateLsa trap signifies that a new
             LSA has been originated by this router.  This
             trap should not be invoked for simple refreshes
             of LSAs (which happens every 30 minutes), but
             instead will only be invoked when an LSA is
             (re)originated due to a topology change.
             Additionally, this trap does not include LSAs that
             are being flushed because they have reached
             MaxAge."
          ::= { ospfTraps 12 }

     ospfMaxAgeLsa NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfLsdbAreaId,  -- 0.0.0.0 for AS Externals
             ospfLsdbType,
             ospfLsdbLsid,
             ospfLsdbRouterId
             }
          STATUS       current
          DESCRIPTION
Top   ToC   RFC4750 - Page 106
             "An ospfMaxAgeLsa trap signifies that one of
             the LSAs in the router's link state database has
             aged to MaxAge."
          ::= { ospfTraps 13 }

     ospfLsdbOverflow NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfExtLsdbLimit
             }

          STATUS       current
          DESCRIPTION
             "An ospfLsdbOverflow trap signifies that the
             number of LSAs in the router's link state
             database has exceeded ospfExtLsdbLimit."
          ::= { ospfTraps 14 }

     ospfLsdbApproachingOverflow NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfExtLsdbLimit
             }
          STATUS       current
          DESCRIPTION
             "An ospfLsdbApproachingOverflow trap signifies
             that the number of LSAs in the router's
             link state database has exceeded ninety percent of
             ospfExtLsdbLimit."
          ::= { ospfTraps 15 }

     ospfIfStateChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
             ospfIfIpAddress,
             ospfAddressLessIf,
             ospfIfState   -- The new state
             }
          STATUS       current
          DESCRIPTION
             "An ospfIfStateChange trap signifies that there
             has been a change in the state of a non-virtual
             OSPF interface.  This trap should be generated
             when the interface state regresses (e.g., goes
             from Dr to Down) or progresses to a terminal
             state (i.e., Point-to-Point, DR Other, Dr, or
             Backup)."
          ::= { ospfTraps 16 }

     ospfNssaTranslatorStatusChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
Top   ToC   RFC4750 - Page 107
             ospfAreaId,
             ospfAreaNssaTranslatorState -- The current translation
                                         -- status
             }
          STATUS       current
          DESCRIPTION
             "An ospfNssaTranslatorStatusChange trap indicates that
             there has been a change in the router's ability to
             translate OSPF type-7 LSAs into OSPF type-5 LSAs.
             This trap should be generated when the translator
             status transitions from or to any defined status on
             a per-area basis."
          ::= { ospfTraps 17 }

     ospfRestartStatusChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
                    ospfRestartStatus,
                    ospfRestartInterval,
                    ospfRestartExitReason
                  }
          STATUS       current
          DESCRIPTION
             "An ospfRestartStatusChange trap signifies that
             there has been a change in the graceful restart
             state for the router.  This trap should be
             generated when the router restart status
             changes."
          ::= { ospfTraps 18 }

     ospfNbrRestartHelperStatusChange NOTIFICATION-TYPE
          OBJECTS { ospfRouterId, -- The originator of the trap
                    ospfNbrIpAddr,
                    ospfNbrAddressLessIndex,
                    ospfNbrRtrId,
                    ospfNbrRestartHelperStatus,
                    ospfNbrRestartHelperAge,
                    ospfNbrRestartHelperExitReason
                  }
          STATUS       current
          DESCRIPTION
             "An ospfNbrRestartHelperStatusChange trap signifies that
             there has been a change in the graceful restart
             helper state for the neighbor.  This trap should be
             generated when the neighbor restart helper status
             transitions for a neighbor."
          ::= { ospfTraps 19 }

     ospfVirtNbrRestartHelperStatusChange NOTIFICATION-TYPE
Top   ToC   RFC4750 - Page 108
          OBJECTS { ospfRouterId, -- The originator of the trap
                    ospfVirtNbrArea,
                    ospfVirtNbrRtrId,
                    ospfVirtNbrRestartHelperStatus,
                    ospfVirtNbrRestartHelperAge,
                    ospfVirtNbrRestartHelperExitReason
                  }
          STATUS       current
          DESCRIPTION
             "An ospfVirtNbrRestartHelperStatusChange trap signifies
             that there has been a change in the graceful restart
             helper state for the virtual neighbor.  This trap should
             be generated when the virtual neighbor restart helper
             status transitions for a virtual neighbor."
          ::= { ospfTraps 20 }

   --  conformance information

   ospfTrapConformance OBJECT IDENTIFIER ::= { ospfTrap 3 }
   ospfTrapGroups      OBJECT IDENTIFIER ::= { ospfTrapConformance 1 }
   ospfTrapCompliances OBJECT IDENTIFIER ::= { ospfTrapConformance 2 }

   --  compliance statements

   ospfTrapCompliance MODULE-COMPLIANCE
        STATUS       obsolete
        DESCRIPTION
           "The compliance statement."
        MODULE       -- this module
        MANDATORY-GROUPS { ospfTrapControlGroup }

        GROUP       ospfTrapControlGroup
        DESCRIPTION
           "This group is optional but recommended for all
           OSPF systems."
        ::= { ospfTrapCompliances 1 }

   ospfTrapCompliance2 MODULE-COMPLIANCE
        STATUS       current
        DESCRIPTION
           "The compliance statement."
        MODULE       -- this module
        MANDATORY-GROUPS { ospfTrapControlGroup, ospfTrapEventGroup }
        OBJECT       ospfConfigErrorType
        MIN-ACCESS   accessible-for-notify
        DESCRIPTION
           "This object is only required to be supplied within
           notifications."
Top   ToC   RFC4750 - Page 109
        OBJECT       ospfPacketType
        MIN-ACCESS   accessible-for-notify
        DESCRIPTION
           "This object is only required to be supplied within
           notifications."
        OBJECT       ospfPacketSrc
        MIN-ACCESS   accessible-for-notify
        DESCRIPTION
           "This object is only required to be supplied within
           notifications."
        ::= { ospfTrapCompliances 2 }

   --  units of conformance

     ospfTrapControlGroup    OBJECT-GROUP
          OBJECTS { ospfSetTrap,
                    ospfConfigErrorType,
                    ospfPacketType,
                    ospfPacketSrc }
          STATUS       current
          DESCRIPTION
             "These objects are required to control traps
             from OSPF systems."
          ::= { ospfTrapGroups 1 }

     ospfTrapEventGroup       NOTIFICATION-GROUP
          NOTIFICATIONS {
             ospfVirtIfStateChange,
             ospfNbrStateChange,
             ospfVirtNbrStateChange,
             ospfIfConfigError,
             ospfVirtIfConfigError,
             ospfIfAuthFailure,
             ospfVirtIfAuthFailure,
             ospfIfRxBadPacket,
             ospfVirtIfRxBadPacket,
             ospfTxRetransmit,
             ospfVirtIfTxRetransmit,
             ospfOriginateLsa,
             ospfMaxAgeLsa,
             ospfLsdbOverflow,
             ospfLsdbApproachingOverflow,
             ospfIfStateChange,
             ospfNssaTranslatorStatusChange,
             ospfRestartStatusChange,
             ospfNbrRestartHelperStatusChange,
             ospfVirtNbrRestartHelperStatusChange
             }
Top   ToC   RFC4750 - Page 110
          STATUS        current
          DESCRIPTION
             "A grouping of OSPF trap events, as specified
             in NOTIFICATION-TYPE constructs."
          ::= { ospfTrapGroups 2 }

   END

6. Security Considerations

There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. It is recommended that attention be specifically given to implementing the MAX-ACCESS clause in a number of objects, including ospfIfAuthKey, ospfIfAuthType, ospfVirtIfAuthKey, and ospfVirtIfAuthType in scenarios that DO NOT use SNMPv3 strong security (i.e., authentication and encryption). Extreme caution must be used to minimize the risk of cascading security vulnerabilities when SNMPv3 strong security is not used. When SNMPv3 strong security is not used, these objects should have access of read-only, not read-create. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View- based Access Control Model RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
Top   ToC   RFC4750 - Page 111

7. IANA Considerations

The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- ospf { mib-2 14 }

8. Acknowledgements

This document was produced by the OSPF Working Group and is based on the MIB for OSPF version 2 by Rob Coltun and Fred Baker [RFC1850]. The editors would like to acknowledge John Moy, Rob Coltun, Randall Atkinson, David T. Perkins, Ken Chapman, Brian Field, Acee Lindem, Vishwas Manral, Roy Jose, Don Goodspeed, Vivek Dubey, Keith McCloghrie, Bill Fenner, and Dan Romascanu for their constructive comments.

9. References

9.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

9.2 Informative References

[RFC1224] Steinberg, L., "Techniques for managing asynchronously generated alerts", RFC 1224, May 1991. [RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994. [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
Top   ToC   RFC4750 - Page 112
   [RFC1793]  Moy, J., "Extending OSPF to Support Demand Circuits", RFC
              1793, April 1995.

   [RFC1850]  Baker, F.  and R.  Coltun, "OSPF Version 2 Management
              Information Base", RFC 1850, November 1995.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2370]  Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
              1998.

   [RFC3101]  Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
              RFC 3101, January 2003.

   [RFC3410]  Case, J., Mundy, R., Partain, D., and B. Stewart,
              "Introduction and Applicability Statements for Internet-
              Standard Management Framework", RFC 3410, December 2002.

   [RFC3414]  Blumenthal, U.  and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3415, December
              2002.

   [RFC3584]  Frye, R., Levi, D., Routhier, S., and B. Wijnen,
              "Coexistence between Version 1, Version 2, and Version 3
              of the Internet-standard Network Management Framework",
              BCP 74, RFC 3584, August 2003.

   [RFC3623]  Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
              Restart", RFC 3623, November 2003.

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC1583]  Moy, J., "OSPF Version 2", RFC 1583, March 1994.
Top   ToC   RFC4750 - Page 113

Appendix A. TOS Support

For backward compatibility with previous versions of the OSPF MIB specification, TOS-specific information has been retained in this document, though the TOS routing option has been deleted from OSPF [RFC2328].

Appendix B. Changes from RFC 1850

This section documents the differences between this memo and RFC 1850.

Appendix B.1. General Group Changes

Added object ospfRFC1583Compatibility to indicate support with "RFC 1583 Compatibility" [RFC1583]. This object has DEFVAL of "enabled". Added object ospfReferenceBandwidth to allow configuration of a reference bandwidth for calculation of default interface metrics. Added objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, ospfRestartStrictLsaChecking, and ospfRestartExitReason to support graceful restart. Added objects ospfStubRouterSupport and ospfStubRouteAdvertisement to support stub routers. Added object ospfDiscontinuityTime in order for a management entity to detect counter discontinuity events.

Appendix B.2. OSPF NSSA Enhancement Support

Added new objects to OspfAreaTable including the following: -ospfAreaNssaTranslatorRole to indicate the configured NSSA translation role. -ospfAreaNssaTranslatorState to indicate the current NSSA translation role. -ospfAreaNssaTranslatorStabilityInterval to indicate time to continue to perform at current translation status. -ospfAreaNssaTranslatorEvents to indicate the number of times OSPF translation state has changed. Added new object ospfAreaAggregateExtRouteTag to ospfAreaAggregateTable.
Top   ToC   RFC4750 - Page 114
   Added new object ospfNssaTranslatorStatusChange to ospfTraps in
   OSPF-TRAP-MIB DEFINITIONS.

   Added ospfAreaId to IMPORTS in OSPF-TRAP-MIB DEFINITIONS to support
   ospfNssaTranslatorStatusChange.

   Added ospfAreaExtNssaTranslatorStatus to IMPORTS in OSPF-TRAP-MIB
   DEFINITIONS to support ospfNssaTranslatorStatusChange.

   Modified the DESCRIPTION clause of the ospfAreaSummary object in the
   ospfAreaTable to indicate support for NSSA.

   Modified the DESCRIPTION clause of the ospfImportAsExtern object in
   the ospfAreaTable for clarity.

Appendix B.3. Opaque LSA Support

Added object ospfOpaqueLsaSupport to ospfGeneralGroup to indicate support of OSPF Opaque LSAs. Created ospfLocalLsdbTable, for link-local (type-9) LSA support. This table is indexed by the following: -ospflocalLsdbIpAddress -ospfLocalLsdbAddressLessIf -ospfLocalLsdbType -ospfLocalLsdbLsid -ospfLocalLsdbRouterId ospfLocalLsdbTable contains the following (columnar) objects: -ospfLocalLsdbSequence, to indicate LSA instance -ospfLocalLsdbAge -ospfLocalLsdbChecksum -ospfLocalLsdbAdvertisement, containing the entire LSA Created ospfVirLocalLsdbTable, for link-local (type-9) LSA support on virtual links. This table is indexed by the following: -ospfVirtLocalLsdbTransitArea
Top   ToC   RFC4750 - Page 115
   -ospfVirtLocalLsdbNeighbor, to indicate the router ID of the virtual
    neighbor

   -ospfVirLocalLsdbType

   -ospfVirLocalLsdbLsid

   -ospfVirLocalLsdbRouterId

   ospfVirLocalLsdbTable contains the following (columnar) objects:

   -ospfVirLocalLsdbSequence, to indicate LSA instance

   -ospfVirLocalLsdbAge

   -ospfVirLocalLsdbChecksum

   -ospfVirLocalLsdbAdvertisement, containing the entire LSA

   Added objects to ospfIfTable to support link-local (type-9) LSAs,
   including the following:

   -ospfIfLsaCount

   -ospfIfLsaCksumSum, to indicate the sum of the type-9 link state
    advertisement checksums on this interface

   Added objects to ospfVirIfTable, to support link-local (type-9) LSAs
   on virtual links, including the following:

   -ospfVirIfLsaCount

   -ospfVirIfLsaCksumSum, to indicate the sum of the type-9 link state
    advertisement checksums on this link

   To support area scope (type-10) LSAs, the enumeration areaOpaqueLink
   (10) was added to ospfLsdbType in the ospfLsdbTable.

   Created ospfAsLsdbTable, for AS-scope LSA support.  This table is
   indexed by the following:

   -ospfAsLsdbType

   -ospfAsLsdbLsid

   -ospfAsLsdbRouterId

   ospfAsLsdbTable contains the following (columnar) objects:
Top   ToC   RFC4750 - Page 116
   -ospfAsLsdbSequence, to indicate LSA instance

   -ospfAsLsdbAge

   -ospfAsLsdbChecksum

   -ospfAsLsdbAdvertisement, containing the entire LSA

Appendix B.4. Graceful Restart Support

Added objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, ospfRestartStrictLsaChecking, and ospfRestartExitReason to general group. Added objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and ospfNbrRestartHelperExitReason to OspfNbrTable. Added objects ospfVirtNbrRestartHelperStatus, ospfVirtNbrRestartHelperAge, and ospfVirtNbrRestartHelperExitReason to OspfVirtNbrTable.

Appendix B.5. OSPF Compliances

New compliance statements were added for new and for obsoleted conformance groups. These statements include the following: -ospfCompliance2 -ospfComplianceObsolete New conformance groups were created to support new objects added to the group. These groups include the following: -ospfBasicGroup2 -ospfAreaGroup2 -ospfIfGroup2 -ospfVirtIfGroup2 -ospfNbrGroup2 -ospfVirtNbrGroup2 -ospfAreaAggregateGroup2 Added completely new conformance groups, including the following:
Top   ToC   RFC4750 - Page 117
   -ospfLocalLsdbGroup, which specifies support for link-local (type-9)
    LSAs

   -ospfVirtLocalLsdbGroup, which specifies support for link-local
    (type-9) LSAs on virtual links

   -ospfObsoleteGroup, for obsolete objects and SMI compatibility

Appendix B.6. OSPF Authentication and Security

As there has been significant concern in the community regarding cascading security vulnerabilities, the following changes have been incorporated: -Modified the DESCRIPTION clause of ospfIfAuthKey due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfVirtIfAuthKey due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfIfAuthType due to security concerns and to increase clarity -Modified the DESCRIPTION clause of ospfVirtIfType due to security concerns and to increase clarity -Modified the OSPF MIB MODULE DESCRIPTION due to security concerns and to include a reference to the Security Considerations section in this document that will transcend compilation -Modified the Security Considerations section to provide detail

Appendix B.7. OSPF Trap MIB

Added ospfTrapEventGroup. Added importation of NOTIFICATION-GROUP. Changed the STATUS of the ospfTrapCompliance MODULE-COMPLIANCE construct to obsolete. Added ospfTrapCompliance2 MODULE-COMPLIANCE construct, which replaces ospfTrapCompliance. OspfTrapCompliance includes an updated MANDATORY-GROUPS clause and new MIN-ACCESS specifications. Added mtuMismatch enumeration to ospfConfigErrorType object in ospfTrapControl to imply MTU mismatch trap generation. in ospfIfConfigError.
Top   ToC   RFC4750 - Page 118
   Added noError enumeration to ospfConfigErrorType object for
   situations when traps are requested but none have been sent.  Updated
   the DESCRIPTION clause accordingly.

   Added nullPacket enumeration to ospfPacketType object for situations
   when traps are requested but none have been sent.  Updated the
   DESCRIPTION clause accordingly.

   Updated the DESCRIPTION clause of ospfPacketSrc for situations when
   traps are requested, but none have been sent.

   Added NOTIFICATION-TYPE for ospfRestartStatusChange.

   Added NOTIFICATION-TYPE for ospfNbrRestartHelperStatusChange.

   Added NOTIFICATION-TYPE for ospfVirtNbrRestartHelperStatusChange.

Appendix B.8. Miscellaneous

Various sections have been moved or modified for clarity. Most of these changes are semantic in nature and include, but are not limited to the following: -The OSPF overview section's format was revised. Unneeded information was removed. Removed information includes OSPF TOS default values. -The trap overview section's format and working were revised. Unneeded information was removed. -Modified the DESCRIPTION clause of "Status" "TEXTUAL-CONVENTION" for clarity. -The Updates section was moved from the overview to its own section. -Updated "REFERENCE" clauses in all objects, as needed. -Modified the SEQUENCE of the OspfIfTable to reflect the true order of the objects in the table. -Modified the DESCRIPTION clause of all row management objects for clarity. Added ospfHostCfgAreaID to object to Host table with read-create access. Deprecated ospfHostAreaID.
Top   ToC   RFC4750 - Page 119
   Added importation of InterfaceIndexOrZero from IF-MIB.  This
   TEXTUAL-CONVENTION will replace the InterfaceIndex TEXTUAL-
   CONVENTION.

   Changed the SYNTAX clause of ospfNbrAddressLessIndex to use the
   semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as
   permitted by the SMI.

   Changed the STATUS clause of the TEXTUAL-CONVENTION InterfaceIndex to
   obsolete and modified the DESCRIPTION accordingly.

   Changed the SYNTAX clause of ospfAddressLessIf to use the
   semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as
   permitted by the SMI.

   Changed the SYNTAX clause of ospfIfMetricAddressLessIf to use the
   semantically identical InterfaceIndexOrZero TEXTUAL-CONVENTION, as
   permitted by the SMI.

   Changed importation of mib-2 from RFC1213-MIB to SNMPv2-SMI

   Added Intellectual Property Rights section.

   Updated REVISION DESCRIPTION clauses with description of major MIB
   modifications.

   Moved all relevant MIB comments to objects' DESCRIPTION clauses.

   Added reasoning for object deprecation.

   Added persistence information for read-write, read-create objects.

   Described conditions when columns can be modified in RowStatus
   managed rows as required by RFC 2579.

   Defined OspfAuthenticationType TC and modified authentication type
   objects to use the new type.

   Made index objects of new tables not accessible.

   Added the UNITS clause to several objects.

   Added ospfIfDesignatedRouterId and ospfIfBackupDesignatedRouterId to
   the OspfIfEntry.

   Added the area LSA counter table.

   Added IANA Considerations section.
Top   ToC   RFC4750 - Page 120

Authors' Addresses

Dan Joyal (Editor) Nortel, Inc. 600 Technology Park Drive Billerica, MA 01821 USA EMail: djoyal@nortel.com Piotr Galecki (Editor) Airvana, Inc. 19 Alpha Road Chelmsford, MA 01824 USA EMail: pgalecki@airvana.com Spencer Giacalone (Editor) CSFB Eleven Madison Ave New York, NY 10010-3629 USA EMail: spencer.giacalone@gmail.com Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara, California 93117 USA EMail: fred@cisco.com Rob Coltun Touch Acoustra 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA EMail: undisclosed
Top   ToC   RFC4750 - Page 121
Full Copyright Statement

   Copyright (C) The IETF Trust (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
   IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
   PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.