OSPF Database Overflow
RFC 1765
|
| Document |
Type |
|
RFC - Experimental
(March 1995; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 1765 (Experimental)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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, unexpected database overflows cannot be handled in the above
manner. This memo describes a way of dynamically limiting database
size under overflow conditions. The basic mechanism is as follows:
(1) A parameter, ospfExtLsdbLimit, is configured in each router
indicating the maximum number of AS-external-LSAs (excluding
those describing the default route) that are allowed in the
link-state database. This parameter must be the same in all
routers in the routing domain (see Section 2.1); synchronization
of the parameter is achieved via network management.
(2) In any router's database, the number of AS-external-LSAs
(excluding default) is never allowed to exceed ospfExtLsdbLimit.
If a router receives a non-default AS-external-LSA that would
cause the limit of ospfExtLsdbLimit to be exceeded, it drops the
LSA and does NOT acknowledge it.
(3) If the number of non-default AS-external-LSAs in a router's
database hits ospfExtLsdbLimit, the router a) flushes all non-
default AS-external-LSAs that it has itself originated (see
Section 2.2) and b) goes into "OverflowState".
(4) While in OverflowState, the router refuses to originate any
non-default AS-external-LSAs (see Section 2.3.2).
Show full document text