Browse Prior Art Database

OSPF Database Overflow (RFC1765)

IP.com Disclosure Number: IPCOM000004016D
Original Publication Date: 1995-Mar-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 9 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Moy: AUTHOR

Related Documents

10.17487/RFC1765: DOI

Abstract

This memo details a way of gracefully handling unanticipated database overflows. This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% of the total text.

Network Working Group J. Moy Request for Comments: 1765 Cascade Category: Experimental March 1995

OSPF Database Overflow

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

Abstract

Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. This memo details a way of gracefully handling unanticipated database overflows.

This memo is a product of the OSPF Working Group. Please send comments to ospf@gated.cornell.edu.

Table of Contents

1. Overview ............................................... 2 2. Implementation details ................................. 3 2.1 Configuration .......................................... 3 2.2 Entering OverflowState ................................. 4 2.3 Operation while in OverflowState ....................... 5 2.3.1 Modifications to Flooding .............................. 5 2.3.2 Originating AS-external-LSAs ........................... 6 2.3.3 Receiving self-originated LSAs ......................... 6 2.4 Leaving OverflowState .................................. 6 3. An example ............................................. 6 4. Administrative response to database overflow ........... 7 5. Operational experience ................................. 8 6. Possible enhancements .................................. 8 A. Related MIB parameters ................................ 8 References ............................................ 9 Security Considerations ............................... 9 Author’s Address ...................................... 9

Moy [Page 1]

RFC 1765 OSPF Database Overflow March 1995

1. Overview

OSPF requires that all OSPF routers within a single area maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". For example, a regional network may have a very large OSPF database because it is importing a large number of external routes into OSPF. Unless database overflow is handled correctly, routers will end up with inconsistent views of the network, possibly leading to incorrect routing.

One way of handling database overflow is to encase routers having limited resources within OSPF stub areas (see Section 3.6 of [1]) or NSSAs ([2]). AS-external-LSAs are omitted from these areas’ link- state databases, thereby controlling database size.

However...

Processing...
Loading...