OSPF Database Overflow
RFC 1765

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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).

    (5) Optionally, the router can attempt to leave OverflowState after
        the configurable parameter ospfExitOverflowInterval has elapsed
        since entering OverflowState (see Section 2.4). Only at this