OSPF-TRAP-MIB

All MIBs › OSPF-TRAP-MIB

Organization: IETF OSPF Working Group

Last Updated: 2006-11-10

Category: Routing Protocols

Description: Defines SNMP trap notifications for OSPF routing protocol events, enabling monitoring of OSPF state changes, neighbor transitions, and error conditions.

IPNetwork Monitor uses several OIDs from this MIB in network discovery and polling the applicable devices. Start monitoring OSPF-TRAP-MIB with a free 30-day trial of IPNetwork Monitor.

What Is OSPF-TRAP-MIB?

OSPF-TRAP-MIB is a vendor-neutral IETF standards-track module (RFC 4750) that defines SNMP trap notifications for the OSPF version 2 routing protocol, complementing the base OSPF-MIB's polled objects with asynchronous event reporting. It covers fault and state-change events such as neighbor state transitions, interface state changes, virtual-interface issues, and various OSPF protocol error conditions (e.g., configuration errors, retransmissions, bad packets). Its role in monitoring is squarely about software/protocol fault detection—alerting operators in near real time when an OSPF neighbor goes down, an interface changes state, or a routing/configuration error occurs, rather than exposing physical hardware counters. It directly depends on the base OSPF-MIB (RFC 4750 companion) for the object definitions referenced by its trap varbinds, and on the standard SNMP notification framework (SNMPv2-CONF/NOTIFICATION-TYPE); compiling the OSPF-TRAP-MIB MIB alongside the base OSPF-MIB is a prerequisite for any management station that wants to receive these standardized OSPF trap notifications. It is deployed on OSPF-speaking routers in enterprise and service-provider IP networks where administrators want proactive alerts on routing protocol instability rather than relying solely on polling.

IPNetwork Monitor allows you to monitor SNMP objects defined in OSPF-TRAP-MIB. Use the built-in SNMP Monitoring Browser to explore available variables, view their current values and descriptions, and select the objects you want to monitor. You can then create SNMP monitors, configure thresholds, and receive alerts when monitored values change.

Supported Devices

vendor-neutral, standards-based MIB, not tied to a specific manufacturer
OSPF-speaking routers and Layer 3 switches

Monitoring Examples

The sample_objects for this MIB (ospfTrapConformance, ospfTrapGroups, ospfTrapCompliances) are conformance/compliance statement objects, so this batch doesn't evidence specific trap varbind names from real data. In actual deployment, an administrator would configure a trap receiver to catch OSPF neighbor state-change and interface state-change notifications defined by this MIB (per RFC 4750) to be alerted the moment an adjacency drops or an interface flaps, rather than waiting for the next polling cycle. Given the limited sample, specific trap object names beyond the conformance groups can't be confirmed from this data.

What Can Be Monitored

OSPF neighbor state-change events
OSPF interface state-change events
OSPF configuration/protocol error events

Imported Objects

From OSPF-MIB

ospf	MODULE-IDENTITY
ospfAddressLessIf
ospfAreaId	OBJECT-TYPE
ospfAreaNssaTranslatorState	OBJECT-TYPE
ospfExtLsdbLimit	OBJECT-TYPE
ospfIfIpAddress
ospfIfState
ospfLsdbAreaId
ospfLsdbLsid
ospfLsdbRouterId
ospfLsdbType
ospfNbrAddressLessIndex
ospfNbrIpAddr
ospfNbrRestartHelperAge
ospfNbrRestartHelperExitReason
ospfNbrRestartHelperStatus
ospfNbrRtrId
ospfNbrState
ospfRestartExitReason
ospfRestartInterval
ospfRestartStatus
ospfRouterId	OBJECT-TYPE
ospfVirtIfAreaId
ospfVirtIfNeighbor
ospfVirtIfState
ospfVirtNbrArea
ospfVirtNbrRestartHelperAge
ospfVirtNbrRestartHelperExitReason
ospfVirtNbrRestartHelperStatus
ospfVirtNbrRtrId
ospfVirtNbrState

From SNMPv2-CONF

MODULE-COMPLIANCE
NOTIFICATION-GROUP
OBJECT-GROUP

From SNMPv2-SMI

IpAddress
MODULE-IDENTITY
NOTIFICATION-TYPE
OBJECT-TYPE

OIDs

