Introduction to OSPF

Previous Table of Contents Next


RFC 1587: The OSPF NSSA Option

This RFC provides a description of a new type of optional OSPF area, the “not-so-stubby” area or NSSA. This optional stubby area is very similar in operation to the existing stubby areas, but it has the additional ability to import external OSPF routes from the Autonomous System to which it belongs.


Notes:  
Importing external OSPF routes will be covered later in this section.

This RFC is very good reading and its authors should be commended for bringing some of the real world into their discussion on the “not-so-stubby” area discussion. This RFC details a problem seen with the implementation of OSPF at the time of its writing. They provide a very good scenario and supporting documentation about the issue this RFC addresses.

Within this RFC, the authors propose adding a new option bit, referred to as the “N” bit and a new type of LSA area definition. This new “N” bit would assist in identifying routers that belong to a NSSA and allow them to agree upon the area’s topology. The new LSA would allow for external route information to be exchanged within the area.

Discussion is provided on the new LSA and how it compares to existing LSAs and how the new LSA will operate. The need for NSSA area border routers to have a default route is also discussed and justified.

I would recommend reading more about this RFC because it provides a very good insight into how the OSPF protocol has matured and responded to the needs of its users. To assist the reader in clarifying that point, the following excerpt is provided from the RFC itself.

Why Was a “Not-So-Stubby” Area Needed?

“Wide-area transit networks (such as the NSFNET regionals) often have connections to moderately-complex “leaf” sites. A leaf site may have multiple IP network numbers assigned to it.

Typically, one of the leaf site’s networks is directly connected to a router provided and administered by the transit network while the others are distributed throughout and administered by the site. From the transit network’s perspective, all of the network numbers associated with the site make up a single “stub” entity. For example, BARRNet has one site composed of a class-B network, 130.57.0.0, and a class-C network, 192.31.114.0. From BARRNet’s perspective, this configuration looks something like Figure 4-2


Figure 4-2  The BARRNet wide-area transit network.

The “cloud” consists of the subnets of 130.57 and network 192.31.114, all of which are learned by RIP on router BR18. Topologically, this cloud looks very much like an OSPF stub area. The advantages of running the cloud as an OSPF stub area are:

1.  Type-5 routes (OSPF external link-state advertisements (LSAs)) are not advertised beyond the router labeled “BR10”. This is advantageous because the link between BR10 and BR18 may be a low-speed link or the router BR18 may have limited resources.
2.  The transit network is abstracted to the “leaf” router BR18 by advertising only a default route across the link between BR10 and BR18.
3.  The cloud becomes a single, manageable “leaf” with respect to the transit network.
4.  The cloud can become, logically, a part of the transit network’s OSPF routing system.
5.  Translated type-5 LSAs that are sent into the backbone from the cloud (which is a separate stub area) may be considered “leaf” nodes when performing the Dijkstra calculation.

However, the current definition of the OSPF protocol [1] imposes topological limitations which restrict simple cloud topologies from becoming OSPF stub areas. In particular, it is illegal for a stub area to import routes external to OSPF; it is not possible for routers BR18 and BR10 to both be members of the stub area and to import the routes learned from RIP or other IP routing protocols as type-5 (OSPF external LSAs) into the OSPF system. In order to run OSPF out to BR18, BR18 must be a member of a non-stub area or the OSPF backbone to import routes other than its directly-connected network(s). Since it is not acceptable for BR18 to maintain all of BARRNet’s external (type-5) routes, BARRNet is forced by OSPF’s topological limitations to run OSPF out to BR10 and to run RIP between BR18 and BR10.”

RFC 1745: BGP4/IDRP for IP-OSPF Interaction

This RFC has been included in this list in order to be as complete as possible, thereby helping the reader understand and be able to reference all the many sources of information available to them on OSPF.

This RFC provides the technical information necessary to design and deploy a network or implement an Autonomous System Border Router (ASBR) that will be running Border Gateway Protocol (BGP4) or Inter-Domain Routing Protocol (IDRP) for IP as your Exterior Gateway Protocol (EGP) with OSPF as your Interior Gateway Protocol (IGP). This document details the settings necessary between the fields and attributes of OSPF and the other protocols. BGP4 is referenced in RFC 1654.

RFC 1765: OSPF Database Overflow

This RFC deals with an undesirable occurrence known as OSPF Database Overflow. For OSPF to operate properly, a complete link-state database must be within each OSPF router in an area. The condition known as “database overflow” occurs when this link-state database becomes too large for the router to handle. This RFC allows for the handling on unanticipated overflows and gives some recommendations on how to configure your network if you are anticipating database overflow.

One way of handling database overflow is to encase routers having limited resources within OSPF stub areas or NSSAs. 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 RFC describes a way of dynamically limiting database size under overflow conditions.

The method used to recover from unexpected database overflow is discussed in great detail and if you are interested or believe you are experiencing this condition, then consult the RFC.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net