RFC 1587

The OSPF NSSA Option

📅 published March 1994, from ietf

RFC 1587: The OSPF NSSA Option 🎀

Okay bestie, this is RFC 1587, "The OSPF NSSA Option" 💖. It came out of the Network Working Group 🌈 and was written by R. Coltun of RainbowBridge Communications and V. Fuller of Stanford University 💜. It's a Standards Track document dated March 1994, and the title block doesn't list any RFCs it obsoletes or updates 👑.

Status of this Memo 💅

Okay so this doc is a standards track protocol spec for the whole Internet community, and it's literally asking everyone to chat about it and send in ideas for making it better 💬. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖. And distribution of this memo is unlimited, so share away 🦋.

Table Of Contents 📑

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Motivation ...............................................  2
   2.2 Proposed Solution ........................................  3
   3.0 Implementation Details ...................................  5
   3.1 The N-bit ................................................  5
   3.2 Type-7 Address Ranges ....................................  5
   3.3 Type-7 LSAs ..............................................  5
   3.4 Originating Type-7 LSAs ..................................  7
   3.5 Calculating Type-7 AS External Routes ....................  8
   3.6 Incremental Updates ...................................... 10
   4.0 Originating Type-5 LSAs .................................. 10
   4.1 Translating Type-7 LSAs .................................. 10
   4.2 Flushing Translated Type-7 LSAs .......................... 13
   5.0 Acknowledgements ......................................... 13
   6.0 References ............................................... 13
   7.0 Security Considerations .................................. 13
   8.0 Authors' Addresses ....................................... 14
   Appendix A: Type-7 LSA Packet Format ......................... 15
   Appendix B: The Options Field ................................ 16
   Appendix C: Configuration Parameters ......................... 17

1.0 Abstract ✨

Okay so this doc introduces a brand new optional kind of OSPF area, which people lovingly call a "not-so-stubby" area (or NSSA) 🦋. It's giving stub area vibes, but with a twist. NSSAs are basically like the existing OSPF stub area option, except they can also import AS external routes, just in a limited way 💅.

2.0 Overview 🌸

2.1 Motivation 🍃

Picture wide-area transit networks (like the NSFNET regionals 🌐). They're often connected to moderately-complex "leaf" sites, and a leaf site might have several IP network numbers assigned to it.

Usually one of the leaf site's networks is directly plugged into a router that the transit network provides and runs, while the rest are spread out around the site and managed by the site itself 🏠. From the transit network's point of view, every network number tied to that site counts as one single "stub" entity 🧸. For example, BARRNet has one site made up of a class-B network, 130.57.0.0, and a class-C network, 192.31.114.0. From BARRNet's perspective, the setup looks a bit like this:

                    192.31.114
                        |
                      (cloud)
                  -------------- 130.57.4
                        |
                        |
                     ------ 131.119.13 ------
                     |BR18|------------|BR10|
                     ------            ------
                                          |
                                          V
                                  to BARRNet "core" OSPF system

where the "cloud" is made up of the subnets of 130.57 and the network 192.31.114, and BR18 learns all of them through RIP 🛰️. Topology-wise, that cloud looks super similar to an OSPF stub area 🤭. Running the cloud as an OSPF stub area has these perks:

  1. Type-5 routes (OSPF external link-state advertisements (LSAs)) don't get advertised past the router labeled "BR10" 🙅. That's a big win because the link between BR10 and BR18 might be low-speed, or BR18 might be running on limited resources 🐢.
  2. The transit network gets abstracted down to the "leaf" router BR18, since only a default route gets advertised across the link between BR10 and BR18 🎀.
  3. The cloud turns into one single, manageable "leaf" as far as the transit network is concerned 🧁.
  4. Logically, the cloud can become part of the transit network's OSPF routing system 🧩.
  5. Translated type-5 LSAs sent into the backbone from the cloud (which is its own separate stub area) may be treated as "leaf" nodes when doing the Dijkstra calculation 🧮.

