rfc-1587

The OSPF NSSA Option

R. Coltun, V. Fuller
date1994-03 streamIETF areartg wgospf statusPROPOSED STANDARD pages17 canonicalhttps://www.rfc-editor.org/rfc/rfc1587 doi10.17487/RFC1587
This document describes a new optional type of OSPF area, somewhat humorously referred to as a "not-so-stubby" area (or NSSA). NSSAs are similar to the existing OSPF stub area configuration option but have the additional capability of importing AS external routes in a limited fashion. [STANDARDS-TRACK]

obsoleted by

Extracted elements (25)

design-rationale §2.1

OSPF stub areas cannot import external routes, which prevents leaf sites (e.g., a cloud running RIP-learned routes) from participating as stub areas. The NSSA option was created to allow limited import of AS external routes via a new LSA type (type-7) while retaining the benefits of stub area topology.

routing

design-rationale §3.4

Summary routes are required in NSSAs (unlike stub areas where they are optional) to ensure OSPF internal routes always take precedence over type-7 external routes. Injecting a default as a type-3 summary would also cause it to be preferred over all more specific type-7 routes, breaking routing.

routing

design-rationale §3.3

The forwarding address is required in type-7 LSAs (unlike being optional in type-5) to enable efficient routing when multiple NSSA border routers exist: packets can be forwarded directly to the ASBR rather than through the translating border router, and the ABR does not need to recompute it during translation.

routing

design-rationale §3.4

The P-bit enables loop avoidance: when an NSSA area border router originates both a type-5 and a type-7 LSA for the same network, it resets the P-bit in the type-7 LSA so another border router will not translate it again, preventing duplicate type-5 LSAs with conflicting forwarding addresses from entering the backbone.

routing

interoperability-note §3.3

Type-5 and type-7 external metrics and path types are directly comparable. The same comparison rules used for type-5 routes (type-1 vs. type-2 metric comparison, forwarding address lookup) apply when comparing type-7 routes against each other or against type-5 routes.

routing

normative-requirement §3.4 MUST

A type-7 default route (0.0.0.0) originated by an NSSA area border router must have the P-bit reset so it is not re-translated and propagated outside the NSSA by another border router. A default route must not be injected into the NSSA as a type-3 summary LSA.

routing

normative-requirement §3.4 MUST

NSSA area border routers must set both the E-bit (external capability) and B-bit (border router) in their type-1 router LSAs, in both the backbone and the NSSA area, because they must be capable of translating type-7 LSAs to type-5 LSAs.

routing

normative-requirement §4.1 MUST

Only type-7 LSAs with the P-bit set and a non-zero forwarding address are eligible for translation to type-5. Translation is skipped if the route falls within a DoNotAdvertise address range. If no configured range matches, a direct type-7-to-type-5 translation occurs by default.

routing

normative-requirement §4.1 MUST

The NSSA area border router with the highest router ID among all reachable area border routers in the NSSA is designated as the sole translator of type-7 LSAs into type-5 LSAs. Other area border routers must skip the translation algorithm.

routing

normative-requirement §3.1 MUST NOT

Two OSPF routers will not form an adjacency unless they agree on the state of the N-bit. The Hello packet processing function must verify that both the N-bit and E-bit in the received Hello match the configured values on the receiving interface.

routing

normative-requirement §3.3 MUST NOT

Type-7 LSAs are flooded only within the NSSA; they follow the same flooding rules as type 1-4 LSAs and are not flooded into the backbone or any other area by border routers.

routing

normative-requirement §3.3 MUST

Type-7 LSAs that are to be translated into type-5 LSAs must have their forwarding address set to a non-zero value. The forwarding address should be the next-hop address if the intervening network is advertised into OSPF as an internal route; otherwise it should be any active OSPF interface address of the originating router.

routing

normative-requirement §3.4 MUST

Unlike stub areas (where it is optional), all OSPF summary routes (type-3 LSAs) must be imported into an NSSA. This ensures that OSPF internal routes are always chosen over OSPF external (type-7) routes.

routing

normative-requirement §4.2 MUST

When a translated type-5 LSA should no longer be advertised (because the routing table entry became unreachable or the associated LSA no longer has the P-bit set with a non-zero forwarding address), the NSSA area border router must flush the type-5 LSA by setting it to MaxAge and flooding it.

routing

normative-requirement §3.5 SHOULD

When a type-5 and type-7 LSA have the same type and equal distance, tie-breaking priority (highest to lowest) is: (a) any type-5 LSA, (b) a type-7 LSA with P-bit set and non-zero forwarding address, (c) any other type-7 LSA.

routing

normative-requirement §3.4 MUST

When an NSSA internal AS boundary router originates a type-7 LSA intended for translation, it must set the P-bit and include a valid forwarding address. If a router is simultaneously an NSSA area border router and an ASBR, it must reset the P-bit in the type-7 LSA to prevent re-translation by another border router.

routing

normative-requirement §3.1 MUST

When the N-bit is set in an interface's options field, the E-bit must be cleared. A mismatch between the N-bit or E-bit in a received Hello packet and the locally configured values causes the Hello to be dropped and no adjacency to form.

routing

normative-requirement §4.1 SHOULD

When translating type-7 routes subsumed by an address range to a type-5 LSA: if path type is external type-2, the type-5 metric is set to the largest type-7 metric within the range plus 1; if path type is external type-1, it is set to the largest metric. The highest path type among subsumed routes is used for the type-5 LSA.

routing

protocol-element §3.1

The N-bit is a new option bit in the OSPF options field that identifies a router's NSSA capability. It is used only in Hello packets and ensures all members of an NSSA agree on the area's configuration. If the N-bit is set, the E-bit must be cleared.

routing

protocol-element §Appendix B

The P-bit (propagate bit) appears in the options field of the Type-7 LSA header. It signals the NSSA area border router to translate the type-7 LSA into a type-5 LSA for flooding into the backbone. It is not used in Hello or Database Description packets.

routing

protocol-element §3.2

Type-7 address ranges allow NSSA area border routers to summarize multiple type-7 routes into a single type-5 LSA. Each range is defined by an [address, mask] pair, a status of Advertise or DoNotAdvertise, and an external route tag. Route aggregation follows rules for metric and path type selection across the subsumed type-7 routes.

routing

protocol-element §3.3

Type-7 LSAs (NSSA External Link-State Advertisements) carry external route information within an NSSA. They are structurally identical to type-5 LSAs except the LSA header type field is 7, they are area-scoped (flooded only within the NSSA), and they include a P-bit in the options field to flag translation to type-5.

routing

security-consideration §7.0

RFC 1587 explicitly states that security issues are not discussed in this memo. No authentication or integrity mechanisms specific to type-7 LSAs or the NSSA option are defined.

security, routing

state-machine §3.5

Type-7 route calculation proceeds after type-5 route calculation (step 5 of OSPF chapter 16). For each type-7 LSA: skip if metric is LSInfinity, age equals MaxAge, or advertising router is self; skip if ASBR is unreachable; skip default routes between two NSSA ABRs; otherwise compute cost X to forwarding address and advertised cost Y, then compare against existing routing table entries using type-5/type-7 tie-breaking rules.

routing

wire-format §Appendix A

The Type-7 LSA packet contains: a standard Link-State Header (with Options byte set to 7 in the type field), a 32-bit Network Mask, one or more TOS blocks each containing E-bit, TOS, and metric fields, a 32-bit Forwarding Address, and a 32-bit External Route Tag. Format is identical to type-5 except for the LSA type field.

routing