tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4750

 
 
 

OSPF Version 2 Management Information Base

Part 5 of 5, p. 94 to 121
Prev RFC Part

 


prevText      Top      Up      ToC       Page 94 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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.