9.1 OSPF Special Area Types

OSPF Special Area Types

In large enterprise networks, running a standard, flat multi-area OSPF design can introduce severe resource scaling challenges on campus access switches and branch office routers. Standard OSPF areas flood all Link-State Advertisements (LSAs)—including external routes redistributed from BGP, static routes, or other routing domains—to every router in the area. Special area types provide a deterministic mechanism to prune the Link-State Database (LSDB), conserve memory, reduce control-plane processing, and shield edge devices from backbone route volatility.

---

1. Motivation for Special Area Types: LSDB Scaling & SPF Overhead

In OSPF, every router within an area runs Dijkstra's Shortest Path First (SPF) algorithm against an identical topological map. The computational complexity of the Dijkstra calculation is roughly proportional to $O(L \log N)$, where $L$ is the number of links and $N$ is the number of nodes in the link-state database.

In enterprise networks with hundreds or thousands of external routes (such as cloud subnets, partner WAN prefixes, or default internet feeds), flooding these routes as Type 5 AS External LSAs across every non-backbone area imposes serious operational burdens:

1. Memory Consumption: LSAs consume control-plane database memory. The PFE contains selected forwarding entries derived from routes, not a hardware copy of every LSA.
2. CPU Utilization During Flaps: While external LSAs do not trigger a full SPF recalculation (they trigger a partial SPF calculation), link churn or route flapping in an external autonomous system causes constant LSA flooding, checksum verification, and routing table updates across all routers.
3. Redundant Topological Detail: Branch access switches and campus edge routers typically possess only one or two egress paths toward the distribution or core layers. These routers do not require individual topological visibility or granular external metrics for hundreds of remote subnets; they only need a default route (0.0.0.0/0) pointing toward the Area Border Router (ABR).

OSPF defines special area types to replace granular external and inter-area routing information with compact default routes at the area boundary.

---

2. Special Area Types & LSA Filtering Mechanics

OSPF defines four primary special area types, each implementing specific LSA filtering boundaries at the ABR.

+---------------------------------------------------------------------------------------------------+
| OSPF SPECIAL AREA TYPES & LSA FILTERING TAXONOMY                                                  |
+-------------------+---------------+---------------+---------------+---------------+---------------+
| Area Type         | Type 1 & 2    | Type 3        | Type 4 & 5    | Type 7        | Default Route |
|                   | (Intra-Area)  | (Inter-Area)  | (External)    | (NSSA Ext)    | Injection     |
+-------------------+---------------+---------------+---------------+---------------+---------------+
| Standard Area     | Allowed       | Allowed       | Allowed       | Blocked       | None (Manual) |
| Stub Area         | Allowed       | Allowed       | BLOCKED       | Blocked       | Type 3 (configure default-metric) |
| Totally Stubby    | Allowed       | BLOCKED*      | BLOCKED       | Blocked       | Type 3 (configure default-metric) |
| NSSA              | Allowed       | Allowed       | BLOCKED       | Allowed       | Explicit/None |
| Totally NSSA      | Allowed       | BLOCKED*      | BLOCKED       | Allowed       | Type 3 (configure default-metric) |
+-------------------+---------------+---------------+---------------+---------------+---------------+
* Note: In Totally Stubby and Totally NSSA, Type 3 summary LSAs are blocked EXCEPT for the single
  Type 3 Summary LSA representing the default route (0.0.0.0/0) injected by the ABR.

A. Standard Stub Area

A Stub Area shields internal routers from external routing information:

• LSA Filtering: The ABR blocks all Type 5 AS External LSAs (generated by ASBRs outside the area) and Type 4 ASBR Summary LSAs (which advertise reachability to ASBRs).
• Permitted LSAs: Type 1 (Router), Type 2 (Network), and Type 3 (Network Summary) LSAs flood normally throughout the stub area, allowing internal routers to maintain full visibility of intra-area and inter-area destinations.
• Default Route Injection: Because external routes are filtered out, configure the Junos ABR’s stub default-metric to generate a default route (0.0.0.0/0) advertised as a Type 3 Summary LSA into the stub area. Internal routers use this Type 3 default route to reach all external destinations.
• Constraints: An Autonomous System Boundary Router (ASBR) cannot reside inside a stub area (no external redistribution is permitted). Furthermore, a virtual link cannot transit through a stub area.

B. Totally Stubby Area

A Totally Stubby Area (originally introduced by Cisco and supported as an industry-standard Junos feature) provides the most aggressive LSDB reduction:

• LSA Filtering: The ABR blocks Type 4 and Type 5 LSAs, and additionally blocks all Type 3 Network Summary LSAs representing prefixes in other OSPF areas.
• Permitted LSAs: Only intra-area Type 1 and Type 2 LSAs are allowed within the area.
• Default Route Injection: The ABR injects a single Type 3 Summary LSA representing 0.0.0.0/0. Internal routers rely exclusively on this default route for all inter-area and external traffic.
• Advantage: The LSDB contains only the immediate local topology plus a single default route, minimizing memory footprint and completely isolating the area from route flaps occurring anywhere outside the area.

C. Not-So-Stubby Area (NSSA - RFC 3101)

In enterprise deployments, branch locations often require external route redistribution (for example, learning local static routes, connecting to a partner via BGP, or terminating an IPsec tunnel) while still benefiting from stub area protections. A standard stub area strictly prohibits ASBRs. The Not-So-Stubby Area (NSSA) solves this architectural dilemma:

