OSPF has six kinds of areas: standard, backbone, stub, totally-stubby, NSSA (Not-So-Stubby Area), and totally-stubby NSSA. If you've stared at a table listing them and still can't remember which is which — this post is the walkthrough your CCNA book didn't give you.
We'll go Socratic. At each step, I'll ask you what you'd expect. Then I'll tell you what OSPF actually does and why.
The one-line framing: OSPF area types are a filtering tradeoff. You get less LSA flooding (less CPU, less memory, less bandwidth) in exchange for less granular routing information. Every area type on the list is a different filtering choice. Understanding that tradeoff is the entire topic.
Why Areas Exist At All
Imagine a router running OSPF in a network with 500 other routers. Every link flap anywhere in the network generates an LSA. That LSA floods to every router. Every router reruns SPF. On a 500-router network, that's catastrophic — CPU spikes, routing table churn, neighbor timeouts.
Ask yourself: How would you solve this?
The answer OSPF chose is areas. You partition the network into logical zones. Within an area, routers see every link flap in full detail (Type 1 and Type 2 LSAs). At area boundaries, a router called the ABR (Area Border Router) summarizes what it knows into a compressed form and floods only the summary (Type 3 LSA) to neighboring areas.
Result: a link flap in area 10 causes full LSA flooding inside area 10 but only a summary LSA change in areas 0, 20, and 30. The blast radius shrinks from the whole network to one area.
Now the question becomes: how much summarization, and where?
Standard Area
A standard area receives every LSA type. Full detail. Maximum routing granularity. Maximum LSA flood.
You use standard areas when you need every route installed with full precision — typically internal routing areas in a medium-sized organization. Also: area 0 is always effectively standard (though we call it "backbone"), because area 0 is where all other areas plug into.
LSAs received by a standard area:
- Type 1 (Router) — every router in the area
- Type 2 (Network) — DR-generated for broadcast segments
- Type 3 (Summary) — inter-area routes from the ABR
- Type 4 (ASBR-Summary) — pointer to where external routes enter the network
- Type 5 (External) — redistributed external routes (e.g., BGP, static)
Backbone (Area 0)
Ask yourself: Why must OSPF have an area 0?
Because the ABR summarization trick only works if all inter-area traffic flows through a consistent hub. OSPF's hub is area 0 (the backbone). Every non-backbone area must connect to area 0, either directly (an ABR with an interface in both) or via a virtual link (a CCNP-level topic).
Area 0 is a standard area — it receives all LSA types. What's special about it is the topological requirement: without a well-connected area 0, OSPF's multi-area design breaks down (you get suboptimal routing or routing loops).
Stub Area
A stub area asks: do my routers really need Type 5 external LSAs?
If your stub area is a branch office with a single exit to the rest of the network — the answer is no. Every external route (redistributed from BGP, for example) leads to the same place: out the ABR. So the ABR replaces all Type 5 LSAs with a single default route (Type 3 LSA, 0.0.0.0/0).
What stub areas receive:
- Type 1, Type 2 (internal)
- Type 3 (inter-area summaries)
- A default route (Type 3 for 0.0.0.0/0) instead of Type 5 externals
- Blocked: Type 5 External LSAs
Ask yourself: What's the tradeoff?
Smaller LSDB. Less SPF work. You give up the ability to choose between multiple external exits — but if there's only one exit, that capability is useless anyway.
Totally-Stubby Area
If stub was "no externals," totally-stubby is "no externals and no inter-area details."
What totally-stubby areas receive:
- Type 1, Type 2 (internal)
- A single default route for everything outside the area
- Blocked: Type 3 inter-area summaries + Type 5 externals
Why would you want this? Even smaller LSDB. For a branch office that doesn't care which specific subnet in headquarters a packet is destined for (because the answer is always "go to the ABR"), totally-stubby removes routing table bulk with no practical downside.
Gotcha: totally-stubby is Cisco proprietary — it's configured by adding no-summary to the area 1 stub config. It works in Cisco multi-vendor environments that accept Cisco's extension, but not all OSPF implementations respect it. Know this for CCNP/CCIE.
NSSA (Not-So-Stubby Area)
Here's where it gets interesting. You want a stub area (no Type 5), but you also need to redistribute routes into OSPF from a local source — say, an eBGP session with an ISP that terminates on one of your area routers.
A stub area can't have an ASBR because ASBRs generate Type 5 LSAs, and stub areas block Type 5. But you still need those redistributed routes to propagate out of the area.
OSPF's solution: Type 7 LSAs. An NSSA allows a local ASBR to generate Type 7 LSAs (which behave like externals but stay inside the NSSA). At the ABR, Type 7 LSAs are translated to Type 5 and flooded to the rest of the OSPF domain.
What NSSAs receive:
- Type 1, Type 2, Type 3
- Type 7 (generated locally from redistributed routes)
- Blocked: Type 5 from elsewhere
- Exit: a default route from the ABR (optional, configured)
The "not so stubby" name: it's stubby (no Type 5 inbound) but not fully stubby (it allows Type 7 outbound). Hence NSSA.
Totally-Stubby NSSA
Same trick as totally-stubby standard. Block Type 5 and Type 3 inbound. Still allow Type 7 outbound. Configured with area X nssa no-summary on Cisco.
You now have the full set. Six area types. The progression is:
- Standard — receives everything
- Backbone (area 0) — the hub; topologically required
- Stub — no Type 5
- Totally-stubby — no Type 5, no Type 3
- NSSA — no Type 5 (inbound), but generates Type 7 (outbound for local redistribution)
- Totally-stubby NSSA — no Type 5, no Type 3, generates Type 7
The Decision Tree
When you design OSPF, ask three questions in order:
- Does this area need to connect to area 0? Yes — every non-backbone area does. Either physically (share an ABR) or via a virtual link.
- Does this area have a local route source (BGP, static, other protocol) to redistribute? Yes → NSSA. No → Stub.
- Does this area need to see every inter-area subnet, or is a default route enough? Needs detail → keep normal/stub/NSSA. Default is enough → use the "totally-stubby" variant.
That's it. The six area types are just combinations of those three yes/no questions.
Where Cisco Packet Tracer Teaches This Well — and Where It Doesn't
For Type 1, Type 2, and Type 3 LSAs, Cisco Packet Tracer is a reasonable teaching simulator. You can build a two-area topology, watch show ip ospf database change as you add networks, and see inter-area summaries appear and disappear.
For Type 5 LSAs and NSSA Type 7 translation, Cisco Packet Tracer's simulation is simplified — the show ip ospf database external output is cleaner than real IOS, some attributes are collapsed, and the Type 7 → Type 5 translation at the NSSA ABR sometimes doesn't reflect the full P-bit behavior. For fundamentals, it works. For CCNP-level scenarios, verify on real IOS.
If you want to see the full LSA database as real IOS shows it — upload your Cisco Packet Tracer .pkt lab to NetPilot, re-export as a ContainerLab variant on real Cisco IOL, and SSH into the ABR. The show ip ospf database output is the unabridged version. Time from .pkt to real IOS: ~2 min.
FAQ
What's the difference between stub and totally-stubby OSPF areas?
Stub blocks only Type 5 (external) LSAs and replaces them with a default route. Totally-stubby additionally blocks Type 3 (inter-area summary) LSAs and replaces everything outside the area — externals and other-area subnets — with a single default route. Totally-stubby is a Cisco extension configured with the no-summary keyword on the ABR.
Why does OSPF require a backbone area 0?
OSPF's ABR summarization only produces loop-free, optimal routing if every non-backbone area connects to a single backbone. Area 0 is that backbone. Without it, you'd need full mesh of summary LSAs between every pair of areas — which defeats the point of hierarchical design. If a non-backbone area can't physically connect to area 0, you use a virtual link through an intermediate area to create a logical connection.
When would I use an NSSA instead of a stub area?
Use an NSSA when the area has a local router performing route redistribution (an ASBR) — for example, an eBGP session with an ISP, or static routes being redistributed into OSPF. Stub areas can't have ASBRs because they block Type 5. NSSAs allow Type 7 locally for the redistributed routes, then the ABR translates Type 7 → Type 5 for the rest of the OSPF domain.
Are totally-stubby areas standard OSPF?
Totally-stubby is a Cisco proprietary extension (RFC 2328 defines stub, not totally-stubby). Most enterprise vendors (Juniper, Arista, Nokia) respect the Cisco no-summary behavior for interoperability, but strict RFC-compliant implementations treat a totally-stubby configuration as a regular stub. Know this for CCIE; for CCNA the Cisco implementation is what's tested.
How does Cisco Packet Tracer handle OSPF NSSA and Type 7 LSAs?
Cisco Packet Tracer supports NSSA configuration and simulates Type 7 → Type 5 translation at a basic level. Advanced behaviors (P-bit handling, default-information originate variations in NSSA, totally-stubby NSSA) are simplified in PT compared to real IOS. For CCNA fundamentals PT is sufficient; for CCNP-level NSSA practice, use real Cisco IOL via CML, GNS3, or NetPilot.
Related reading
- Why Did My OSPF Lab Work in Cisco Packet Tracer but Fail on Real Routers? — six specific OSPF divergences
- Cisco Packet Tracer vs Real IOS Cheat Sheet — protocol-by-protocol divergences
- Hardest CCNA Topics — where students struggle
- CCNA Practice Lab — NetPilot's CCNA-focused product page
- Packet Tracer AI Tutor — import
.pkt, get step-by-step explanations
Copy-paste ready: Practice OSPF multi-area on real Cisco IOL with the OSPF Single Area prompt as your starting point.
Want to see LSA Types 1-7 the way real IOS shows them? Open NetPilot — build a multi-area OSPF lab in ~2 min, SSH into the ABR, run show ip ospf database.