But here's the catch 😤: the current OSPF protocol definition [1] has topological limits that stop simple cloud topologies from becoming OSPF stub areas. Specifically, it's straight-up illegal for a stub area to import routes external to OSPF 🚫. That means routers BR18 and BR10 can't both be in the stub area and also pull the routes learned from RIP or other IP routing protocols into the OSPF system as type-5 (OSPF external LSAs). To run OSPF out to BR18, BR18 must be a member of a non-stub area or the OSPF backbone so it can import routes other than its directly-connected network(s). And since it's not acceptable for BR18 to keep all of BARRNet's external (type-5) routes, OSPF's topological limits force BARRNet to run OSPF out to BR10 and run RIP between BR18 and BR10 🥲.

2.2 Proposed Solution 💖

So yeah, this doc describes that new optional OSPF area again, the "not-so-stubby" one (NSSA for short) 💖, which can import external routes in a limited way.

The OSPF specification defines two general classes of area configuration. The first allows type-5 LSAs to be flooded throughout the area. In this configuration, type-5 LSAs may be originated by routers internal to the area or flooded into the area by area border routers. These areas, referred to herein as type-5 capable areas (or just plain areas in the OSPF spec), are distinguished by the fact that they can carry transit traffic. The backbone is always a type-5 capable area. The second type of area configuration, called stub, doesn't let any type-5 LSAs propagate into or throughout the area, and instead it depends on default routing to reach external destinations 🧭.

NSSAs are defined in much the same way as existing stub areas 🪞. To support NSSAs, a new option bit (the "N" bit) and a new type of LSA (type-7) get defined 🌟. The "N" bit makes sure that routers belonging to an NSSA agree on its configuration. Just like the stub area's use of the "E" bit, both NSSA neighbors must agree on the setting of the "N" bit, or the OSPF neighbor adjacency won't form 🙅‍♀️.

Type-7 LSAs carry external route information within an NSSA 📦. Type-7 AS External LSAs have virtually the same syntax as Type-5 AS External LSAs, with the obvious exception of the link-state type (see section 3.2 for more details). There are two major semantic differences between type-5 and type-7 LSAs:

  • Type-7 LSAs may be originated by and advertised throughout an NSSA. As with stub areas, NSSA's do not receive or originate type-5 LSAs 🙅.
  • Type-7 LSAs are advertised only within a single NSSA. They are not flooded into the backbone area or any other area by border routers, though the information they contain can be propagated into the backbone area (see section 3.6) 🫶.

To allow limited exchange of external information across an NSSA area border, NSSA border routers will translate selected type-7 LSAs received from the NSSA into type-5 LSAs 🔁. These type-5 LSAs will be flooded to all type-5 capable areas. NSSA area border routers may be configured with address ranges so that several type-7 LSAs may be represented by a single type-5 LSA 🧩.

On top of that, an NSSA area border router can originate a default type-7 LSA (IP address of 0.0.0.0) into the NSSA 🌈. Default routes are necessary because NSSAs don't receive full routing information, so they must have a default route to reach AS-external destinations 🗺️. Like stub areas, NSSAs may be connected to the backbone at more than one area border router, but they may not be used as a transit area. Note that the default route originated by an NSSA area border router is never translated into a type-5 LSA. However, a default route originated by an NSSA internal AS boundary router (one that is not also an area border router) may be translated into a type-5 LSA 🤓.

It should also be noted that, unlike stub areas, all OSPF summary routes (type-3 LSAs) must be imported into NSSAs. This makes sure that OSPF internal routes are always chosen over OSPF external (type-7) routes 👑.

In our example topology, the subnets of 130.57 and the network 192.31.114 will still be learned by RIP on router BR18. But now both BR10 and BR18 can be in an NSSA, and all of BARRNet's external routes are hidden from BR18 🙈. BR10 becomes an NSSA area border router, and BR18 becomes an AS boundary router internal to the NSSA. BR18 imports the subnets of 130.57 and the network 192.31.114 as type-7 LSAs into the NSSA. Then BR10 translates these routes into type-5 LSAs and floods them into BARRNet's backbone 🚀.

