OSPF Stub and NSSA Area Types: Configuration Guide

Stub areas exist to shrink the link-state database and to stop external churn from reaching routers that have no business carrying external routes. NSSA exists because stub areas have one annoying limitation: they cannot contain an ASBR. If the branch site needs to redistribute a static route or inject a default learned elsewhere, plain stub breaks — and that is exactly the gap RFC 3101's NSSA option fills. This guide lays out which area type blocks what, then configures and verifies each one.

Which Area Type Blocks What

The mechanism that makes NSSA work: external routes are carried inside the area as type-7 LSAs. At the area border, the ABR (acting as the type-7-to-type-5 translator) converts them to type-5 LSAs so the rest of the OSPF domain sees them as normal externals. Route redistribution inside an NSSA therefore works — it just uses a different LSA other than type 5.

Stub Configuration

! All routers inside area 1 must agree on the stub flag
router ospf 1
 router-id 10.0.0.1
 area 1 stub                 ! interior router
!
! On the ABR, use no-summary to make it totally stubby
router ospf 1
 area 1 stub no-summary      ! blocks LSA 3 as well; injects only a default route

The ABR automatically originates a default route into a stub area. That default is the only exit for external destinations, so a stub area must have exactly one or more ABRs that can reach the rest of the domain — design-wise, this is why stub areas are for leaf sites, not transit.

NSSA Configuration

! Interior router inside the NSSA
router ospf 1
 router-id 10.0.0.2
 area 1 nssa

! ASBR inside the NSSA redistributing a static route
router ospf 1
 area 1 nssa
 redistribute static subnets
!
ip route 0.0.0.0 0.0.0.0 192.0.2.1

! ABR that also wants to send a default into the NSSA
router ospf 1
 area 1 nssa default-information-originate

Note the difference between default-information originate (an ASBR injecting a default into the domain, creating an external LSA) and area X nssa default-information-originate (originating a default specifically into the NSSA). Mixing these up is a common source of "the branch has no default route".

Verification

show ip ospf                 ! per-area configuration: stub/NSSA flags as seen locally
show ip ospf database         ! look for LSA types 3, 5 and 7 per area
show ip ospf database nssa-external     ! type-7 LSAs (NSSA only)
show ip ospf database external         ! type-5 LSAs (should be empty inside a stub area)
show ip route ospf
show ip ospf neighbor

Concrete things to check: inside a stub area there must be no type-5 LSAs and a default route via the ABR; inside an NSSA you should see type-7 LSAs for redistributed routes, and type-5 equivalents once the ABR translates them. If the ABR is translating, its role as translator can be inspected on platforms that expose the NSSA translator state.

Design Pitfalls

• Flag mismatch: every router in the area must have the stub/NSSA flag. A mismatch prevents adjacency formation — the neighbour drops with a mismatched area parameter, which is easy to misread as an MTU or authentication problem.
• Stub with an ASBR inside: not allowed. If the site needs redistribution, use NSSA.
• Area 0 cannot be stub or NSSA. The backbone carries the full database by definition.
• Virtual links and stub/NSSA do not mix: a virtual link traverses area 0 semantics that a stub area cannot provide.
• Summarisation still matters. Blocking LSAs reduces the database, but area range/summary-address is what keeps it small as the network grows.
• Multiple ABRs and default routes: with two ABRs in a stub area both inject defaults; verify which one your traffic actually uses, especially if one has a worse path to the core.

相关阅读：OSPF LSA 类型与作用范围说明、Cisco Nexus NX-OS OSPF 配置示例 以及 Cisco IOS-XR OSPF 配置示例。

原文链接：Cisco - Configure the OSPF Not-So-Stubby Area (NSSA)