RFC 4750
OSPF Version 2 Management Information Base
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.
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.
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
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}.
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
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
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 }
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.,
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
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."
::= { 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 }
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
"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
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
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."
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
}
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.
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.
[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.
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.
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
-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:
-ospfAsLsdbSequence, to indicate LSA instance -ospfAsLsdbAge -ospfAsLsdbChecksum -ospfAsLsdbAdvertisement, containing the entire LSAAppendix 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:
-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.
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.
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.
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
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.