3.0 Implementation Details 🔧

3.1 The N-bit 🪄

The N-bit makes sure that all members of an NSSA agree on the area's configuration 🤝. Together, the N-bit and E-bit reflect an interface's (and, as a result, the interface's associated area's) external LSA flooding capability. As explained in section 10.5 of the OSPF specification, if type-5 LSAs are not flooded into or throughout the area, the E-bit must be clear in the option field of the received Hello packets. Interfaces associated with an NSSA won't send or receive type-5 LSAs on that interface, but they may send and receive type-7 LSAs. So if the N-bit is set in the options field, the E-bit must be cleared 💜.

To support the NSSA option, an additional check must be made in the function that handles receiving Hello packets. It has to verify that both the N-bit and the E-bit found in the Hello packet's option field match the values of the options configured on the receiving interface 🔍. A mismatch means processing of the received Hello packet stops and the packet gets dropped 🗑️.

3.2 Type-7 Address Ranges 🌷

NSSA area border routers may be configured with type-7 address ranges 🌷. Each address range is defined as an [address,mask] pair. Many separate type-7 networks may then be represented by a single address range (as advertised by a type-5 LSA), just like a subnetted network is made up of many separate subnets 🍰. Area border routers can then summarize type-7 routes by advertising a single type-5 route for each type-7 address range. The type-5 route that results from a type-7 address range match will be distributed to all type-5 capable areas. Section 4.1 gives the details of generating type-5 routes from type-7 address ranges 📚.

A type-7 address range includes the following configurable items:

  • An [address,mask] pair.
  • A status indication of either Advertise or DoNotAdvertise.
  • External route tag.