OID symbolic	OID numeric	Type	Access	Description
INT ospfConfigErrorType	1.3.6.1.2.1.14.16.1.2	INTEGER	read-only	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.
NTF ospfIfAuthFailure	1.3.6.1.2.1.14.16.2.6			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.
NTF ospfIfConfigError	1.3.6.1.2.1.14.16.2.4			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.
NTF ospfIfRxBadPacket	1.3.6.1.2.1.14.16.2.8			An ospfIfRxBadPacket trap signifies that an OSPF packet has been received on a non-virtual interface that cannot be parsed.
NTF ospfIfStateChange	1.3.6.1.2.1.14.16.2.16			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).
NTF ospfLsdbApproachingOverflow	1.3.6.1.2.1.14.16.2.15			An ospfLsdbApproachingOverflow trap signifies that the number of LSAs in the router's link state database has exceeded ninety percent of ospfExtLsdbLimit.
NTF ospfLsdbOverflow	1.3.6.1.2.1.14.16.2.14			An ospfLsdbOverflow trap signifies that the number of LSAs in the router's link state database has exceeded ospfExtLsdbLimit.
NTF ospfMaxAgeLsa	1.3.6.1.2.1.14.16.2.13			An ospfMaxAgeLsa trap signifies that one of the LSAs in the router's link state database has aged to MaxAge.
NTF ospfNbrRestartHelperStatusChange	1.3.6.1.2.1.14.16.2.19			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.
NTF ospfNbrStateChange	1.3.6.1.2.1.14.16.2.2			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.
NTF ospfNssaTranslatorStatusChange	1.3.6.1.2.1.14.16.2.17			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.
NTF ospfOriginateLsa	1.3.6.1.2.1.14.16.2.12			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.
IP ospfPacketSrc	1.3.6.1.2.1.14.16.1.4	IpAddress	read-only	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.
INT ospfPacketType	1.3.6.1.2.1.14.16.1.3	INTEGER	read-only	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.
NTF ospfRestartStatusChange	1.3.6.1.2.1.14.16.2.18			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.
OCT ospfSetTrap	1.3.6.1.2.1.14.16.1.1	OCTET STRING	read-write	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.
ospfTrap	1.3.6.1.2.1.14.16			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.
ospfTrapCompliance	1.3.6.1.2.1.14.16.3.2.1			The compliance statement.
ospfTrapCompliance2	1.3.6.1.2.1.14.16.3.2.2			The compliance statement.
ospfTrapCompliances	1.3.6.1.2.1.14.16.3.2
ospfTrapConformance	1.3.6.1.2.1.14.16.3
ospfTrapControl	1.3.6.1.2.1.14.16.1
ospfTrapControlGroup	1.3.6.1.2.1.14.16.3.1.1			These objects are required to control traps from OSPF systems.
ospfTrapEventGroup	1.3.6.1.2.1.14.16.3.1.2			A grouping of OSPF trap events, as specified in NOTIFICATION-TYPE constructs.
ospfTrapGroups	1.3.6.1.2.1.14.16.3.1
ospfTraps	1.3.6.1.2.1.14.16.2
NTF ospfTxRetransmit	1.3.6.1.2.1.14.16.2.10			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.
NTF ospfVirtIfAuthFailure	1.3.6.1.2.1.14.16.2.7			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.
NTF ospfVirtIfConfigError	1.3.6.1.2.1.14.16.2.5			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.
NTF ospfVirtIfRxBadPacket	1.3.6.1.2.1.14.16.2.9			An ospfVirtIfRxBadPacket trap signifies that an OSPF packet has been received on a virtual interface that cannot be parsed.
NTF ospfVirtIfStateChange	1.3.6.1.2.1.14.16.2.1			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).
NTF ospfVirtIfTxRetransmit	1.3.6.1.2.1.14.16.2.11			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.
NTF ospfVirtNbrRestartHelperStatusChange	1.3.6.1.2.1.14.16.2.20			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.
NTF ospfVirtNbrStateChange	1.3.6.1.2.1.14.16.2.3			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).

FAQ

Why would I load OSPF-TRAP-MIB alongside the base OSPF-MIB when monitoring a router network?
OSPF-MIB gives you polled OSPF objects, but OSPF-TRAP-MIB adds asynchronous notifications for OSPF version 2 events -- neighbor state transitions, interface state changes, virtual-interface issues, and protocol errors like bad packets or configuration mismatches. Loading it lets your management station get alerted the moment an OSPF neighbor drops or an interface changes state, instead of only discovering the problem on the next poll cycle.

What kinds of events actually trigger notifications defined in OSPF-TRAP-MIB?
The traps cover routing-protocol fault and state-change conditions: an OSPF neighbor transitioning to a different state, an interface (including virtual interfaces) changing operational state, and various OSPF error conditions such as configuration errors, retransmissions, or malformed packets. It's aimed at proactive alerting on routing instability on OSPF-speaking routers and Layer 3 switches, not at physical hardware counters.

RFC description

Defines SNMP trap notifications and events for OSPF routing protocol state changes, neighbor relationships, and adjacency events as specified in RFC 6549.

Start monitoring vendor-neutral, standards-based MIB (OSPFv2 trap notifications, RFC 4750) with a free 30-day trial of IPNetwork Monitor. Import MIBs, browse SNMP OIDs, create custom SNMP monitors, configure alerts, and monitor any SNMP-enabled network device from a single console.

Download OSPF-TRAP-MIB

What Is OSPF-TRAP-MIB?

Supported Devices

Monitoring Examples

What Can Be Monitored

This MIB depends on

Related MIBs

FAQ

RFC description