• LSA Filtering: Like a standard stub area, the ABR blocks external Type 4 and Type 5 LSAs originating from the backbone or other areas from entering the NSSA.
• Local Redistribution via Type 7 LSAs: An internal router acting as an ASBR inside the NSSA can redistribute external routes. Because Type 5 LSAs are forbidden in stub environments, the ASBR packages these external routes into Type 7 NSSA External LSAs.
• Flooding Scope: Type 7 LSAs flood strictly within the originating NSSA; they are never flooded directly into Area 0 or other standard areas.
• Type 7 to Type 5 Translation: When Type 7 LSAs reach an ABR connecting the NSSA to the backbone (Area 0), the ABR translates the Type 7 LSAs into standard Type 5 AS External LSAs and floods them across Area 0 and the rest of the OSPF autonomous system.
• The Propagate Bit (P-bit):
  • The originating ASBR sets the P-bit (Propagate bit) in the options field of the Type 7 LSA header.
  • When $P=1$ and the LSA contains a non-zero Forwarding Address (FA), the ABR translates the Type 7 LSA into a Type 5 LSA.
  • If $P=0$, the ABR is instructed not to translate the LSA. This allows network administrators to keep specific external routes strictly local to the NSSA.
• Default Route Behavior in Junos: Unlike standard stub areas, Junos ABRs do not automatically inject a default route into an NSSA by default. Network administrators must explicitly configure default route generation under the NSSA hierarchy.

D. Totally NSSA

A Totally NSSA combines NSSA external redistribution with totally stubby summary filtering:

• LSA Filtering: Blocks Type 4 and Type 5 external LSAs, and blocks all Type 3 summary LSAs from entering the area.
• Local Redistribution: Permits Type 7 LSAs originating within the area.
• Default Route Injection: Configure the ABR’s nssa default-lsa to inject a default route (0.0.0.0/0) as a Type 3 Summary LSA into the area (suppressing all other Type 3 summaries).

---

3. Junos CLI Configuration & Verification

Configuring special area types in Junos OS is accomplished under the [edit protocols ospf area <area-id>] hierarchy.

A. Configuring a Standard Stub Area

All routers within the area must agree on the stub flag in their Hello packets (the E-bit in the Options field must be set to 0). If one router is configured as stub and its neighbor is not, the Hello validation fails and the adjacency does not form.

Internal Router Configuration:

[edit protocols ospf]
user@Branch-EX3400# set area 0.0.0.20 stub
user@Branch-EX3400# set area 0.0.0.20 interface ge-0/0/0.0
user@Branch-EX3400# set area 0.0.0.20 interface lo0.0 passive

ABR Configuration (Injecting Default Metric):

[edit protocols ospf]
user@Campus-ABR# set area 0.0.0.0 interface ae0.0
user@Campus-ABR# set area 0.0.0.20 stub default-metric 25
user@Campus-ABR# set area 0.0.0.20 interface ge-0/0/1.0

B. Configuring a Totally Stubby Area

In Junos, a totally stubby area is configured by adding the no-summaries option on the ABR only. Internal routers require only the basic stub statement.

ABR Configuration:

[edit protocols ospf]
user@Campus-ABR# set area 0.0.0.20 stub default-metric 25 no-summaries

C. Configuring an NSSA and Totally NSSA

In an NSSA, routers configure nssa instead of stub (the N-bit is set to 1 in Hello packets). To inject a default route on a Junos ABR, use default-lsa:

ABR Configuration for Basic NSSA with Default Route:

[edit protocols ospf]
user@Campus-ABR# set area 0.0.0.30 nssa default-lsa default-metric 15
user@Campus-ABR# set area 0.0.0.30 nssa default-lsa type-7
user@Campus-ABR# set area 0.0.0.30 interface ge-0/0/2.0

ABR Configuration for Totally NSSA:

[edit protocols ospf]
user@Campus-ABR# set area 0.0.0.30 nssa default-lsa default-metric 15
user@Campus-ABR# set area 0.0.0.30 nssa default-lsa type-7
user@Campus-ABR# set area 0.0.0.30 nssa no-summaries

D. Operational Verification Commands

To verify special area operation and confirm LSA filtering in Junos:

user@Branch-EX3400> show ospf overview
OSPF instance: master
  Router ID: 10.20.0.1
  Area: 0.0.0.20
    Stub type: Stub                    <-- Verifies area type
    Authtype: None
    Area border routers: 1, AS boundary routers: 0
    Neighbors
      Total: 1, Up: 1

user@Branch-EX3400> show ospf database
    OSPF link state database, Area 0.0.0.20
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *10.20.0.1        10.20.0.1        0x80000004   212  0x2  0x4a12  36
Router   10.20.0.254      10.20.0.254      0x80000003   198  0x2  0x8b34  36
Summary  0.0.0.0          10.20.0.254      0x80000001   201  0x2  0x319a  28

Notice that no Type 4, Type 5, or individual Type 3 summaries appear in the totally stubby database—only the Summary 0.0.0.0 default route.

---

4. Critical Exam Gotchas

1. Stub Flag Mismatch: OSPF Hello packets exchange area capability flags in the Options field. Stub areas clear the E-bit (ExternalRoutingCapability). NSSAs set the N-bit. If two adjacent routers have mismatched stub/NSSA configurations, the Hello packet is discarded and the neighbor adjacency cannot form; an Init state by itself specifically indicates missing bidirectional discovery.
2. Virtual Link Transit Prohibition: An OSPF virtual link cannot be configured across a Stub or NSSA area. Virtual links require transit areas to flood all LSA types (including Type 4 and Type 5) without filtering.
3. Type 7 to Type 5 Translator Election: When multiple ABRs attach an NSSA to Area 0, RFC 3101 dictates that only one ABR translates Type 7 LSAs to Type 5 to avoid redundant advertisements. By default, the ABR with the highest Router ID is elected as the translator. Junos allows manual override using set protocols ospf area <id> nssa always-translate.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.