Okay so this is where the external routes actually come in 💖. External routes get imported into NSSAs as type-7 LSAs, and the NSSA's AS boundary routers are the ones doing it. Quick reminder: an NSSA AS boundary router is a router with an interface tied to the NSSA that's swapping routing info with routers in another AS 🌸. Just like type-5 LSAs, you get one separate type-7 LSA for every destination network (so organized, I'm obsessed 💅). That means the link-state database must be expanded to hold type-7 LSAs too, because that's what makes NSSA areas work 🧚.

Type-7 LSAs are basically type-5 LSAs with a few plot twists. If you want the full lore, check section 12.3.4 "AS external links" in the OSPF specification. Here's the tea 🫖:

  1. The type field in the LSA header is 7.
  2. Type-7 LSAs only get flooded inside the NSSA. They follow the exact same flooding rules as type 1-4 LSAs 🫶.
  3. Type-7 LSAs live in the NSSA's LSDB, so they're area specific. Type-5 LSAs are flooded to every type-5 capable area, so they have global scope in the router's LSDB 🌍.
  4. At the area border router, selected type-7 LSAs get translated into type-5 LSAs and then flooded into the backbone 🦋.
  5. Type-7 LSAs have a propagate (P-bit) bit. It's the signal telling the area border router "yo, translate this one into a type-5 LSA." The examples of how the P-bit helps with loop avoidance are in the sections that follow 🔁.
  6. Type-7 LSAs that are going to be translated into type-5 LSAs must have their forwarding address set. Most type-5 LSAs translated from type-7 LSAs must also contain a forwarding address. The one exception is when the translation happens because of an address range match. Then the type-5 LSA won't carry a forwarding address (see section 4.1 for details) 🙈.

Why does the forwarding address matter so much? When there are multiple NSSA area border routers, a forwarding address in the type-5 LSA means more efficient routing to the AS external networks ✨. And if the type-7 LSA already has it, the translation is way easier, because the NSSA area border router doesn't have to figure out the forwarding address by itself 💅.

If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route, the forwarding address should be the next hop address, same as what's already done in type-5 LSAs. But unlike type-5 LSAs, if that intervening network is not advertised into OSPF as an internal OSPF route, the forwarding address should be any one of the router's active OSPF interface addresses 🌈.

Type-5 and type-7 metrics and path types are directly comparable 💜.

3.4 Originating Type-7 LSAs 🎀

NSSA AS boundary routers may originate type-7 LSAs. All NSSA area border routers must also be AS boundary routers, since every single one of them needs to be able to translate a type-7 LSA into a type-5 LSA (check section 3.6 for the translation algorithm 🧠). NSSA area border routers must set the E-bit (external bit) as well as the B-bit (border bit) in their router (type-1) LSAs, both in the backbone and in the NSSA area 👑.

When an NSSA internal AS boundary router originates a type-7 LSA that it wants translated into a type-5 LSA by the NSSA area border router (and then flooded into the backbone), it must set the P-bit in the option field of the LS header and add a valid forwarding address to the type-7 LSA 🦋.

If a router is attached to another AS and is also an NSSA area border router, it may originate both a type-5 and a type-7 LSA for the same network. The type-5 LSA gets flooded to the backbone (and all attached type-5 capable areas), and the type-7 LSA gets flooded into the NSSA. When that's the case, the P-bit must be reset in the type-7 LSA so that another NSSA area border router doesn't translate it into a type-5 LSA again 🔒.

A type-7 default route (network 0.0.0.0) may be originated into the NSSA by an NSSA area border router, or by an NSSA AS boundary router that's internal to the NSSA 🌸. The type-7 default route originated by the NSSA area border router must have the P-bit reset, so that the default route it originates won't find its way out of the NSSA and into the rest of the AS through another NSSA area border router. The type-7 default route originated by an NSSA AS boundary router that isn't an NSSA area border router may have the P-bit set. Type-7 routes originated by an NSSA area border router won't get added to other NSSA area border routers' routing tables 🙅‍♀️.

A default route must not be injected into the NSSA as a summary (type-3) LSA, even though that's how it's done in stub areas. The reason is that the preferred summary default route would beat out all the more specific type-7 routes 😭. Summary routes are preferred over external routes, so to make sure summary routes get chosen over external ones within the NSSA, all summary routes must be imported into an NSSA. (Unlike stub areas, where that part is optional 💀.)

3.5 Calculating Type-7 AS External Routes 🧮

This section is very similar to section 16.4 (Calculating AS external routes) in the OSPF specification 👯. An NSSA area border router should examine both type-5 LSAs and type-7 LSAs whenever either type-5 or type-7 routes need updating, and the type-7 LSAs should be examined after the type-5 LSAs. An NSSA internal router should examine type-7 LSAs whenever its type-7 routes need recalculating.

When it comes to the routing table calculation steps in the OSPF specification (chapter 16, "Calculation of the Routing Table"), type-7 LSAs should be examined after step 5, which is where the routes to external destinations get calculated 📋.

Type-7 routes are calculated by examining type-7 LSAs, one at a time. Most type-7 LSAs describe routes to specific IP destinations, but a type-7 LSA can also describe a default route for the NSSA (destination = DefaultDestination). For each type-7 LSA:

  1. If the metric specified by the LSA is LSInfinity, if the age of the LSA equals MaxAge, or if the advertising router field equals this router's router ID, skip it and check the next advertisement 🙅‍♀️.
  2. Call the destination described by the LSA N. Look up the routing table entry for the AS boundary router (ASBR) that originated the LSA. If there's no entry for the ASBR (meaning the ASBR is unreachable), do nothing with this LSA and move on to the next one 🚫.

If the destination is the default route (destination = DefaultDestination) and both the originator of the LSA and the calculating router are NSSA area border routers, do nothing with this LSA and move on to the next one 💅.

Otherwise, this LSA describes an AS external path to destination N. If the forwarding address (from the forwarding address field of the LSA) is 0.0.0.0, the packets routed to external destination N will be routed to the originating ASBR. If the forwarding address is not 0.0.0.0, look up the forwarding address in the routing table. Packets routed to external destination N will then be routed within the NSSA to this forwarding address, so an intra-area path must exist to it. If no such path exists, do nothing with the LSA and move on to the next one 🛣️.

Call the routing table distance to the forwarding address (or the distance to the originating ASBR if the forwarding address is 0.0.0.0) X, and the cost specified in the type-7 LSA Y. X is in terms of the link-state metric, and Y is a Type-1 or Type-2 external metric 🔢.

  1. Now look up the routing table entry for destination N. If no entries exist for N, install the AS external path to N, with the next hop equal to the list of next hops to the forwarding address/ASBR, and the advertising router equal to the ASBR ✨. If the external metric type is 1, the path-type is set to Type-1 external and the cost is equal to X + Y. If the external metric type is 2, the path-type is set to Type-2 external, the link-state component of the route's cost is X, and the Type-2 cost is Y 💖.
  2. Else, if the paths present in the table are not Type-1 or Type-2 external paths, do nothing. AS external paths have the lowest priority, so they just get bumped 🫠.
  3. Otherwise, compare the cost of this new AS external path to the ones already in the table. Type-5 and type-7 routes are directly comparable. Type-1 external paths are always shorter than Type-2 external paths. Type-1 external paths get compared by looking at the sum of the distance to the forwarding address/ASBR and the advertised Type-1 paths (X+Y). Type-2 external paths get compared by looking at the advertised Type-2 metrics, and then, if necessary, the distance to the forwarding address/ASBR 📊.

When a type-5 LSA and a type-7 LSA have the same type and an equal distance, these priorities apply (listed from highest to lowest) to break the tie:

  • a. Any type 5 LSA.
  • b. A type-7 LSA with the P-bit set and a non-zero forwarding address.
  • c. Any other type-7 LSA.

If the new path is shorter, it replaces the present paths in the routing table entry. If the new path is the same cost, it gets added to the routing table entry's list of paths 🏆.

3.6 Incremental Updates 🔄

Incremental updates for type-7 LSAs should be treated the same as incremental updates for type-5 LSAs (see section 16.6 of the OSPF specification). So if a new instance of a type-7 LSA shows up, you don't need to recalculate the entire routing table 🙌. If there's already an OSPF internal route to the destination the type-7 LSA represents, no recalculation is necessary either 💅.

Otherwise, the procedure in the preceding section has to be performed, but only for the external routes (type-5 and type-7) whose networks describe the same networks as the newly received LSA 🎯.

4.0 Originating Type-5 LSAs ✨

4.1 Translating Type-7 LSAs Into Type-5 LSAs ✨

Okay bestie, this step happens as part of the NSSA's Dijkstra calculation, after the type-5 and type-7 routes have been calculated 💅. If the calculating router is not an area border router, this translation algorithm SHOULD be skipped 🙈. Next, all reachable area border routers in the NSSA SHOULD now be examined, noting the one with the highest router ID 👑. If that router has the highest router ID, it's the one that translates type-7 LSAs into type-5 LSAs for the NSSA. Otherwise the translation algorithm SHOULD NOT be performed 💀.

All type-7 routes that have been added to the routing table SHOULD be examined 🦋. If the type-7 LSA tied to the route being examined has the P-bit set and a non-zero forwarding address, the following steps SHOULD be taken 🌸.

The translation procedure MUST first check for a configured type-7 address range. Quick refresher: a type-7 address range is an [address,mask] pair plus a status of either Advertise or DoNotAdvertise. At most a single type-5 LSA is made for each range. If the route being examined falls within the type-7 address range (meaning the route's [address,mask] pair is equal to or a more specific instance of the range's [address,mask] pair), one of the following three actions MAY take place 🎀.

  1. When the range's status indicates Advertise and the route's address and mask are equal to the address and mask of the type-7 range, a type-5 LSA SHOULD be originated if:
    • there currently is no type-5 LSA originated from this router corresponding to the type-7 LSA,
    • the path type or the metric in the corresponding type-5 LSA is different from the type-7 LSA, or
    • the forwarding address in the corresponding type-5 LSA is different from the type-7 LSA.

The newly originated type-5 LSA will describe the same network and have the same network mask, metrics, forwarding address, external route tag and path type as the type-7 LSA. The only difference is that the advertising router field will be the router ID of this area border router ✨.

  1. When the range's status indicates Advertise and the route's address or mask indicates a more specific route (i.e., the route's address is subsumed by the range or the route has a longer mask), a type-5 LSA is generated with a link-state ID equal to the range's address. If necessary, the link-state ID can also have one or more of the range's "host" bits set; see Appendix F of the OSPF specification for details. The network mask, external route tag and path type will be set to the configured type-7 range values. The advertising router field will be the router ID of this area border router. The forwarding address will not be set. The path type SHOULD always be set to the highest path type that is subsumed by the net range. The metric for the type-5 LSA will be set as follows:
    • if the path type is external type 2, the type-5 metric SHOULD be set to the largest type-7 metric subsumed by this net range + 1.
    • if the path type is external type 1, the type-5 metric SHOULD be set to the largest metric.

For example, given a net range of [10.0.0.0, 255.0.0.0] for an area that has type-7 routes of:

10.1.0.0 path type 1, metric 10
10.2.0.0 path type 1, metric 11
10.3.0.0 path type 2, metric 5

a type-5 LSA will be generated with a path type of 2 and a metric of 6 🧮.

As another example, given a net range of [10.0.0.0, 255.0.0.0] for an area that has type-7 routes of:

10.1.0.0 path type 1, metric 10
10.2.0.0 path type 1, metric 11
10.3.0.0 path type 1, metric 5

a type-5 LSA will be generated with a path type of 1 and a metric of 11.

These metric and path type rules will avoid routing loops in the event that path type 1 and 2 are both used within the area 🔁.

  1. When the range's status indicates DoNotAdvertise, the type-5 LSA is suppressed and the component networks remain hidden from the rest of the AS 🫣.

By default (given that the P-bit is set and the LSA has a non-zero forwarding address), if a network is not contained in any explicitly configured address range, a type-7 to type-5 LSA translation will occur 🌈.

A new instance of a type-5 LSA SHOULD be originated and flooded to all attached type-5 capable areas if one of the following is true.

  1. There currently is no type-5 LSA originated from this router corresponding to the type-7 LSA.
  2. The path type or the metric in the corresponding type-5 LSA is different from the type-7 LSA.
  3. The forwarding address in the corresponding type-5 LSA is different from the type-7 LSA.

The newly originated type-5 LSAs will describe the same network and have the same network mask, metrics, forwarding address, external route tag and path type as the type-7 LSA. The advertising router field will be the router ID of this area border router.

As with all newly originated type-5 LSAs, a type-5 LSA that is the result of a type-7 to type-5 translation (type-7 range or default case) is flooded to all attached type-5 capable areas 🚀.

4.2 Flushing Translated Type-7 LSAs 🧹

If an NSSA area border router has translated a type-7 LSA to a type-5 LSA that SHOULD no longer be translated, the type-5 LSA SHOULD be flushed (set to MaxAge and flooded). The translated type-5 LSA SHOULD be flushed whenever the routing table entry that caused the translation changes so that either the routing table entry is unreachable or the entry's associated LSA is not a type-7 with the P-bit set and a non-zero forwarding address 🗑️.

5.0 Acknowledgements 🫶

This document was produced by the OSPF Working Group, chaired by John Moy. In addition, the comments of the following individuals are also acknowledged 💖:

               Phani Jajjarvarpu  cisco
               Dino Farinacci     cisco
               Jeff Honig         Cornell University
               John Moy           Proteon, Inc.
               Doug Williams      IBM

6.0 References 📚

[1] Moy, J., "OSPF Version 2", RFC 1583, Proteon, Inc., March 1994.

[2] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., Proteon, Inc., March 1994.

7.0 Security Considerations 🔒

Security issues are not discussed in this memo. 💀 Dramatic, I know, but that's the whole entry, no notes.

8.0 Authors' Addresses 📮

Rob Coltun
RainbowBridge Communications

Phone: (301) 340-9416
EMail: rcoltun@rainbow-bridge.com


Vince Fuller
BARRNet
Stanford University
Pine Hall 115
Stanford, CA, 94305-4122

Phone: (415) 723-6860
EMail: vaf@Valinor.Stanford.EDU

Appendix A: Type-7 Packet Format 🎀

Here's the packet layout, slay 💅:

          0                                32
          -----------------------------------
          |                | OPTS   |   7   |
          |                ------------------
          |        Link-State Header        |
          |                                 |
          -----------------------------------
          | Network Mask                    |
          -----------------------------------  ______
          |E| Tos  |        metric          |  .
          -----------------------------------  .  repeated for each TOS
          | Forwarding Address              |  .
          -----------------------------------  .
          | External Route Tag              |  ______
          -----------------------------------

The definitions of the link-state ID, network mask, metrics and external route tag are the same as the definitions for the type-5 LSAs (see A.4.5 in the OSPF specification) except for:

  • The Forwarding Address

If the network between the NSSA AS boundary router and the adjacent AS is advertised into OSPF as an internal OSPF route, the forwarding address SHOULD be the next hop address. But if the intervening network is not advertised into OSPF as an internal OSPF route, the forwarding address SHOULD be any one of the router's active OSPF interface addresses 🧭.

Appendix B: The Options Field 🍓

The OSPF options field is present in OSPF Hello packets, Database Description packets and all link-state advertisements. See appendix A.2 in the OSPF specification for a description of the option field 📋.

                   ------------------------------------
                   | * | * | * | * | N/P | MC | E | T |
                   ------------------------------------

                       The Type-7 LSA options field
  • T-bit: The T-bit describes the router's TOS capability.
  • E-bit: Type-5 AS external link advertisements are not flooded into/through OSPF stub and NSSA areas. The E-bit ensures that all members of a stub area agree on that area configuration. The E-bit is meaningful only in OSPF Hello packets. When the E-bit is reset in the Hello packet sent out a particular interface, it means that the router will neither send nor receive type-5 AS external link state advertisements on that interface (in other words, the interface connects to a stub area). Two routers will not become neighbors unless they agree on the state of the E-bit 🚧.
  • MC-bit: The MC-bit describes the multicast capability of the various pieces of the OSPF routing domain [2].
  • N-bit: The N-bit describes the router's NSSA capability. The N-bit is used only in Hello packets and ensures that all members of an NSSA agree on that area's configuration. When the N-bit is reset in the Hello packet sent out a particular interface, it means that the router will neither send nor receive type-7 LSAs on that interface. Two routers will not form an adjacency unless they agree on the state of the N-bit. If the N-bit is set in the options field, the E-bit MUST be reset 🙌.
  • P-bit: The P-bit is used only in the type-7 LSA header. It flags the NSSA area border router to translate the type-7 LSA into a type-5 LSA 🦋.

Appendix C: Configuration Parameters ⚙️

Appendix C.2 in the OSPF specification lists the area parameters. The area ID, list of address ranges for type-3 summary routes and authentication type remain unchanged. Section 3.2 of this document lists the configuration parameters for type-7 address ranges 🌷.

For NSSAs, the external capabilities of the area MUST be set to accept type-7 external routes. Additionally, there MUST be a way of configuring the NSSA area border router to send a default route into the NSSA using a specific metric (type-1 or type-2 and the actual cost). That's the end of the spec, bestie, and you ate it all 👑🎀

📦 where this page comes from