draft-ietf-ospf-mib-05.txt   rfc1850.txt 
Internet Draft OSPF MIB January 1995 Network Working Group F. Baker
Request For Comments: 1850 Cisco Systems
OSPF Version 2 Management Information Base Obsoletes: 1253 R. Coltun
draft-ietf-ospf-mib-05.txt Category: Standards Track RainbowBridge Communications
November 1995
Mon Jan 9 14:20:53 PST 1995
Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
fbaker@acc.com
Rob Coltun
RainbowBridge Communications OSPF Version 2 Management Information Base
(301) 340-9416
rcoltun@rainbow-bridge.com Status of this Memo
1. Status of this Memo This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are Abstract
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six This memo defines a portion of the Management Information Base (MIB)
months. Internet Drafts may be updated, replaced, or obsoleted for use with network management protocols in TCP/IP-based internets.
by other documents at any time. It is not appropriate to use In particular, it defines objects for managing the Open Shortest Path
Internet Drafts as reference material or to cite them other First Routing Protocol.
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each Table of Contents
Internet Draft directory to learn the current status of this
or any other Internet Draft.
2. Abstract 1. The SNMPv2 Network Management Framework .............. 2
1.1 Object Definitions .................................. 3
2. Overview ............................................. 3
2.1 Changes from RFC 1253 ............................... 3
2.2 Textual Conventions ................................. 6
2.3 Structure of MIB .................................... 6
2.3.1 General Variables ................................. 6
2.3.2 Area Data Structure and Area Stub Metric Table .... 7
2.3.3 Link State Database and External Link State
Database .......................................... 7
2.3.4 Address Table and Host Tables ..................... 7
2.3.5 Interface and Interface Metric Tables ............. 7
2.3.6 Virtual Interface Table ........................... 7
2.3.7 Neighbor and Virtual Neighbor Tables .............. 7
2.4 Conceptual Row Creation ............................. 7
2.5 Default Configuration ............................... 8
3. Definitions .......................................... 10
3.1 OSPF General Variables .............................. 13
3.2 OSPF Area Table ..................................... 17
3.3 OSPF Area Default Metrics ........................... 21
3.4 OSPF Link State Database ............................ 25
3.5 OSPF Address Range Table ............................ 27
3.6 OSPF Host Table ..................................... 29
3.7 OSPF Interface Table ................................ 32
3.8 OSPF Interface Metrics .............................. 39
3.9 OSPF Virtual Interface Table ........................ 42
3.10 OSPF Neighbor Table ................................ 46
3.11 OSPF Virtual Neighbor Table ........................ 51
3.12 OSPF External Link State Database .................. 54
3.13 OSPF Route Table Use ............................... 57
3.14 OSPF Area Aggregate Table .......................... 58
4. OSPF Traps ........................................... 66
4.1 Format Of Trap Definitions .......................... 67
4.2 Approach ............................................ 67
4.3 Ignoring Initial Activity ........................... 67
4.4 Throttling Traps .................................... 67
4.5 One Trap Per OSPF Event ............................. 68
4.6 Polling Event Counters .............................. 68
5. OSPF Trap Definitions ................................ 69
5.1 Trap Support Objects ................................ 69
5.2 Traps ............................................... 71
6. Acknowledgements ...................................... 78
7. References ............................................ 78
8. Security Considerations ............................... 80
9. Authors' Addresses .................................... 80
This memo defines a portion of the Management Information Base 1. The SNMPv2 Network Management Framework
(MIB) for use with network management protocols in TCP/IP-
based internets. In particular, it defines objects for
managing the Open Shortest Path First Routing Protocol.
This memo does not, in its draft form, specify a standard for The SNMPv2 Network Management Framework consists of four major
the Internet community. components. They are:
3. The SNMPv2 Network Management Framework o RFC 1441 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of
management.
The SNMPv2 Network Management Framework consists of four major o STD 17, RFC 1213 defines MIB-II, the core set of managed objects
components. They are: for the Internet suite of protocols.
o RFC 1441 which defines the SMI, the mechanisms used for o RFC 1445 which defines the administrative and other
describing and naming objects for the purpose of architectural aspects of the framework.
management.
o RFC 1213 defines MIB-II, the core set of managed objects o RFC 1448 which defines the protocol used for network
for the Internet suite of protocols. access to managed objects.
o RFC 1445 which defines the administrative and other The Framework permits new objects to be defined for the purpose of
architectural aspects of the framework. experimentation and evaluation.
o RFC 1448 which defines the protocol used for network 1.1. Object Definitions
access to managed objects.
The Framework permits new objects to be defined for the Managed objects are accessed via a virtual information store, termed
purpose of experimentation and evaluation. the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object object type is named
by an OBJECT IDENTIFIER, an administratively assigned name. The
object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to
refer to the object type.
3.1. Object Definitions 2. Overview
Managed objects are accessed via a virtual information store, 2.1. Changes from RFC 1253
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) defined in the SMI. In particular, each object
object type is named by an OBJECT IDENTIFIER, an
administratively assigned name. The object type together with
an object instance serves to uniquely identify a specific
instantiation of the object. For human convenience, we often
use a textual string, termed the descriptor, to refer to the
object type.
4. Overview The changes from RFC 1253 are the following:
4.1. Changes from RFC 1253 (1) The textual convention PositiveInteger was changed from
1..'FFFFFFFF'h to 1..'7FFFFFFF'h at the request of
Marshall Rose.
The changes from RFC 1253 are the following: (2) The textual convention TOSType was changed to reflect the
TOS values defined in the Router Requirements Draft, and
in accordance with the IP Forwarding Table MIB's values.
(1) The textual convention PositiveInteger was changed from (3) The names of some objects were changed, conforming to the
1..'FFFFFFFF'h to 1..'7FFFFFFF'h at the request of convention that an acronym (for example, LSA) is a single
Marshall Rose. word ("Lsa") in most SNMP names.
(2) The textual convention TOSType was changed to reflect the (4) textual changes were made to make the MIB readable by
TOS values defined in the Router Requirements Draft, and Dave Perkins' SMIC MIB Compiler in addition to Mosy.
in accordance with the IP Forwarding Table MIB's values. This involved changing the case of some characters in
certain names and removing the DEFVAL clauses for
Counters.
(3) The names of some objects were changed, conforming to the (5) The variables ospfAreaStatus and ospfIfStatus were added,
convention that an acronym (for example, LSA) is a single having been overlooked in the original MIB.
word ("Lsa") in most SNMP names.
(4) textual changes were made to make the MIB readable by (6) The range of the variable ospfLsdbType was extended to
Dave Perkins' SMIC MIB Compiler in addition to Mosy. include multicastLink (Group-membership LSA) and
This involved changing the case of some characters in nssaExternalLink (NSSA LSA).
certain names and removing the DEFVAL clauses for
Counters. (This would appear to violate RFC 1212, which
explicitly states that DEFVALs are for the purpose of
initializing read-only objects???)
(5) The variables ospfAreaStatus and ospfIfStatus were added, (7) The variable ospfIfMetricMetric was renamed
having been overlooked in the original MIB. ospfIfMetricValue, and the following text was removed
from its description:
(6) The range of the variable ospfLsdbType was extended to "The value FFFF is distinguished to mean 'no route via
include multicastLink (Group-membership LSA) and this TOS'."
nssaExternalLink (NSSA LSA).
(7) The variable ospfIfMetricMetric was renamed (8) The variable ospfNbmaNbrPermanence was added, with the
ospfIfMetricValue, and the following text was removed values 'dynamic' and 'permanent'; by this means,
from its description: dynamically learned and configured neighbors can be
distinguished.
"The value FFFF is distinguished to mean 'no route via (9) The DESCRIPTION of the variable ospfNbrIpAddr was changed
this TOS'." from
(8) The variable ospfNbmaNbrPermanence was added, with the "The IP address of this neighbor."
values 'dynamic' and 'permanent'; by this means,
dynamically learned and configured neighbors can be
distinguished.
(9) The DESCRIPTION of the variable ospfNbrIpAddr was changed to
from
"The IP address of this neighbor." "The IP address this neighbor is using in its IP Source
Address. Note that, on addressless links, this will not
be 0.0.0.0, but the address of another of the neighbor's
interfaces."
to This is by way of clarification and does not change the
specification.
"The IP address this neighbor is using in its IP Source (10) The OSPF External Link State Database was added. The
Address. Note that, on addressless links, this will not OSPF Link State Database used to display all LSAs stored;
be 0.0.0.0, but the address of another of the neighbor's in this MIB, it displays all but the AS External LSAs.
interfaces." This is because there are usually a large number of
External LSAs, and they are relicated in all non-Stub
Areas.
This is by way of clarification and does not change the (11) The variable ospfAreaSummary was added to control the
specification. import of summary LSAs into stub areas. If it is
noAreaSummary (default) the router will neither originate
nor propagate summary LSAs into the stub area. It will
rely entirely on its default route. If it is
sendAreaSummary, the router will both summarize and
propagate summary LSAs.
(10) The OSPF External Link State Database was added. The (12) The general variables ospfExtLsdbLimit and
OSPF Link State Database used to display all LSAs stored; ExitOverflowInterval were introduced to help handle LSDB
in this MIB, it displays all but the AS External LSAs. overflow.
This is because there are usually a large number of
External LSAs, and they are relicated in all non-Stub
Areas.
(11) The variable ospfAreaSummary was added to control the (13) The use of the IP Forwarding Table is defined.
import of summary LSAs into stub areas. If it is
noAreaSummary (default) the router will neither originate
nor propagate summary LSAs into the stub area. It will
rely entirely on its default route. If it is
sendAreaSummary, the router will both summarize and
propagate summary LSAs.
(12) The general variables ospfExtLsdbLimit and (14) The ospfAreaRangeTable was obsoleted and replaced with
ExitOverflowInterval were introduced to help handle LSDB the ospfAreaAggregateTable to accommodate two additional
overflow. indexes. The ospfAreaAggregateEntry keys now include a
LsdbType (which can be used to differentiate between the
traditional type-3 Aggregates and NSSA Aggregates) and an
ospfAreaAggregateMask (which will more clearly express
the range).
(13) The use of the IP Forwarding Table is defined. (15) The variable ospfAreaAggregateEffect was added. This
permits the network manager to hide a subnet within an
area.
(14) The ospfAreaRangeTable was obsoleted and replaced with (16) Normally, the border router of a stub area advertises a
the ospfAreaAggregateTable to accommodate two additional default route as an OSPF network summary. An NSSA border
indexes. The ospfAreaAggregateEntry keys now include a router will generate a type-7 LSA indicating a default
LsdbType (which can be used to differentiate between the route, and import it into the NSSA. ospfStubMetricType
traditional type-3 Aggregates and NSSA Aggregates) and an (ospf internal, type 1 external, or type 2 external)
ospfAreaAggregateMask (which will more clearly express indicates the type of the default metric advertised.
the range).
(15) The variable ospfAreaAggregateEffect was added. This (17) ospfMulticastExtensions is added to the OSPF General
permits the network manager to hide a subnet within an Group. This indicates the router's ability to forward IP
area. multicast (Class D) datagrams.
(16) Normally, the border router of a stub area advertises a (18) ospfIfMulticastForwarding is added to the Interface
default route as an OSPF network summary. An NSSA border Group. It indicates whether, and if so, how, multicasts
router will generate a type-7 LSA indicating a default should be forwarded on the interface.
route, and import it into the NSSA. ospfStubMetricType
(ospf internal, type 1 external, or type 2 external)
indicates the type of the default metric advertised.
(17) ospfMulticastExtensions is added to the OSPF General (19) The MIB is converted to SNMP Version 2. Beyond simple
Group. This indicates the router's ability to forward IP text changes and the addition of the MODULE-IDENTITY and
multicast (Class D) datagrams. MODULE-COMPLIANCE macros, this involved trading the
TruthValue Textual Convention for SNMP Version 2's, which
has the same values, and trading the Validation Textual
Convention for SNMP Version 2's RowStatus.
(18) ospfIfMulticastForwarding is added to the Interface (20) ospfAuthType (area authentication type) was changed to an
Group. It indicates whether, and if so, how, multicasts interface authentication type to match the key. It also
should be forwarded on the interface. has an additional value, to indicate the use of MD5 for
authentication.
(19) The MIB is converted to SNMP Version 2. Beyond simple (21) ospfIfIntfType has a new value, pointToMultipoint.
text changes and the addition of the MODULE-IDENTITY and
MODULE-COMPLIANCE macros, this involved trading the
TruthValue Textual Convention for SNMP Version 2's, which
has the same values, and trading the Validation Textual
Convention for SNMP Version 2's RowStatus.
(20) ospfAuthType (area authentication type) was changed to an (22) ospfIfDemand (read/write) is added, to permit control of
interface authentication type to match the key. It also Demand OSPF features.
has an additional value, to indicate the use of MD5 for
authentication.
(21) ospfIfIntfType has a new value, pointToMultipoint. (23) ospfNbrHelloSuppressed and ospfVirtNbrHelloSuppressed
were added, (read only). They indicate whether Hellos are
being suppressed to the neighbor.
(22) ospfIfDemand (read/write) is added, to permit control of (24) ospfDemandExtensions was added to indicate whether the
Demand OSPF features. Demand OSPF extensions have been implemented, and to
disable them if appropriate.
(23) ospfNbrHelloSuppressed is added, (read only). This 2.2. Textual Conventions
indicates whether Hellos are being suppressed to the
neighbor.
4.2. Textual Conventions Several new data types are introduced as a textual convention in this
MIB document. These textual conventions enhance the readability of
the specification and can ease comparison with other specifications
if appropriate. It should be noted that the introduction of the
these textual conventions has no effect on either the syntax nor the
semantics of any managed objects. The use of these is merely an
artifact of the explanatory method used. Objects defined in terms of
one of these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or the SNMP
are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers and writers in pursuit
of the elusive goal of clear, concise, and unambiguous MIB documents.
Several new data types are introduced as a textual convention The new data types are AreaID, RouterID, TOSType, Metric, BigMetric,
in this MIB document. These textual conventions enhance the Status, PositiveInteger, HelloRange, UpToMaxAge, InterfaceIndex, and
readability of the specification and can ease comparison with DesignatedRouterPriority.
other specifications if appropriate. It should be noted that
the introduction of the these textual conventions has no
effect on either the syntax nor the semantics of any managed
objects. The use of these is merely an artifact of the
explanatory method used. Objects defined in terms of one of
these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or
the SNMP are necessary to accommodate these textual
conventions which are adopted merely for the convenience of
readers and writers in pursuit of the elusive goal of clear,
concise, and unambiguous MIB documents.
The new data types are AreaID, RouterID, TOSType, Metric, 2.3. Structure of MIB
BigMetric, Status, PositiveInteger, HelloRange, UpToMaxAge,
InterfaceIndex, and DesignatedRouterPriority.
4.3. Structure of MIB The MIB is composed of the following sections:
The MIB is composed of the following sections:
General Variables General Variables
Area Data Structure Area Data Structure
Area Stub Metric Table Area Stub Metric Table
Link State Database Link State Database
Address Range Table Address Range Table
Host Table Host Table
Interface Table Interface Table
Interface Metric Table Interface Metric Table
Virtual Interface Table Virtual Interface Table
Neighbor Table Neighbor Table
Virtual Neighbor Table Virtual Neighbor Table
External Link State Database External Link State Database
Aggregate Range Table Aggregate Range Table
There exists a separate MIB for notifications ("traps"), which There exists a separate MIB for notifications ("traps"), which is
is entirely optional. entirely optional.
4.3.1. General Variables 2.3.1. General Variables
The General Variables are about what they sound like; The General Variables are about what they sound like; variables which
variables which are global to the OSPF Process. are global to the OSPF Process.
4.3.2. Area Data Structure and Area Stub Metric Table 2.3.2. Area Data Structure and Area Stub Metric Table
The Area Data Structure describes the OSPF Areas that the The Area Data Structure describes the OSPF Areas that the router
router participates in. The Area Stub Metric Table describes participates in. The Area Stub Metric Table describes the metrics
the metrics advertised into a stub area by the default advertised into a stub area by the default router(s).
router(s).
4.3.3. Link State Database and External Link State Database 2.3.3. Link State Database and External Link State Database
The Link State Database is provided primarily to provide The Link State Database is provided primarily to provide detailed
detailed information for network debugging. information for network debugging.
4.3.4. Address Table and Host Tables 2.3.4. Address Table and Host Tables
The Address Range Table and Host Table are provided to view The Address Range Table and Host Table are provided to view
configured Network Summary and Host Route information. configured Network Summary and Host Route information.
4.3.5. Interface and Interface Metric Tables 2.3.5. Interface and Interface Metric Tables
The Interface Table and the Interface Metric Table together The Interface Table and the Interface Metric Table together describe
describe the various IP interfaces to OSPF. The metrics are the various IP interfaces to OSPF. The metrics are placed in
placed in separate tables in order to simplify dealing with separate tables in order to simplify dealing with multiple types of
multiple types of service, and to provide flexibility in the service, and to provide flexibility in the event that the IP TOS
event that the IP TOS definition is changed in the future. A definition is changed in the future. A Default Value specification
Default Value specification is supplied for the TOS 0 is supplied for the TOS 0 (default) metric.
(default) metric.
4.3.6. Virtual Interface Table 2.3.6. Virtual Interface Table
Likewise, the Virtual Interface Table describe virtual links Likewise, the Virtual Interface Table describe virtual links to the
to the OSPF Process. OSPF Process.
4.3.7. Neighbor and Virtual Neighbor Tables 2.3.7. Neighbor and Virtual Neighbor Tables
The Neighbor Table and the Virtual Neighbor Table describe the The Neighbor Table and the Virtual Neighbor Table describe the
neighbors to the OSPF Process. neighbors to the OSPF Process.
4.4. Conceptual Row Creation 2.4. Conceptual Row Creation
For the benefit of row-creation in "conceptual" (see [9]) For the benefit of row-creation in "conceptual" (see [9]) tables,
tables, DEFVAL (Default Value) clauses are included in the DEFVAL (Default Value) clauses are included in the definitions in
definitions in section 5, suggesting values which an agent section 3, suggesting values which an agent should use for instances
should use for instances of variables which need to be created of variables which need to be created due to a Set-Request, but which
due to a Set-Request, but which are not specified in the Set- are not specified in the Set-Request. DEFVAL clauses have not been
Request. DEFVAL clauses have not been specified for some specified for some objects which are read-only, implying that they
objects which are read-only, implying that they are zeroed are zeroed upon row creation. These objects are of the SYNTAX
upon row creation. These objects are of the SYNTAX Counter32 Counter32 or Gauge32.
or Gauge32.
For those objects not having a DEFVAL clause, both management For those objects not having a DEFVAL clause, both management
stations and agents should heed the Robustness Principle of stations and agents should heed the Robustness Principle of the
the Internet (see RFC-791): Internet (see RFC-791):
"be liberal in what you accept, conservative in what you "be liberal in what you accept, conservative in what you
send" send"
That is, management stations should include as many of these That is, management stations should include as many of these columnar
columnar objects as possible (e.g., all read-write objects) in objects as possible (e.g., all read-write objects) in a Set-Request
a Set-Request when creating a conceptual row; agents should when creating a conceptual row; agents should accept a Set-Request
accept a Set-Request with as few of these as they need (e.g., with as few of these as they need (e.g., the minimum contents of a
the minimum contents of a row creating SET consists of those row creating SET consists of those objects for which, as they cannot
objects for which, as they cannot be intuited, no default is be intuited, no default is specified.).
specified.).
There are numerous read-write objects in this MIB, as it is There are numerous read-write objects in this MIB, as it is designed
designed for SNMP management of the protocol, not just SNMP for SNMP management of the protocol, not just SNMP monitoring of its
monitoring of its state. However, in the absence of a state. However, in the absence of a standard SNMP Security
standard SNMP Security architecture, it is acceptable for architecture, it is acceptable for implementations to implement these
implementations to implement these as read-only with an as read-only with an alternative interface for their modification.
alternative interface for their modification.
4.5. Default Configuration 2.5. Default Configuration
OSPF is a powerful routing protocol, equipped with features to OSPF is a powerful routing protocol, equipped with features to handle
handle virtually any configuration requirement that might virtually any configuration requirement that might reasonably be
reasonably be found within an Autonomous System. With this found within an Autonomous System. With this power comes a fair
power comes a fair degree of complexity, which the sheer degree of complexity, which the sheer number of objects in the MIB
number of objects in the MIB will attest to. Care has will attest to. Care has therefore been taken, in constructing this
therefore been taken, in constructing this MIB, to define MIB, to define default values for virtually every object, to minimize
default values for virtually every object, to minimize the the amount of parameterization required in the typical case. That
amount of parameterization required in the typical case. That default configuration is as follows:
default configuration is as follows:
Given the following assumptions: Given the following assumptions:
- IP has already been configured - IP has already been configured
- The ifTable has already been configured - The ifTable has already been configured
- ifSpeed is estimated by the interface drivers
- The OSPF Process automatically discovers all IP - ifSpeed is estimated by the interface drivers
Interfaces and creates corresponding OSPF Interfaces
- The TOS 0 metrics are autonomously derived from ifSpeed - The OSPF Process automatically discovers all IP
Interfaces and creates corresponding OSPF Interfaces
- The OSPF Process automatically creates the Areas required - The TOS 0 metrics are autonomously derived from ifSpeed
for the Interfaces
The simplest configuration of an OSPF process requires that: - The OSPF Process automatically creates the Areas required
for the Interfaces
- The OSPF Process be Enabled. The simplest configuration of an OSPF process requires that:
- The OSPF Process be Enabled.
This can be accomplished with a single SET:
This can be accomplished with a single SET:
ospfAdminStat := enabled. ospfAdminStat := enabled.
The configured system will have the following attributes: The configured system will have the following attributes:
- The RouterID will be one of the IP addresses of the - The RouterID will be one of the IP addresses of the
device device
- The device will be neither an Area Border Router nor an - The device will be neither an Area Border Router nor an
Autonomous System Border Router. Autonomous System Border Router.
- Every IP Interface, with or without an address, will be - Every IP Interface, with or without an address, will be
an OSPF Interface. an OSPF Interface.
- The AreaID of each interface will be 0.0.0.0, the - The AreaID of each interface will be 0.0.0.0, the
Backbone. Backbone.
- Authentication will be disabled - Authentication will be disabled
- All Broadcast and Point to Point interfaces will be - All Broadcast and Point to Point interfaces will be
operational. NBMA Interfaces require the configuration operational. NBMA Interfaces require the configuration
of at least one neighbor. of at least one neighbor.
- Timers on all direct interfaces will be:
- Timers on all direct interfaces will be:
Hello Interval: 10 seconds Hello Interval: 10 seconds
Dead Timeout: 40 Seconds Dead Timeout: 40 Seconds
Retransmission: 5 Seconds Retransmission: 5 Seconds
Transit Delay: 1 Second Transit Delay: 1 Second
Poll Interval: 120 Seconds Poll Interval: 120 Seconds
- no direct links to hosts will be configured. - no direct links to hosts will be configured.
- no addresses will be summarized - no addresses will be summarized
- Metrics, being a measure of bit duration, are unambiguous - Metrics, being a measure of bit duration, are unambiguous
and intelligent. and intelligent.
- No Virtual Links will be configured. - No Virtual Links will be configured.
5. Definitions 3. Definitions
OSPF-MIB DEFINITIONS ::= BEGIN OSPF-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, OBJECT-TYPE, Counter32, Gauge32,
Integer32, IpAddress Integer32, IpAddress
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TruthValue, RowStatus TEXTUAL-CONVENTION, TruthValue, RowStatus
FROM SNMPv2-TC FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
mib-2 FROM RFC1213-MIB; mib-2 FROM RFC1213-MIB;
-- This MIB module uses the extended OBJECT-TYPE macro as -- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in [9]. -- defined in [9].
ospf MODULE-IDENTITY ospf MODULE-IDENTITY
LAST-UPDATED "9501091420Z" -- Mon Jan 9 14:20:53 PST 1995 LAST-UPDATED "9501201225Z" -- Fri Jan 20 12:25:50 PST 1995
ORGANIZATION "IETF OSPF Working Group" ORGANIZATION "IETF OSPF Working Group"
CONTACT-INFO CONTACT-INFO
" Fred Baker " Fred Baker
Postal: Advanced Computer Communications Postal: Cisco Systems
315 Bollay Drive 519 Lado Drive
Santa Barbara, California 93117 Santa Barbara, California 93111
Tel: +1 085 685 4455 Tel: +1 805 681 0115
E-Mail: fbaker@acc.com E-Mail: fred@cisco.com
Rob Coltun Rob Coltun
Postal: RainbowBridge Communications Postal: RainbowBridge Communications
Tel: (301) 340-9416 Tel: (301) 340-9416
E-Mail: rcoltun@rainbow-bridge.com" E-Mail: rcoltun@rainbow-bridge.com"
DESCRIPTION DESCRIPTION
"The MIB module to describe the OSPF Version 2 "The MIB module to describe the OSPF Version 2
Protocol" Protocol"
::= { mib-2 14 } ::= { mib-2 14 }
skipping to change at page 20, line 10 skipping to change at page 16, line 10
This number does not include newer instantia- This number does not include newer instantia-
tions of self-originated link-state advertise- tions of self-originated link-state advertise-
ments." ments."
::= { ospfGeneralGroup 10 } ::= { ospfGeneralGroup 10 }
ospfExtLsdbLimit OBJECT-TYPE ospfExtLsdbLimit OBJECT-TYPE
SYNTAX Integer32 (-1..'7FFFFFFF'h) SYNTAX Integer32 (-1..'7FFFFFFF'h)
MAX-ACCESS read-write MAX-ACCESS read-write
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The maximum number of external link-state en- "The maximum number of non-default AS-
tries that can be stored in the link-state da- external-LSAs entries that can be stored in the
tabase. If the value is -1, then there is no link-state database. If the value is -1, then
limit. there is no limit.
When the number of non-default AS-external-LSAs When the number of non-default AS-external-LSAs
in a router's link-state database reaches in a router's link-state database reaches
ospfExtLsdbLimit, the router enters Overflow- ospfExtLsdbLimit, the router enters Overflow-
State. The router never holds more than State. The router never holds more than
ospfExtLsdbLimit non-default AS-external-LSAs ospfExtLsdbLimit non-default AS-external-LSAs
in its database. OspfExtLsdbLimit MUST be set in its database. OspfExtLsdbLimit MUST be set
identically in all routers attached to the OSPF identically in all routers attached to the OSPF
backbone and/or any regular OSPF area. (i.e., backbone and/or any regular OSPF area. (i.e.,
OSPF stub areas and NSSAs are excluded)." OSPF stub areas and NSSAs are excluded)."
skipping to change at page 23, line 5 skipping to change at page 17, line 26
DESCRIPTION DESCRIPTION
"The number of seconds that, after entering "The number of seconds that, after entering
OverflowState, a router will attempt to leave OverflowState, a router will attempt to leave
OverflowState. This allows the router to again OverflowState. This allows the router to again
originate non-default AS-external-LSAs. When originate non-default AS-external-LSAs. When
set to 0, the router will not leave Overflow- set to 0, the router will not leave Overflow-
State until restarted." State until restarted."
DEFVAL { 0 } DEFVAL { 0 }
::= { ospfGeneralGroup 13 } ::= { ospfGeneralGroup 13 }
ospfDemandExtensions OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The router's support for demand routing."
REFERENCE
"OSPF Version 2, Appendix on Demand Routing"
::= { ospfGeneralGroup 14 }
-- The OSPF Area Data Structure contains information -- The OSPF Area Data Structure contains information
-- regarding the various areas. The interfaces and -- regarding the various areas. The interfaces and
-- virtual links are configured as part of these areas. -- virtual links are configured as part of these areas.
-- Area 0.0.0.0, by definition, is the Backbone Area -- Area 0.0.0.0, by definition, is the Backbone Area
ospfAreaTable OBJECT-TYPE ospfAreaTable OBJECT-TYPE
SYNTAX SEQUENCE OF OspfAreaEntry SYNTAX SEQUENCE OF OspfAreaEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 68, line 45 skipping to change at page 51, line 47
RouterID, RouterID,
ospfVirtNbrIpAddr ospfVirtNbrIpAddr
IpAddress, IpAddress,
ospfVirtNbrOptions ospfVirtNbrOptions
Integer32, Integer32,
ospfVirtNbrState ospfVirtNbrState
INTEGER, INTEGER,
ospfVirtNbrEvents ospfVirtNbrEvents
Counter32, Counter32,
ospfVirtNbrLsRetransQLen ospfVirtNbrLsRetransQLen
Gauge32 Gauge32,
ospfVirtNbrHelloSuppressed
TruthValue
} }
ospfVirtNbrArea OBJECT-TYPE ospfVirtNbrArea OBJECT-TYPE
SYNTAX AreaID SYNTAX AreaID
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The Transit Area Identifier." "The Transit Area Identifier."
::= { ospfVirtNbrEntry 1 } ::= { ospfVirtNbrEntry 1 }
skipping to change at page 72, line 5 skipping to change at page 53, line 41
ospfVirtNbrLsRetransQLen OBJECT-TYPE ospfVirtNbrLsRetransQLen OBJECT-TYPE
SYNTAX Gauge32 SYNTAX Gauge32
MAX-ACCESS read-only MAX-ACCESS read-only
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The current length of the retransmission "The current length of the retransmission
queue." queue."
::= { ospfVirtNbrEntry 7 } ::= { ospfVirtNbrEntry 7 }
ospfVirtNbrHelloSuppressed OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether Hellos are being suppressed
to the neighbor"
::= { ospfVirtNbrEntry 8 }
-- OSPF Link State Database, External -- OSPF Link State Database, External
-- The Link State Database contains the Link State -- The Link State Database contains the Link State
-- Advertisements from throughout the areas that the -- Advertisements from throughout the areas that the
-- device is attached to. -- device is attached to.
-- This table is identical to the OSPF LSDB Table in -- This table is identical to the OSPF LSDB Table in
-- format, but contains only External Link State -- format, but contains only External Link State
-- Advertisements. The purpose is to allow external -- Advertisements. The purpose is to allow external
-- LSAs to be displayed once for the router rather -- LSAs to be displayed once for the router rather
skipping to change at page 82, line 21 skipping to change at page 62, line 9
ospfVersionNumber, ospfVersionNumber,
ospfAreaBdrRtrStatus, ospfAreaBdrRtrStatus,
ospfASBdrRtrStatus, ospfASBdrRtrStatus,
ospfExternLsaCount, ospfExternLsaCount,
ospfExternLsaCksumSum, ospfExternLsaCksumSum,
ospfTOSSupport, ospfTOSSupport,
ospfOriginateNewLsas, ospfOriginateNewLsas,
ospfRxNewLsas, ospfRxNewLsas,
ospfExtLsdbLimit, ospfExtLsdbLimit,
ospfMulticastExtensions, ospfMulticastExtensions,
ospfExitOverflowInterval ospfExitOverflowInterval,
ospfDemandExtensions
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are required for OSPF systems." "These objects are required for OSPF systems."
::= { ospfGroups 1 } ::= { ospfGroups 1 }
ospfAreaGroup OBJECT-GROUP ospfAreaGroup OBJECT-GROUP
OBJECTS { OBJECTS {
ospfAreaId, ospfAreaId,
ospfImportAsExtern, ospfImportAsExtern,
skipping to change at page 87, line 13 skipping to change at page 65, line 45
::= { ospfGroups 10 } ::= { ospfGroups 10 }
ospfVirtNbrGroup OBJECT-GROUP ospfVirtNbrGroup OBJECT-GROUP
OBJECTS { OBJECTS {
ospfVirtNbrArea, ospfVirtNbrArea,
ospfVirtNbrRtrId, ospfVirtNbrRtrId,
ospfVirtNbrIpAddr, ospfVirtNbrIpAddr,
ospfVirtNbrOptions, ospfVirtNbrOptions,
ospfVirtNbrState, ospfVirtNbrState,
ospfVirtNbrEvents, ospfVirtNbrEvents,
ospfVirtNbrLsRetransQLen ospfVirtNbrLsRetransQLen,
ospfVirtNbrHelloSuppressed
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are required for OSPF systems." "These objects are required for OSPF systems."
::= { ospfGroups 11 } ::= { ospfGroups 11 }
ospfExtLsdbGroup OBJECT-GROUP ospfExtLsdbGroup OBJECT-GROUP
OBJECTS { OBJECTS {
ospfExtLsdbType, ospfExtLsdbType,
ospfExtLsdbLsid, ospfExtLsdbLsid,
skipping to change at page 89, line 4 skipping to change at page 66, line 38
ospfAreaAggregateMask, ospfAreaAggregateMask,
ospfAreaAggregateStatus, ospfAreaAggregateStatus,
ospfAreaAggregateEffect ospfAreaAggregateEffect
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are required for OSPF systems." "These objects are required for OSPF systems."
::= { ospfGroups 13 } ::= { ospfGroups 13 }
END END
6. OSPF Traps
OSPF is an event driven routing protocol, where an event can 4. OSPF Traps
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. Another approach is to notify a network manager of
potentially critical OSPF events with SNMP traps.
This section defines a set of traps, objects and mechanisms to OSPF is an event driven routing protocol, where an event can be a
enhance the ability to manage IP internetworks which use OSPF change in an OSPF interface's link-level status, the expiration of an
as its IGP. It is an optional but useful extension to the OSPF timer or the reception of an OSPF protocol packet. Many of the
OSPF MIB. 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. Another approach is to notify a network manager of
potentially critical OSPF events with SNMP traps.
6.1. Format Of Trap Definitions This section defines a set of traps, objects and mechanisms to
enhance the ability to manage IP internetworks which use OSPF as its
IGP. It is an optional but useful extension to the OSPF MIB.
Section A.4.0 contains contains the trap definitions using 4.1. Format Of Trap Definitions
6.2. Approach Section 7 contains contains the trap definitions.
The mechanism for sending traps is straight-forward. When an 4.2. Approach
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. A new object is defined in
section 5.2 that will allow a network manager to enable or
disable particular OSPF traps. Section A.4.0 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 The mechanism for sending traps is straight-forward. When an
mechanisms are suggested. 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. A new object is defined in section 3.2 that will
allow a network manager to enable or disable particular OSPF traps.
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.
6.3. Ignoring Initial Activity To limit the frequency of OSPF traps, the following additional
mechanisms are suggested.
The majority of critical events occur when OSPF is enabled on 4.3. Ignoring Initial Activity
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, ospfTxRetranmit 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.
6.4. Throttling Traps 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, ospfTxRetranmit 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.
The mechanism for throttling the traps is similar to the 4.4. Throttling Traps
mechanism explained in RFC 1224 [11] section 5. The basic
idea is that there is a sliding window in seconds and an upper
bound on the number of traps that may be generated within this
window. 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 traps The mechanism for throttling the traps is similar to the mechanism
types except for the ospfLsdbOverflow and the explained in RFC 1224 [11], section 5. The basic idea is that there
ospfLsdbApproachingOverflow trap which should not be is a sliding window in seconds and an upper bound on the number of
throttled. For example, if the window time is 3, the upper traps that may be generated within this window. Unlike RFC 1224,
bound is 3 and the events that would cause trap types 1,3,5 traps are not sent to inform the network manager that the throttling
and 7 occur within a 3 second period, the type 7 trap should mechanism has kicked in.
not be generated.
Appropriate values are 7 traps with a window time of 10 A single window should be used to throttle all OSPF traps types
seconds. except for the ospfLsdbOverflow and the ospfLsdbApproachingOverflow
trap which should not be throttled. For example, if the window time
is 3, the upper bound is 3 and the events that would cause trap types
1,3,5 and 7 occur within a 3 second period, the type 7 trap should
not be generated.
6.5. One Trap Per OSPF Event Appropriate values are 7 traps with a window time of 10 seconds.
Several of the traps defined in section A.4.0 are generated as 4.5. One Trap Per OSPF Event
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.
6.6. Polling Event Counters 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.
Many of the tables in the OSPF MIB contain generalized event 4.6. Polling Event Counters
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 Many of the tables in the OSPF MIB contain generalized event
counters defined in the OSPF MIB and the trap types defined in counters. By enabling the traps defined in this document a network
section A.4.0 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 defined in section 5.
Counter32 Trap Type Counter32 Trap Type
----------------------- ------------------------ ----------------------- ------------------------
ospfOriginateNewLsas ospfOriginateLsa ospfOriginateNewLsas ospfOriginateLsa
ospfIfEvents ospfIfStateChange ospfIfEvents ospfIfStateChange
ospfConfigError ospfConfigError
ospfIfAuthFailure ospfIfAuthFailure
ospfRxBadPacket ospfRxBadPacket
ospfTxRetransmit ospfTxRetransmit
ospfVirtIfEvents ospfVirtIfStateChange ospfVirtIfEvents ospfVirtIfStateChange
ospfVirtIfConfigError ospfVirtIfConfigError
ospfVirtIfAuthFailure ospfVirtIfAuthFailure
ospfVirtIfRxBadPacket ospfVirtIfRxBadPacket
ospfVirtIfTxRetransmit ospfVirtIfTxRetransmit
ospfNbrEvents ospfNbrStateChange ospfNbrEvents ospfNbrStateChange
ospfVirtNbrEvents ospfVirtNbrStateChange ospfVirtNbrEvents ospfVirtNbrStateChange
ospfExternLSACount ospfLsdbApproachingOverflow ospfExternLSACount ospfLsdbApproachingOverflow
ospfExternLSACount ospfLsdbOverflow ospfExternLSACount ospfLsdbOverflow
7. OSPF Trap Definitions 5. OSPF Trap Definitions
OSPF-TRAP-MIB DEFINITIONS ::= BEGIN OSPF-TRAP-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF FROM SNMPv2-CONF
ospfRouterId, ospfIfIpAddress, ospfAddressLessIf, ospfIfState, ospfRouterId, ospfIfIpAddress, ospfAddressLessIf, ospfIfState,
ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState, ospfVirtIfAreaId, ospfVirtIfNeighbor, ospfVirtIfState,
ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrIpAddr, ospfNbrAddressLessIndex, ospfNbrRtrId,
ospfNbrState, ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrState, ospfNbrState, ospfVirtNbrArea, ospfVirtNbrRtrId, ospfVirtNbrState,
ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, ospfLsdbAreaId, ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, ospfLsdbAreaId,
ospfExtLsdbLimit, ospf ospfExtLsdbLimit, ospf
FROM OSPF-MIB; FROM OSPF-MIB;
ospfTrap MODULE-IDENTITY ospfTrap MODULE-IDENTITY
LAST-UPDATED "9402091913Z" -- Mon Jan 9 14:20:53 PST 1995 LAST-UPDATED "9501201225Z" -- Fri Jan 20 12:25:50 PST 1995
ORGANIZATION "IETF OSPF Working Group" ORGANIZATION "IETF OSPF Working Group"
CONTACT-INFO CONTACT-INFO
" Fred Baker " Fred Baker
Postal: Advanced Computer Communications Postal: Cisco Systems
315 Bollay Drive 519 Lado Drive
Santa Barbara, California 93117 Santa Barbara, California 93111
Tel: +1 085 685 4455 Tel: +1 805 681 0115
E-Mail: fbaker@acc.com E-Mail: fred@cisco.com
Rob Coltun Rob Coltun
Postal: RainbowBridge Communications Postal: RainbowBridge Communications
Tel: (301) 340-9416 Tel: (301) 340-9416
E-Mail: rcoltun@rainbow-bridge.com" E-Mail: rcoltun@rainbow-bridge.com"
DESCRIPTION DESCRIPTION
"The MIB module to describe traps for the OSPF "The MIB module to describe traps for the OSPF
Version 2 Protocol." Version 2 Protocol."
::= { ospf 16 } ::= { ospf 16 }
skipping to change at page 98, line 4 skipping to change at page 73, line 42
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An ospfConfigError trap signifies that a pack- "An ospfConfigError trap signifies that a pack-
et has been received on a virtual interface et has been received on a virtual interface
from a router whose configuration parameters from a router whose configuration parameters
conflict with this router's configuration conflict with this router's configuration
parameters. Note that the event optionMismatch parameters. Note that the event optionMismatch
should cause a trap only if it prevents an ad- should cause a trap only if it prevents an ad-
jacency from forming." jacency from forming."
::= { ospfTraps 5 } ::= { ospfTraps 5 }
ospfIfAuthFailure NOTIFICATION-TYPE ospfIfAuthFailure NOTIFICATION-TYPE
OBJECTS { OBJECTS {
ospfRouterId, -- The originator of the trap ospfRouterId, -- The originator of the trap
ospfIfIpAddress, ospfIfIpAddress,
ospfAddressLessIf, ospfAddressLessIf,
ospfPacketSrc, -- The source IP address ospfPacketSrc, -- The source IP address
ospfConfigErrorType, -- authTypeMismatch or authFailure ospfConfigErrorType, -- authTypeMismatch or
-- authFailure
ospfPacketType ospfPacketType
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An ospfIfAuthFailure trap signifies that a "An ospfIfAuthFailure trap signifies that a
packet has been received on a non-virtual in- packet has been received on a non-virtual in-
terface from a router whose authentication key terface from a router whose authentication key
or authentication type conflicts with this or authentication type conflicts with this
router's authentication key or authentication router's authentication key or authentication
type." type."
::= { ospfTraps 6 } ::= { ospfTraps 6 }
ospfVirtIfAuthFailure NOTIFICATION-TYPE ospfVirtIfAuthFailure NOTIFICATION-TYPE
OBJECTS { OBJECTS {
ospfRouterId, -- The originator of the trap ospfRouterId, -- The originator of the trap
ospfVirtIfAreaId, ospfVirtIfAreaId,
ospfVirtIfNeighbor, ospfVirtIfNeighbor,
ospfConfigErrorType, -- authTypeMismatch or authFailure ospfConfigErrorType, -- authTypeMismatch or
-- authFailure
ospfPacketType ospfPacketType
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"An ospfVirtIfAuthFailure trap signifies that a "An ospfVirtIfAuthFailure trap signifies that a
packet has been received on a virtual interface packet has been received on a virtual interface
from a router whose authentication key or au- from a router whose authentication key or au-
thentication type conflicts with this router's thentication type conflicts with this router's
authentication key or authentication type." authentication key or authentication type."
::= { ospfTraps 7 } ::= { ospfTraps 7 }
skipping to change at page 104, line 4 skipping to change at page 78, line 23
ospfPacketType, ospfPacketType,
ospfPacketSrc ospfPacketSrc
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"These objects are required to control traps "These objects are required to control traps
from OSPF systems." from OSPF systems."
::= { ospfTrapGroups 1 } ::= { ospfTrapGroups 1 }
END END
8. Acknowledgements
This document was produced by the OSPF Working Group. 6. Acknowledgements
9. References This document was produced by the OSPF Working Group.
[1] V. Cerf, IAB Recommendations for the Development of 7. References
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] V. Cerf, Report of the Second Ad Hoc Network Management [1] Cerf, V., "IAB Recommendations for the Development of Internet
Review Group, Internet Working Group Request for Comments Network Management Standards", RFC 1052, NRI, April 1988.
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[3] M.T. Rose and K. McCloghrie, Structure and Identification [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
of Management Information for TCP/IP-based internets, Group", RFC 1109, NRI, August 1989.
Internet Working Group Request for Comments 1155.
Network Information Center, SRI International, Menlo
Park, California, (May, 1990).
[4] K. McCloghrie and M.T. Rose, Management Information Base [3] Rose M., and K. McCloghrie, "Structure and Identification of
for Network Management of TCP/IP-based internets, Management Information for TCP/IP-based internets", STD 16, RFC
Internet Working Group Request for Comments 1156. 1155, Performance Systems International, Hughes LAN Systems, May
Network Information Center, SRI International, Menlo 1990.
Park, California, (May, 1990).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, [4] McCloghrie K., and M. Rose, "Management Information Base for
Simple Network Management Protocol, Internet Working Network Management of TCP/IP-based internets", RFC 1156, Hughes
Group Request for Comments 1157. Network Information LAN Systems, Performance Systems International, May 1990.
Center, SRI International, Menlo Park, California, (May,
1990).
[6] M.T. Rose (editor), Management Information Base for [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management of TCP/IP-based internets, Internet Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Working Group Request for Comments 1213. Network Performance Systems International, Performance Systems
Information Center, SRI International, Menlo Park, International, MIT Laboratory for Computer Science, May 1990.
California, (May, 1990).
[7] Information processing systems - Open Systems [6] Rose M., Editor, "Management Information Base for Network
Interconnection - Specification of Abstract Syntax Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213,
Notation One (ASN.1), International Organization for Performance Systems International, March 1991.
Standardization. International Standard 8824, (December,
1987).
[8] Information processing systems - Open Systems [7] Information processing systems - Open Systems Interconnection -
Interconnection - Specification of Basic Encoding Rules Specification of Abstract Syntax Notation One (ASN.1),
for Abstract Notation One (ASN.1), International International Organization for Standardization, International
Organization for Standardization. International Standard Standard 8824, December 1987.
8825, (December, 1987).
[9] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB [8] Information processing systems - Open Systems Interconnection -
Definitions, Internet Draft, Internet Engineering Task Specification of Basic Encoding Rules for Abstract Notation One
Force, (September, 1990). (ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[10] M.T. Rose (editor), A Convention for Defining Traps for [9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
use with the SNMP, Internet Working Group Request for STD 16, RFC 1212, Performance Systems International, Hughes LAN
Comments 1215. Network Information Center, SRI Systems, March 1991.
International, Menlo Park, California, (March, 1991).
[11] L. Steinberg, Techniques for Managing Asynchronously [10] Rose, M., Editor, "A Convention for Defining Traps for use with
Generated Alerts. Internet Working Group Request for the SNMP", RFC 1215, Performance Systems International, March
Comments 1224. Network Information Center, SRI 1991.
International, Menlo Park, California, (May, 1991).
[12] J. Moy, Multicast Extensions to OSPF, Internet Draft, [11] Steinberg, L., "Techniques for Managing Asynchronously Generated
Proteon, Inc., (September, 1993). Alerts", RFC 1224, IBM Corporation, May 1991.
Table of Contents [12] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc.,
September 1993.
1 Status of this Memo ................................... 1 8. Security Considerations
2 Abstract .............................................. 2
3 The SNMPv2 Network Management Framework ............... 3 Security issues are not discussed in this memo.
3.1 Object Definitions .................................. 3
4 Overview .............................................. 3 9. Authors' Addresses
4.1 Changes from RFC 1253 ............................... 3
4.2 Textual Conventions ................................. 7 Fred Baker
4.3 Structure of MIB .................................... 7 cisco Systems, Inc.
4.3.1 General Variables ................................. 7 519 Lado Drive
4.3.2 Area Data Structure and Area Stub Metric Table .... 8 Santa Barbara, CA 93111
4.3.3 Link State Database and External Link State Da-
tabase ............................................. 8 Phone: (805) 681-0115
4.3.4 Address Table and Host Tables ..................... 8 EMail: fred@cisco.com
4.3.5 Interface and Interface Metric Tables ............. 8
4.3.6 Virtual Interface Table ........................... 8 Rob Coltun
4.3.7 Neighbor and Virtual Neighbor Tables .............. 8 RainbowBridge Communications
4.4 Conceptual Row Creation ............................. 8
4.5 Default Configuration ............................... 9 Phone: (301) 340-9416
5 Definitions ........................................... 12 EMail: rcoltun@rainbow-bridge.com
5.1 OSPF General Variables .............................. 15
5.2 OSPF Area Table ..................................... 22
5.3 OSPF Area Default Metrics ........................... 27
5.4 OSPF Link State Database ............................ 30
5.5 OSPF Address Range Table ............................ 35
5.6 OSPF Host Table ..................................... 38
5.7 OSPF Interface Table ................................ 41
5.8 OSPF Interface Metrics .............................. 51
5.9 OSPF Virtual Interface Table ........................ 55
5.10 OSPF Neighbor Table ................................ 61
5.11 OSPF Virtual Neighbor Table ........................ 67
5.12 OSPF External Link State Database .................. 71
5.13 OSPF Route Table Use ............................... 76
5.14 OSPF Area Aggregate Table .......................... 77
6 OSPF Traps ............................................ 89
6.1 Format Of Trap Definitions .......................... 89
6.2 Approach ............................................ 89
6.3 Ignoring Initial Activity ........................... 89
6.4 Throttling Traps .................................... 90
6.5 One Trap Per OSPF Event ............................. 90
6.6 Polling Event Counters .............................. 91
7 OSPF Trap Definitions ................................. 91
7.1 Trap Support Objects ................................ 91
7.2 Traps ............................................... 94
8 Acknowledgements ...................................... 104
9 References ............................................ 105
 End of changes. 149 change blocks. 
447 lines changed or deleted 468 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/