idnits 2.17.1 draft-ietf-ospf-trapmib-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 113 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 182 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 41 has weird spacing: '... Drafts are ...' == Line 42 has weird spacing: '...cuments of t...' == Line 43 has weird spacing: '...t other group...' == Line 53 has weird spacing: '... Draft direc...' == Line 61 has weird spacing: '...n event can...' == (108 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 1992) is 11485 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 573 looks like a reference -- Missing reference section? '2' on line 576 looks like a reference -- Missing reference section? '5' on line 592 looks like a reference -- Missing reference section? '8' on line 610 looks like a reference -- Missing reference section? '6' on line 598 looks like a reference -- Missing reference section? '9' on line 614 looks like a reference -- Missing reference section? '7' on line 604 looks like a reference -- Missing reference section? '3' on line 580 looks like a reference -- Missing reference section? '4' on line 586 looks like a reference -- Missing reference section? '10' on line 620 looks like a reference -- Missing reference section? '11' on line 625 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft OSPF Trap MIB November 1992 4 OSPF Version 2 Traps 6 Rob Coltun 8 Consultant 10 (301) 340-9416 11 rcoltun@ni.umd.edu 13 Fred Baker 15 Advanced Computer Communications 16 315 Bollay Drive 17 Santa Barbara, California 93117 19 fbaker@acc.com 21 Table Of Contents 23 1.0 Status Of This Memo ...................................... 2 24 2.0 Abstract ................................................. 2 25 3.0 The Network Management Framework ......................... 2 26 4.0 Objects .................................................. 3 27 4.0 Format Of Definitions .................................... 3 28 5.0 Approach ................................................. 4 29 5.1 Ignoring Initial Activity ................................ 4 30 5.2 Throttling Traps ......................................... 4 31 5.3 One Trap Per OSPF Event .................................. 4 32 5.4 Polling Event Counters ................................... 5 33 6.0 OSPF Trap Definitions .................................... 6 34 6.1 Imports .................................................. 6 35 6.2 Trap Support Objects ..................................... 6 36 6.3 Traps .................................................... 7 37 7.0 Acknowledgements ......................................... 12 38 8.0 References ............................................... 12 39 1.0 Status Of This Memo 41 This document is an Internet Draft. Internet Drafts are working 42 documents of the Internet Engineering Task Force (IETF), its 43 Areas, and its Working Groups. Note that other groups may also 44 distribute working documents as Internet Drafts. 46 Internet Drafts are draft documents valid for a maximum of six 47 months. Internet Drafts may be updated, replaced, or obsoleted by 48 other documents at any time. It is not appropriate to use Inter- 49 net Drafts as reference material or to cite them other than as a 50 "working draft" or "work in progress." 52 Please check the I-D abstract listing contained in each Internet 53 Draft directory to learn the current status of this or any other 54 Internet Draft. 56 This memo does not, in its draft form, specify a standard for the 57 Internet community. 59 2.0 Abstract 61 OSPF [1] is an event driven routing protocol, where an event can 62 be a change in an OSPF interface's link-level status, the expira- 63 tion of an OSPF timer or the reception of an OSPF protocol 64 packet. Many of the actions that OSPF takes as a result of these 65 events will result in a change of the routing topology. As rout- 66 ing topologies become large and complex it is often difficult to 67 locate the source of a topology change or unpredicted routing 68 path by polling a large number or routers. Another approach is 69 to notify a network manager of potentially critical OSPF events 70 with SNMP traps. 72 This draft document defines a set of traps, objects and mechan- 73 isms to enhance the ability to manage IP internetworks which use 74 OSPF as its IGP. It is meant as an extension to the OSPF MIB 75 [2]. 77 3.0 The Network Management Framework 79 The Internet-standard Network Management Framework consists of 80 three components. They are: 82 RFC 1155 [5] which defines the SMI, the mechanisms used for 83 describing and naming objects for the purpose of management. 84 RFC 1212 [8] defines a more concise description mechanism, 85 which is wholly consistent with the SMI. 87 RFC 1156 [6] which defines MIB-I, the core set of managed 88 objects for the Internet suite of protocols. RFC 1213 [9] 89 defines MIB-II, an evolution of MIB-I based on implementa- 90 tion experience and new operational requirements. 92 RFC 1157 [7] which defines the SNMP, the protocol used for 93 network access to managed objects. 95 The Framework permits new objects to be defined for the purpose 96 of experimentation and evaluation. 98 4.0 Objects 100 Managed objects are accessed via a virtual information store, 101 termed the Management Information Base or MIB. Objects in the MIB 102 are defined using the subset of Abstract Syntax Notation One 103 (ASN.1) [3] defined in the SMI. In particular, each object has a 104 name, a syntax, and an encoding. The name is an object identif- 105 ier, an administratively assigned name, which specifies an object 106 type. The object type together with an object instance serves to 107 uniquely identify a specific instantiation of the object. For 108 human convenience, we often use a textual string, termed the 109 OBJECT DESCRIPTOR, to also refer to the object type. 111 The syntax of an object type defines the abstract data structure 112 corresponding to that object type. The ASN.1 language is used 113 for this purpose. However, the SMI purposely restricts the ASN.1 114 constructs which may be used. These restrictions are explicitly 115 made for simplicity. 117 The encoding of an object type is simply how that object type is 118 represented using the object type's syntax. Implicitly tied to 119 the notion of an object type's syntax and encoding is how the 120 object type is represented when being transmitted on the network. 122 The SMI specifies the use of the basic encoding rules of ASN.1 123 [4], subject to the additional requirements imposed by the SNMP. 125 The SMI does not provide a means for defining traps. The SNMP, 126 however, does define a few standard traps and provides a means 127 for defining enterprise-specific traps. The TRAP-TYPE macro 128 defined in RFC 1215 [10] suggests a straight-forward approach 129 towards defining traps used with the SNMP. 131 4.1 Format of Definitions 133 Section 6 contains the specification of all object types con- 134 tained in this MIB module. The object types are defined using the 135 conventions defined in the SMI, as amended by the extensions 136 specified in RFC 1212. 138 Section 6.3 contains contains the trap definitions using the 139 TRAP-TYPE macro described in RFC 1215. 141 5.0 Approach 143 The mechanism for sending traps is straight-forward. When an 144 exception event occurs, the application notifies the local agent 145 who sends a trap to the appropriate SNMP management stations. 146 The message includes the trap type and may include a list of trap 147 specific variables. A new object is defined in section 6.2 that 148 will allow a network manager to enable or disable particular OSPF 149 traps. Section 6.3 gives the trap definitions which includes the 150 variable lists. The router ID of the originator of the trap is 151 included in the variable list so that the network manager may 152 easily determine the source of the trap. 154 To limit the frequency of OSPF traps, the following additional 155 mechanisms are suggested. 157 5.1 Ignoring Initial Activity 159 The majority of critical events occur when OSPF is enabled on a 160 router, at which time the designated router is elected and neigh- 161 bor adjacencies are formed. During this initial period a poten- 162 tial flood of traps is unnecessary since the events are expected. 163 To avoid unnecessary traps, a router should not originate 164 expected OSPF interface related traps until two of that 165 interface's dead timer intervals have elapsed. The expected OSPF 166 interface traps are ospfIfStateChange, ospfVirtIfStateChange, 167 ospfNbrStateChange, ospfVirtNbrStateChange, ospfTxRetranmit and 168 ospfVirtIfTxRetransmit. Additionally, ospfMaxAgeLsa and ospfOri- 169 ginateLsa traps should not be originated until two dead timer 170 intervals have elapsed where the dead timer interval used should 171 be the dead timer with the smallest value. 173 5.2 Throttling Traps 175 The mechanism for throttling the traps is similar to the mechan- 176 ism explained in RFC 1224 [11] section 5. The basic idea is that 177 there is a sliding window in seconds and an upper bound on the 178 number of traps that may be generated within this window. Unlike 179 RFC 1224, traps are not sent to inform the network manager that 180 the throttling mechanism has kicked in. 182 A single window should be used to throttle all OSPF traps types 183 except for the ospfLsdbOverflow and the ospfLsdbApproachingOver- 184 flow trap which should not be throttled. For example, if the 185 window time is 3, the upper bound is 3 and the events that would 186 cause trap types 1,3,5 and 7 occur within a 3 second period, the 187 type 7 trap should not be generated. 189 Appropriate values are 7 traps with a window time of 10 seconds. 191 5.3 One Trap Per OSPF Event 192 Several of the traps defined in section 6.3 are generated as the 193 result of finding an unusual condition while parsing an OSPF 194 packet or a processing a timer event. There may be more than one 195 unusual condition detected while handling the event. For exam- 196 ple, a link-state update packet may contain several retransmitted 197 link-state advertisements (LSAs), or a retransmitted database 198 description packet may contain several database description 199 entries. To limit the number of traps and variables, OSPF should 200 generate at most one trap per OSPF event. Only the variables 201 associated with the first unusual condition should be included 202 with the trap. Similarly, if more than one type of unusual con- 203 dition is encountered while parsing the packet, only the first 204 event will generate a trap. 206 5.4 Polling Event Counters 208 Many of the tables in the OSPF MIB contain generalized event 209 counters. By enabling the traps defined in this document a net- 210 work manager can obtain more specific information about these 211 events. A network manager may want to poll these event counters 212 and enable specific OSPF traps when a particular counter starts 213 increasing abnormally. 215 The following table shows the relationship between the event 216 counters defined in the OSPF MIB and the trap types defined in 217 section 6.3. 219 Counter Trap Type 220 ----------------------- ------------------------ 221 ospfOriginateNewLsas ospfOriginateLsa 222 ospfIfEvents ospfIfStateChange 223 ospfConfigError 224 ospfIfAuthFailure 225 ospfRxBadPacket 226 ospfTxRetransmit 227 ospfVirtIfEvents ospfVirtIfStateChange 228 ospfVirtIfConfigError 229 ospfVirtIfAuthFailure 230 ospfVirtIfRxBadPacket 231 ospfVirtIfTxRetransmit 232 ospfNbrEvents ospfNbrStateChange 233 ospfVirtNbrEvents ospfVirtNbrStateChange 234 ospfExtLsdbLimit ospfLsdbApproachingOverflow 235 ospfExtLsdbLimit ospfLsdbOverflow 237 6.0 OSPF Trap Definitions 239 6.1 Imports 241 RFCXXX-MIB DEFINITIONS ::= BEGIN 242 IMPORTS 243 IpAddress, OSPF 244 FROM RFC1155-SMI 245 OBJECT-TYPE 246 FROM RFC1212 247 TRAP-TYPE 248 FROM RFC1215 249 ospfRouterId, ospfIfIpAddress, ospfAddressLessIf, 250 ospfAreaId, ospfIfType, ospfIfState, ospfVirtAreaId, 251 ospfVirtIfNeighbor, ospfVirtIfState, ospfNbrIpAddr, 252 ospfNbrAddressLessIndex, ospfNbrRtrId, ospfNbrState, 253 ospfVirtNbrArea, ospfVirtNbrRtrId, ospfLsdbAreaId, 254 ospfLsdbType, ospfLsdbLsid, ospfLsdbRouterId, 255 ospfExtLsdbLimit 256 FROM RFC1253-OSPF MIB 258 6.2 Trap Support Objects 260 -- Trap Support Objects 262 ospfTrapGroup OBJECT IDENTIFIER ::= { ospf 14 } 264 ospfSetTrap OBJECT-TYPE 265 SYNTAX OCTET STRING 266 ACCESS read-write 267 STATUS mandatory 268 DESCRIPTION 269 "A four-octet string serving as a bit map for the 270 trap events defined by the OSPF traps. This object 271 is used to enable and disable specific OSPF traps 272 where a 1 in the bit field represents enabled. 273 The right-most bit (least significant) represents 274 trap 0." 275 ::= { ospfTrapGroup 1 } 277 ospfConfigErrorType OBJECT-TYPE 278 SYNTAX INTEGER { 279 badVersion (1), 280 areaMismatch (2), 281 unknownNbmaNbr (3), -- Router is Dr eligible 282 unknownVirtualNbr (4), 283 authTypeMismatch(5), 284 authFailure (6), 285 netMaskMismatch (7), 286 helloIntervalMismatch (8), 287 deadIntervalMismatch (9), 288 optionMismatch (10) } 290 ACCESS read-only 291 STATUS mandatory 292 DESCRIPTION 293 "Potential types of configuration conflicts. Used 294 by the ospfConfigError and ospfConfigVirtError 295 traps." 296 ::= { ospfTrapGroup 2 } 298 ospfPacketType OBJECT-TYPE 299 SYNTAX INTEGER { 300 hello (1), 301 dbDescript (2), 302 lsReq (3), 303 lsUpdate (4), 304 lsAck (5) } 305 ACCESS read-only 306 STATUS mandatory 307 DESCRIPTION 308 "OSPF packet types." 309 ::= { ospfTrapGroup 3 } 311 6.3 Traps 313 -- Traps 315 ospfIfStateChange TRAP-TYPE 316 ENTERPRISE ospf 317 VARIABLES { 318 ospfRouterId, -- The originator of the trap 319 ospfIfIpAddress, 320 ospfAddressLessIf, 321 ospfIfState } -- The new state 322 DESCRIPTION 323 "An ospfIfStateChange trap signifies that there has 324 been a change in the state of a non-virtual OSPF inter- 325 face. This trap should be generated when the interface 326 state regresses (e.g., goes from "Dr to "Down") or pro- 327 gress to a terminal state (i.e., Point-to-Point, DR 328 Other, Dr, or Backup)." 329 ::= 0 331 ospfVirtIfStateChange TRAP-TYPE 332 ENTERPRISE ospf 333 VARIABLES { 334 ospfRouterId, -- The originator of the trap 335 ospfVirtAreaId, 336 ospfVirtIfNeighbor, 337 ospfVirtIfState } -- The new state 338 DESCRIPTION 339 "An ospfIfStateChange trap signifies that there has 340 been a change in the state of an OSPF virtual 341 interface." This trap should be generated when the 342 interface state regresses (e.g., goes from "Point-to- 343 Point to "Down") or progress to a terminal state (i.e., 344 Point-to-Point)." 345 ::= 1 347 ospfNbrStateChange TRAP-TYPE 348 ENTERPRISE ospf 349 VARIABLES { 350 ospfRouterId, -- The originator of the trap 351 ospfNbrIpAddr, 352 ospfNbrAddressLessIndex, 353 ospfNbrRtrId, 354 ospfNbrState } -- The new state 355 DESCRIPTION 356 "An ospfNbrStateChange trap signifies that there has 357 been a change in the state of a non-virtual OSPF neigh- 358 bor. This trap should be generated when the neighbor 359 state regresses (e.g., goes from "Attempt" or "Full" to 360 "1-Way" or "Down") or progress to a terminal state 361 (e.g., "2-Way" or "Full"). When an neighbor transi- 362 tions from or to "Full" on non-broadcast multi-access 363 and broadcast networks, the trap should be generated by 364 the designated router. A designated router transition- 365 ing to "Down" will be noted by ospfIfStateChange." 366 ::= 2 368 ospfVirtNbrStateChange TRAP-TYPE 369 ENTERPRISE ospf 370 VARIABLES { 371 ospfRouterId, -- The originator of the trap 372 ospfVirtNbrArea, 373 ospfVirtNbrRtrId, 374 ospfVirtNbrState } -- The new state 375 DESCRIPTION 376 "An ospfIfStateChange trap signifies that there has 377 been a change in the state of an OSPF virtual neighbor. 378 This trap should be generated when the neighbor state 379 regresses (e.g., goes from "Attempt" or "Full" to "1- 380 Way" or "Down") or progress to a terminal state (e.g., 381 "Full")." 382 ::= 3 384 ospfIfConfigError TRAP-TYPE 385 ENTERPRISE ospf 386 VARIABLES { 387 ospfRouterId, -- The originator of the trap 388 ospfIfIpAddress, 389 ospfAddressLessIf, 390 IpAddress, -- The source IP address 391 ospfConfigErrorType, -- Type of error 392 ospfPacketType } 393 DESCRIPTION 394 "An ospfIfConfigError trap signifies that a packet has 395 been received on a non-virtual interface from a router 396 whose configuration parameters conflict with this 397 router's configuration parameters. Note that the event 398 optionMismatch should cause a trap only if it prevents 399 an adjacency from forming." 400 ::= 4 402 ospfVirtIfConfigError TRAP-TYPE 403 ENTERPRISE ospf 404 VARIABLES { 405 ospfRouterId, -- The originator of the trap 406 ospfVirtAreaId, 407 ospfVirtIfNeighbor, 408 ospfConfigErrorType, -- Type of error 409 ospfPacketType } 410 DESCRIPTION 411 "An ospfConfigError trap signifies that a packet has 412 been received on a virtual interface from a router 413 whose configuration parameters conflict with this 414 router's configuration parameters. Note that the event 415 optionMismatch should cause a trap only if it prevents 416 an adjacency from forming." 417 ::= 5 419 ospfIfAuthFailure TRAP-TYPE 420 ENTERPRISE ospf 421 VARIABLES { 422 ospfRouterId, -- The originator of the trap 423 ospfIfIpAddress, 424 ospfAddressLessIf, 425 IpAddress, -- The source IP address 426 ospfPacketType } 427 DESCRIPTION 428 "An ospfIfAuthFailure trap signifies that a packet has 429 been received on a non-virtual interface from a router 430 whose authentication key or authentication type con- 431 flicts with this router's authentication key or authen- 432 tication type." 433 ::= 6 435 ospfVirtIfAuthFailure TRAP-TYPE 436 ENTERPRISE ospf 437 VARIABLES { 438 ospfRouterId, -- The originator of the trap 439 ospfVirtAreaId, 440 ospfVirtIfNeighbor, 441 ospfConfigErrorType, -- Type of error 442 ospfPacketType } 444 DESCRIPTION 445 "An ospfVirtIfAuthFailure trap signifies that a packet 446 has been received on a virtual interface from a router 447 whose authentication key or authentication type con- 448 flicts with this router's authentication key or authen- 449 tication type." 450 ::= 7 452 ospfIfRxBadPacket TRAP-TYPE 453 ENTERPRISE ospf 454 VARIABLES { 455 ospfRouterId, -- The originator of the trap 456 ospfIfIpAddress, 457 ospfAddressLessIf, 458 IpAddress, -- The source IP address 459 ospfPacketType } 460 DESCRIPTION 461 "An ospfIfRxBadPacket trap signifies that an OSPF 462 packet has been received on a non-virtual interface 463 that cannot be parsed." 464 ::= 8 466 ospfVirtIfRxBadPacket TRAP-TYPE 467 ENTERPRISE ospf 468 VARIABLES { 469 ospfRouterId, -- The originator of the trap 470 ospfVirtAreaId, 471 ospfVirtIfNeighbor, 472 ospfPacketType } 473 DESCRIPTION 474 "An ospfRxBadPacket trap signifies that an OSPF packet 475 has been received on a virtual interface that cannot be 476 parsed." 477 ::= 9 479 ospfTxRetransmit TRAP-TYPE 480 ENTERPRISE ospf 481 VARIABLES { 482 ospfRouterId, -- The originator of the trap 483 ospfIfIpAddress, 484 ospfAddressLessIf, 485 ospfNbrRtrId, -- Destination 486 ospfPacketType } 487 DESCRIPTION 488 "An ospfTxRetransmit trap signifies than an OSPF packet 489 has been retransmitted on a non-virtual interface." 490 ::= 10 492 ospfVirtIfTxRetransmit TRAP-TYPE 493 ENTERPRISE ospf 494 VARIABLES { 495 ospfRouterId, -- The originator of the trap 496 ospfVirtAreaId, 497 ospfVirtIfNeighbor, 498 ospfPacketType } 499 DESCRIPTION 500 "An ospfTxRetransmit trap signifies than an OSPF packet 501 has been retransmitted on a virtual interface." 502 ::= 11 504 ospfOriginateLsa TRAP-TYPE 505 ENTERPRISE ospf 506 VARIABLES { 507 ospfRouterId, -- The originator of the trap 508 ospfLsdbAreaId, -- 0.0.0.0 for AS Externals 509 ospfLsdbType, 510 ospfLsdbLsid, 511 ospfLsdbRouterId } 512 DESCRIPTION 513 "An ospfOriginateLsa trap signifies that a new LSA has 514 been originated by this router. This trap should not 515 be invoked for simple refreshes of LSAs (which happesn 516 every 30 minutes), but instead will only be invoked 517 when an LSA is (re)originated due to a topology change. 518 Additionally, this trap does not include LSAs that are 519 being flushed because they have reached MaxAge." 520 ::= 12 522 ospfMaxAgeLsa TRAP-TYPE 523 ENTERPRISE ospf 524 VARIABLES { 525 ospfRouterId, -- The originator of the trap 526 ospfLsdbAreaId, -- 0.0.0.0 for AS Externals 527 ospfLsdbType, 528 ospfLsdbLsid, 529 ospfLsdbRouterId } 530 DESCRIPTION 531 "An ospfMaxAgeLsa trap signifies that one of the LSA in 532 the router's link-state database has aged to MaxAge." 533 ::= 13 535 ospfLsdbOverflow TRAP-TYPE 536 ENTERPRISE ospf 537 VARIABLES { 538 ospfRouterId, -- The originator of the trap 539 ospfExtLsdbLimit } 540 DESCRIPTION 541 "An ospfLsdbOverflow trap signifies that the number of 542 LSAs in the router's link-state database has exceeded 543 ospfExtLsdbLimit." 544 ::= 14 546 ospfLsdbApproachingOverflow TRAP-TYPE 547 ENTERPRISE ospf 548 VARIABLES { 549 ospfRouterId, -- The originator of the trap 550 ospfExtLsdbLimit } 551 DESCRIPTION 552 "An ospfLsdbApproachingOverflow trap signifies that the 553 number of LSAs in the router's link-state database has 554 exceeded ninety percent of ospfExtLsdbLimit." 555 ::= 15 556 END 558 7.0 Acknowledgements 560 This document was produced by the OSPF Working Group, chaired by 561 John Moy. 563 In addition, the comments of the following individuals are also 564 acknowledged: 565 Dino Farinacci cisco 566 Vince Fuller BARRNet 567 Stan Froyd ACC 568 Dean Morris Digital Equipment Corp. 569 John Moy Proteon, Inc. 571 8.0 References 573 [1] J. Moy, The OSPF Specification, Version 2 Internet 574 Draft, Internet Engineering Task Force, (November, 1992). 576 [2] F. Baker and R. Coltun, OSPF Version 2 Management 577 Information Base Internet Draft, Internet Engineering 578 Task Force, (November 1992) 580 [3] Information processing systems - Open Systems 581 Interconnection - Specification of Abstract Syntax 582 Notation One (ASN.1), International Organization for 583 Standardization. International Standard 8824, (December, 584 1987). 586 [4] Information processing systems - Open Systems 587 Interconnection - Specification of Basic Encoding Rules 588 for Abstract Notation One (ASN.1), International 589 Organization for Standardization. International Standard 590 8825, (December, 1987). 592 [5] M.T. Rose and K. McCloghrie, Structure and Identification 593 of Management Information for TCP/IP-based internets, 594 Internet Working Group Request for Comments 1155. 595 Network Information Center, SRI International, Menlo 596 Park, California, (May, 1990). 598 [6] K. McCloghrie and M.T. Rose, Management Information Base 599 for Network Management of TCP/IP-based internets, 600 Internet Working Group Request for Comments 1156. 601 Network Information Center, SRI International, Menlo 602 Park, California, (May, 1990). 604 [7] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 605 Simple Network Management Protocol, Internet Working 606 Group Request for Comments 1157. Network Information 607 Center, SRI International, Menlo Park, California, (May, 608 1990). 610 [8] Rose, M.T.; McCloghrie, K.,eds. Concise MIB definitions. 611 Internet Request for Comments 1212. Network Information 612 Center, SRI International, Menlo Park, California, (1991 March). 614 [9] M.T. Rose (editor), Management Information Base for 615 Network Management of TCP/IP-based internets, Internet 616 Working Group Request for Comments 1213. Network 617 Information Center, SRI International, Menlo Park, 618 California, (May, 1990). 620 [10] M.T. Rose, A Convention for Defining Traps for 621 use with the SNMP, Internet Request for Comments 622 1215. Network Information Center, SRI International, 623 Menlo Park, California, (March, 1991). 625 [11] L. Steinberg, Techniques for Managing Asynchronously 626 Generated Alerts. Internet Request for Comments 1224. 627 Network Information Center, SRI International, Menlo Park, 628 California, (May, 1991).