101
0/240
Loading content...
A flat OSPF network where every router knows about every link would collapse under its own weight at scale. With thousands of routers, the LSDB would be enormous, SPF calculations would consume excessive CPU, and every topology change would trigger flooding and recalculation across the entire domain.
OSPF areas solve this problem through hierarchy. By dividing the network into areas, OSPF achieves:
But not all areas behave the same. OSPF defines several area types, each with different rules about which LSAs are permitted. Understanding these types is essential for designing scalable OSPF networks and optimizing routing table sizes.
By the end of this page, you will understand: (1) OSPF's hierarchical area model and the backbone requirement, (2) The role of Area Border Routers (ABRs) in summarization, (3) Standard, stub, totally stubby, and NSSA area types, (4) Which LSA types are permitted in each area type, (5) How to choose the appropriate area type for different network scenarios, and (6) Configuration and verification of area types.
OSPF uses a two-level hierarchy: area 0 (the backbone) and non-backbone areas. All non-backbone areas must connect to the backbone, either directly or through virtual links. This star-like structure ensures routing information flows predictably through a central hub.
Key Concepts:
| Component | Definition | Role |
|---|---|---|
| Area | A group of routers sharing an identical LSDB | Limits flooding and SPF scope |
| Area 0 (Backbone) | The mandatory central area | Transit for all inter-area traffic |
| Non-backbone Area | Any area other than 0 | Contains detailed topology, summarized to backbone |
| Area Border Router (ABR) | Router with interfaces in multiple areas | Originates summary LSAs between areas |
| AS Boundary Router (ASBR) | Router redistributing external routes | Originates external (Type-5) LSAs |
| Virtual Link | Logical link through transit area to backbone | Extends backbone connectivity |
OSPF Hierarchical Area Model═══════════════════════════════════════════════════════════════════════════ ASBR │ External Routes ▼ (Type-5 LSAs) ┌─────────────────────────────────────────────────────┐ │ AREA 0 │ │ (BACKBONE) │ │ │ │ ABR1 ABR2 ABR3 │ └──────┬────────────────┬────────────────┬────────────┘ │ │ │ ┌───────────┴───┐ ┌───────┴───────┐ ┌──┴────────────┐ │ AREA 1 │ │ AREA 2 │ │ AREA 3 │ │ (Standard) │ │ (Stub) │ │ (NSSA) │ │ │ │ │ │ │ │ R1 R2 R3 │ │ R4 R5 R6 │ │ R7 R8 ASBR │ └───────────────┘ └───────────────┘ └───────────────┘ LSA Flow:═════════════════════════════════════════════════════════════════════════════• Type-1 (Router): Within area only, never crosses ABR• Type-2 (Network): Within area only, never crosses ABR• Type-3 (Summary Network): ABR generates for inter-area routes• Type-4 (Summary ASBR): ABR generates to advertise ASBR location• Type-5 (External): ASBR generates, flooded to all non-stub areas• Type-7 (NSSA External): ASBR in NSSA generates, converted to Type-5 at ABR Key Rules:═════════════════════════════════════════════════════════════════════════════• All areas MUST connect to Area 0 (directly or via virtual link)• Inter-area traffic MUST transit through Area 0• ABRs maintain separate LSDBs for each area they touch• Area 0 sees summary routes, not detailed topology of other areasWhy the Backbone Requirement?
The backbone-centric design prevents routing loops in inter-area routing. Consider what happens without a backbone requirement:
No loop here—but what if costs change? Without the deterministic backbone transit, routing loops become possible. By forcing all inter-area traffic through Area 0, OSPF ensures a consistent, loop-free routing topology.
A router is an ABR if it has at least one interface in Area 0 AND at least one interface in a non-backbone area. Simply having interfaces in two non-backbone areas does not make a router an ABR—it must touch the backbone. (Exception: RFC 3509 modified this to "best-connected to backbone" for certain virtualization scenarios.)
Understanding which LSA types are permitted in each area type is fundamental to OSPF area design. Area types are defined by which LSAs they filter.
Complete LSA Type Reference:
| Type | Name | Originated By | Scope | Purpose |
|---|---|---|---|---|
| 1 | Router LSA | Every router | Within area | Describes router's links and their costs |
| 2 | Network LSA | DR on broadcast/NBMA | Within area | Lists routers attached to transit network |
| 3 | Summary Network LSA | ABR | Into other areas | Advertises inter-area prefixes |
| 4 | Summary ASBR LSA | ABR | Into other areas | Advertises path to ASBR |
| 5 | External LSA | ASBR | OSPF domain (almost) | Advertises external routes |
| 7 | NSSA External LSA | ASBR in NSSA | NSSA only | External routes within NSSA |
LSA Flooding Matrix by Area Type:
LSA Flooding by Area Type═══════════════════════════════════════════════════════════════════════════ LSA Types Permitted ┌────────────────────────────────────────────┐ Area Type │ Type-1 │ Type-2 │ Type-3 │ Type-4 │ Type-5 │ Type-7 │ │(Router)│(Network)│(Summary)│(ASBR) │(External)│(NSSA)│════════════════════╪════════╪════════╪════════╪═══════╪═════════╪═══════╪ Backbone (Area 0) │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │────────────────────┼────────┼────────┼────────┼───────┼─────────┼───────┤ Standard Area │ ✓ │ ✓ │ ✓ │ ✓ │ ✓ │ ✗ │────────────────────┼────────┼────────┼────────┼───────┼─────────┼───────┤ Stub Area │ ✓ │ ✓ │ ✓ │ ✗ │ ✗ │ ✗ │────────────────────┼────────┼────────┼────────┼───────┼─────────┼───────┤ Totally Stubby │ ✓ │ ✓ │ ✗* │ ✗ │ ✗ │ ✗ │────────────────────┼────────┼────────┼────────┼───────┼─────────┼───────┤ NSSA │ ✓ │ ✓ │ ✓ │ ✗ │ ✗ │ ✓ │────────────────────┼────────┼────────┼────────┼───────┼─────────┼───────┤ Totally Stubby NSSA│ ✓ │ ✓ │ ✗* │ ✗ │ ✗ │ ✓ │════════════════════╧════════╧════════╧════════╧═══════╧═════════╧═══════╧ * = Except for default route (0.0.0.0/0) summary Key Insights:═════════════════════════════════════════════════════════════════════════════• Type-1 and Type-2 are ALWAYS present (define intra-area topology)• Type-5 absence is the defining characteristic of stub areas• Type-7 enables external routes in NSSA despite no Type-5• "Totally" variants filter Type-3/4, injecting only a default route• Area 0 cannot be stub (must handle all inter-area traffic)Remember: Stub = no external (Type-5). Totally stubby = no external AND no summaries (Type-3/4). NSSA = no external, but allows local external (Type-7). The key question is always: "What does this area need to know about?"
Area 0, the backbone, is the core of every OSPF network. It has unique properties and requirements that distinguish it from all other areas.
Backbone Characteristics:
Virtual Links:
When an area cannot physically connect to Area 0, a virtual link provides logical backbone connectivity through a transit area. The transit area must be a standard (non-stub) area.
Virtual Link Scenario═══════════════════════════════════════════════════════════════════════════ Problem: Area 3 cannot directly connect to Area 0 ┌───────────────────┐ │ Area 0 │ │ │ │ ABR1 │ └────────┬──────────┘ │ ┌────────┴──────────┐ │ Area 2 │ (Transit Area) │ │ │ ABR1----ABR2 │ └────────┬──────────┘ │ ┌────────┴──────────┐ │ Area 3 │ (Needs backbone access) │ │ │ ABR2 R1 │ └───────────────────┘ Solution: Virtual Link between ABR1 and ABR2 through Area 2 ╔═══════════════════════════════╗ ║ Virtual Link (logical) ║ ║ ABR1 <═════════════════> ABR2 ║ ╚═══════════════════════════════╝ After virtual link:• ABR2 becomes an ABR (connected to Area 0 via virtual link)• Area 3 traffic flows: Area 3 → ABR2 → Area 2 → ABR1 → Area 0• To other areas: continues through Area 0 Configuration (Cisco):─────────────────────────────────────────────────────────────────────────────! On ABR1 (Router ID: 1.1.1.1):router ospf 1 area 2 virtual-link 2.2.2.2 ! ABR2's Router ID ! On ABR2 (Router ID: 2.2.2.2):router ospf 1 area 2 virtual-link 1.1.1.1 ! ABR1's Router ID Verification:─────────────────────────────────────────────────────────────────────────────show ip ospf virtual-links Virtual Link OSPF_VL0 to router 2.2.2.2 is up Run as demand circuit DoNotAge LSA allowed. Transit area 2, via interface GigabitEthernet0/1 Neighbor state FULLVirtual links should be temporary solutions to backbone connectivity problems, not permanent design choices. They add complexity, depend on transit area stability, and can cause subtle routing issues. When possible, redesign the physical topology to restore direct backbone connectivity.
Standard areas (sometimes called "normal" areas) are the default non-backbone area type. They participate fully in OSPF, receiving all LSA types including external routes.
Standard Area Behavior:
| Aspect | Behavior | Implications |
|---|---|---|
| LSA Types | Receives all types (1-5) | Full participation in OSPF routing |
| External Routes | Receives Type-5 LSAs from all ASBRs | Large RIB if many external routes |
| Inter-area Routes | Receives Type-3 summaries from ABR | Knows about all OSPF prefixes |
| Default Route | Not automatically injected | Must be configured or redistributed |
| ASBR Allowed | Yes, can have local ASBRs | Can redistribute into OSPF |
| Use Case | Areas needing full routing visibility | Core, data center, HQ locations |
When to Use Standard Areas:
12345678910111213141516171819202122232425
! Standard Area Configuration (Cisco IOS)! Area 1 as a standard area - the default, minimal config router ospf 1 network 10.1.0.0 0.0.255.255 area 1 ! That's it - standard is the default behavior ! Verification:show ip ospf Area 1 Number of interfaces in this area is 3 Area has no authentication SPF algorithm last executed 00:02:15.123 ago SPF algorithm executed 12 times Area ranges are Number of LSA 45. Checksum Sum 0x012ABC Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0 Number of indication LSA 0 Number of DoNotAge LSA 0 Flood list length 0 show ip ospf database ! You'll see all LSA types including Type-5 externalsIn networks with large numbers of external routes (e.g., full Internet BGP table redistribution), standard areas may have very large routing tables. Each router in the area must store all Type-5 LSAs and compute routes to all external destinations. This is where stub and NSSA areas provide relief.
Stub areas block external routes (Type-5 LSAs) from entering the area. Instead, the ABR injects a default route, directing all external-bound traffic toward the ABR for further routing decisions.
Stub Area Mechanics:
Stub Area Behavior═══════════════════════════════════════════════════════════════════════════ ┌─────────────────────┐ │ Area 0 │ │ (has Type-5s) │ │ │ │ 10.0.0.0/8 via ASBR (Type-5) │ 20.0.0.0/8 via ASBR (Type-5) │ 30.0.0.0/8 via ASBR (Type-5) │ │ │ ABR │ └─────────┬───────────┘ │ Type-5 BLOCKED ─────X───── Type-5 BLOCKED │ Default route injected (Type-3) ▼ ┌─────────────────────┐ │ Area 1 (STUB) │ │ │ │ Sees: │ │ • Type-1 (local) │ │ • Type-2 (local) │ │ • Type-3 (summaries)│ │ • 0.0.0.0/0 → ABR │ │ │ │ Does NOT see: │ │ • 10.0.0.0/8 │ │ • 20.0.0.0/8 │ │ • 30.0.0.0/8 │ └─────────────────────┘ Result:═══════════════════════════════════════════════════════════════════════════• Routers in Area 1 have smaller LSDB (no Type-5 LSAs)• Routers in Area 1 have smaller routing tables• External destinations are reached via the default route• Traffic to 10.0.0.0/8 goes to ABR, which knows the specific pathConfiguration:
123456789101112131415161718192021222324
! Stub Area Configuration - MUST be on ALL routers in the area! ! On ABR (router between Area 0 and Area 1):router ospf 1 area 1 stub ! On all internal routers in Area 1:router ospf 1 area 1 stub ! Verification:show ip ospf Area 1 It is a stub area ... Generates stub default route with cost 1 show ip route ospf O*IA 0.0.0.0/0 [110/11] via 10.1.1.1, GigabitEthernet0/0 ! Customizing default route cost (on ABR only):router ospf 1 area 1 stub area 1 default-cost 100 ! Default is 1If you configure only some routers in an area as stub, the E-bit in Hello packets won't match, and adjacencies will fail (stuck in INIT). This is the #1 stub configuration error. Always configure ALL routers in the designated stub area.
Totally stubby areas take stub area simplification one step further: they block not only external routes (Type-5) but also inter-area summary routes (Type-3/4). Internal routers receive only a default route for all destinations outside the area.
Totally Stubby Area Mechanics:
Totally Stubby Area Behavior═══════════════════════════════════════════════════════════════════════════ ┌─────────────────────┐ │ Area 0 │ │ │ │ • 10.0.0.0/8 (Type-5 external) │ • 192.168.1.0/24 (Area 2 via Type-3) │ • 192.168.2.0/24 (Area 2 via Type-3) │ • 172.16.0.0/16 (Area 3 via Type-3) │ │ │ ABR │ └─────────┬───────────┘ │ Type-5 BLOCKED ─────X───── Type-5 BLOCKED Type-3 BLOCKED ─────X───── Type-3 BLOCKED Type-4 BLOCKED ─────X───── Type-4 BLOCKED │ ONLY default route injected ▼ ┌─────────────────────┐ │ Area 1 (TOTALLY │ │ STUBBY) │ │ │ │ Sees: │ │ • Type-1 (local) │ │ • Type-2 (local) │ │ • 0.0.0.0/0 → ABR │ │ │ │ Does NOT see: │ │ • ANY external │ │ • ANY inter-area │ │ • 192.168.x.x │ │ • 172.16.x.x │ └─────────────────────┘ Routing Table Comparison:═══════════════════════════════════════════════════════════════════════════Standard Area │ Stub Area │ Totally Stubby─────────────────────┼────────────────────┼─────────────────────10.0.0.0/8 → ASBR │ 0.0.0.0/0 → ABR │ 0.0.0.0/0 → ABR20.0.0.0/8 → ASBR │ 192.168.1.0 → ABR │ (nothing else)192.168.1.0 → ABR │ 192.168.2.0 → ABR │192.168.2.0 → ABR │ 172.16.0.0 → ABR │172.16.0.0 → ABR │ │... (hundreds) │ ... (fewer) │ Route count: 500+ │ Route count: 50 │ Route count: 10 │ │ (only local + default)Configuration:
1234567891011121314151617181920
! Totally Stubby Area Configuration ! On ABR - additional "no-summary" keyword:router ospf 1 area 1 stub no-summary ! On internal routers - regular stub command suffices:router ospf 1 area 1 stub ! Note: Only ABR needs "no-summary" - it blocks Type-3! Internal routers just need "stub" for E-bit matching ! Verification on internal router:show ip route ospf O*IA 0.0.0.0/0 [110/11] via 10.1.1.1, GigabitEthernet0/0 ! That's it - no other OSPF routes from outside the area show ip ospf database ! Only Type-1, Type-2 from local area, plus the default route Type-3| Aspect | Stub Area | Totally Stubby Area |
|---|---|---|
| Type-5 (External) | Blocked | Blocked |
| Type-4 (ASBR Summary) | Blocked | Blocked |
| Type-3 (Network Summary) | Allowed | Blocked (except default) |
| Default Route | Injected by ABR | Injected by ABR |
| Inter-area destinations | Specific routes known | Only via default |
| Optimal routing | Yes for inter-area | Suboptimal possible |
| LSDB size | Smaller than standard | Minimal |
Totally stubby areas are ideal for remote sites with a single exit point where you don't need optimal inter-area routing. A branch office with one WAN link doesn't benefit from knowing the specific path to HQ—everything goes out the same interface anyway. The dramatic LSDB reduction justifies any minor suboptimality.
NSSA solves a common problem: what if you need stub area benefits (no Type-5 flooding from the backbone) but also need to redistribute external routes locally within the area? Standard stub prohibits local ASBRs. NSSA allows them using Type-7 LSAs.
The NSSA Problem and Solution:
NSSA Scenario - Branch Office with Local Internet═══════════════════════════════════════════════════════════════════════════ ┌─────────────────────┐ │ Area 0 │ │ (Enterprise HQ) │ │ │ │ ASBR → Full Internet│ (100,000 Type-5 routes) │ │ │ ABR │ └─────────┬───────────┘ │ Corporate External ─X─ (We DON'T want 100K routes here) │ ▼ ┌─────────────────────┐ │ Area 1 (NSSA) │ │ Branch Office │ │ │ │ R1 R2 │ │ │ │ ASBR ─────── Local ISP │ (local) │ │ Want to advertise │ │ via this ISP! │ └─────────────────────┘ Problem:═════════════════════════════════════════════════════════════════════════════• Can't use standard area: Would receive 100K Type-5 routes from HQ• Can't use stub area: Stub prohibits local ASBR• Need: Block incoming Type-5, allow local external redistribution Solution: NSSA═════════════════════════════════════════════════════════════════════════════• External routes from backbone: BLOCKED (Type-5 filtered at ABR)• Local external routes: Redistributed as Type-7 LSAs• At ABR: Type-7 converted to Type-5 and flooded to backbone Type-7 LSA Flow:─────────────────────────────────────────────────────────────────────────────Local ISP → ASBR (in NSSA) → Type-7 LSA → ABR → Type-7→Type-5 → Area 0 ═══════════════════════════════════════════════════════════════════════════ Inside NSSA │ Outside NSSA │ Local ISP routes as TYPE-7 ───▶ │ ───▶ Same routes as TYPE-5 │ N-bit set in Hello │ Regular E-bit behavior═══════════════════════════════════════════════════════════════════════════Type-7 to Type-5 Translation:
Type-7 LSAs exist only within the NSSA. At the ABR, they're converted to Type-5 LSAs for flooding to the rest of the OSPF domain. Key translation rules:
123456789101112131415161718192021222324252627282930313233
! NSSA Configuration ! On ABR - configure area as NSSA:router ospf 1 area 1 nssa ! On internal routers and local ASBR:router ospf 1 area 1 nssa ! On local ASBR - redistribute external routes:router ospf 1 area 1 nssa redistribute connected subnets ! Or BGP, static, etc. ! Redistributed routes become Type-7 LSAs ! Default route options:router ospf 1 area 1 nssa default-information-originate ! Injects default route as Type-7 into NSSA ! Totally Stubby NSSA (blocks Type-3 also):router ospf 1 area 1 nssa no-summary ! Blocks Type-3 (like totally stubby) + allows Type-7 ! Verification:show ip ospf database nssa-external ! Shows Type-7 LSAs show ip ospf | include NSSA Area 1 is a NSSA area Translate Type-7 to Type-5: Enabled| Aspect | Stub | NSSA | Totally Stubby NSSA |
|---|---|---|---|
| Backbone Type-5 | Blocked | Blocked | Blocked |
| Local ASBR | Not allowed | Allowed (uses Type-7) | Allowed (uses Type-7) |
| Type-3 Summary | Allowed | Allowed | Blocked |
| Default Route | Type-3 from ABR | Type-7 if configured | Type-3 from ABR |
| Hello N-bit | Not set | Set | Set |
NSSA uses the N-bit (NSSA capability) in Hello packets instead of the E-bit. All routers in an NSSA must have N-bit set and E-bit clear. Mixing NSSA and non-NSSA routers in the same area causes adjacency failures, similar to stub/non-stub mismatches.
Selecting the appropriate area type requires understanding your routing requirements, network topology, and scalability goals. Here's a decision framework:
Decision Tree:
Area Type Selection Decision Tree═══════════════════════════════════════════════════════════════════════════ Start: Does this area need to be Area 0 (backbone)? │ ├─ YES → Use STANDARD for Area 0 (cannot be stub) │ └─ NO → Does this area need to redistribute external routes into OSPF? │ ├─ YES → Will it have a local ASBR? │ │ │ ├─ YES → Use NSSA │ │ │ │ │ └─ Also need to minimize Type-3? │ │ │ │ │ ├─ YES → Use TOTALLY STUBBY NSSA │ │ └─ NO → Use NSSA │ │ │ └─ NO → Does it need specific external routes from backbone? │ │ │ ├─ YES → Use STANDARD │ └─ NO → Use STUB │ └─ NO → Does it need specific inter-area routes? │ ├─ YES → Use STUB (blocks Type-5 only) │ └─ NO → Can it use just a default route? │ ├─ YES → Use TOTALLY STUBBY └─ NO → Use STUB ═══════════════════════════════════════════════════════════════════════════ Summary Table:─────────────────────────────────────────────────────────────────────────────Requirement │ Area Type─────────────────────────────────────┼───────────────────────────────────────Transit for all traffic, all routes │ STANDARD (or Backbone)Block external routes only │ STUBBlock external + inter-area routes │ TOTALLY STUBBYBlock external but have local ASBR │ NSSABlock external + inter-area, + ASBR │ TOTALLY STUBBY NSSA─────────────────────────────────────┴───────────────────────────────────────Common Deployment Patterns:
| Location Type | Typical Characteristics | Recommended Area Type |
|---|---|---|
| Data Center | High bandwidth, many routes, multiple exit points | Standard (or Backbone) |
| Campus Building | Medium complexity, needs inter-area visibility | Standard or Stub |
| Remote Branch (single link) | Simple topology, single exit | Totally Stubby |
| Branch with local Internet | Simple, but has local ISP | NSSA or Totally Stubby NSSA |
| DMZ/Guest Network | Isolated, minimal routing needs | Totally Stubby |
| Legacy Network Integration | Needs specific external routes | Standard or NSSA |
When unsure, start with standard areas. You can always convert to stub/NSSA later if scaling becomes an issue. Converting requires changing all routers in the area simultaneously (maintenance window), but it's straightforward. Going the other direction (stub→standard) is equally easy.
We've explored OSPF area types comprehensively—from the mandatory backbone through stub areas to NSSA. Let's consolidate the key concepts:
What's Next:
Understanding area types leads naturally to Route Summarization. ABRs can summarize Type-3 LSAs to further reduce routing table sizes, and ASBRs can summarize external routes. Effective summarization combined with proper area design creates highly scalable OSPF networks.
You now have comprehensive knowledge of OSPF area types and their appropriate use cases. This understanding is essential for designing scalable networks, optimizing routing table sizes, and troubleshooting inter-area routing issues. The right area type choice can dramatically improve network performance and manageability.