Single-area OSPF works. Right up until it doesn't. Drop fifty routers into area 0, watch the LSDB swell, watch SPF runtime climb on every link flap, watch one flaky interface in a far corner flood updates that ripple to every device in the domain — and you start to understand why areas exist.
This article is the conceptual half of Lab 8 — OSPF Multi-Area. The lab is where you build a backbone, three ABRs, and a fourth router in interface-mode and watch the LSDB partition with your own eyes. This is what's actually in that LSDB — the LSA types, what each one carries, who originates it, where it floods, and the exam trivia about all of them that the CCNA loves to pull on.
If you haven't read the OSPF concepts article yet, start there — link-state, LSDB, SPF, neighbour vs adjacency. Adjacency states is the troubleshooting companion. This piece picks up after those: you've got a single-area OSPF you can build in your sleep, and now you want to know what the next jump up looks like.
★ THE THREE THINGS AREAS ACTUALLY DO
"Areas reduce the size of the topology table" is the answer the exam wants. The honest answer is that areas cut three different costs at the same time, and which one matters most depends on what's killing your network.
In one area, every router holds an identical copy of every link in the domain. In multi-area, each router holds only its own area's type-1/type-2 LSAs, plus condensed type-3 summary LSAs from the ABRs. A 200-router domain with five areas of 40 each isn't a 200-router database on every router — it's a 40-router database plus a handful of summary entries. Memory pressure drops, route-table lookups speed up.
SPF runtime is O(n log n) on the area's link count. Cut n and you cut runtime — and SPF runs on every router for every topology change in its area. On a 500-router single-area domain, one flaky port runs SPF 500 times. In multi-area, most routers never even see the change.
A link flap in area 2 floods type-1 LSAs only inside area 2. The ABR re-originates a type-3 summary into the backbone only if the summary itself changed — and most internal flaps never change the summary. Sitewide flooding goes away. Bandwidth on transit links stops getting eaten by every internal hiccup.
Big-picture: multi-area is how OSPF scales past "enough routers that you'd remember their names." The three wins above are the reason ISP backbones, large campus networks, and basically every real deployment of OSPF carves the domain up. Single-area is fine for the lab and the exam scenario where you only have four routers. It is not fine for the network you'll actually inherit on day three at the job.
★ THE BACKBONE RULE
Area 0 is the backbone. It always exists. Every non-backbone area must touch area 0 through at least one Area Border Router (ABR). A non-backbone area connected only to another non-backbone area is invisible from the rest of the domain — its routes don't propagate, the backbone never learns its summaries, and the design is broken. (You can fake it with a virtual link across an intermediate area, but that's a CCNP workaround, not a design pattern.)
So if you're sketching an OSPF topology and you've got area 1 hanging off area 2 hanging off area 0 — stop. Move area 1 to connect directly to area 0, or accept that area 1 is going to be unreachable. The "hub-and-spoke" mental model is the right one: area 0 is the hub, every other area is a spoke that plugs straight into it.
This is why ABRs matter: an ABR is, by definition, a router with interfaces in two or more areas, one of which is area 0. A router with interfaces in area 2 and area 5 only is not an ABR — it's just a broken design.
★ ROUTER ROLES IN OSPF
Four roles, distinguished by where the router lives in the topology and what it advertises. The exam will hand you a topology diagram and ask which router is which. Burn these in.
| ROLE | WHERE IT SITS | WHAT IT DOES |
|---|---|---|
| Internal router | All interfaces in the same non-backbone area. | Runs OSPF in one area. Knows that area's topology in detail; sees other areas only as type-3 summaries. |
| Backbone router | At least one interface in area 0. | Carries the backbone. May or may not also be an ABR. |
| ABR (Area Border Router) | Interfaces in two or more areas, one of which is area 0. | Originates type-3 summary LSAs. Translates between areas. Holds a separate LSDB per area it touches. |
| ASBR (Autonomous-System Boundary Router) | Redistributes routes from outside OSPF into OSPF. | Originates type-5 external LSAs (or type-7 in an NSSA). The "gateway" between OSPF and another routing source. |
A router can wear more than one hat at once. The router that connects your OSPF domain to a BGP peer at the WAN edge might be a backbone router + ABR + ASBR simultaneously. Roles describe what a router does, not what it's called in the config.
ABR connects two OSPF areas. ASBR connects OSPF to something that isn't OSPF. A router redistributing static routes into OSPF is an ASBR. A router with G0/0 in area 0 and G0/1 in area 5 is an ABR. A router doing both is both. The CCNA loves a question that includes one of each and asks you to label the right router.
★ THE LSA TYPES — THE MEAT
OSPFv2 defines eleven LSA types in the RFC. CCNA cares about six of them. We'll cover the six, skip one (type 6 is multicast OSPF, dead protocol, not on the exam, not in any modern deployment), and mention the rest only for completeness.
TYPE 1 — ROUTER LSA
Originated by: Every router, for every area it has interfaces in.
Carries: A list of every directly connected link on this router in this area, with cost and link type. "Here is the part of the topology I'm responsible for."
Floods within: Its own area only. Stops at the ABR.
Link ID: The originating router's router-ID.
Type 1 is the foundation. Every router originates one type-1 LSA per area, which is why an ABR shows up twice in show ip ospf database router — once in area 0, once in its non-backbone area. The contents are different (different interfaces face different areas), but the router-ID matches.
TYPE 2 — NETWORK LSA
Originated by: The Designated Router (DR) on a multi-access network (Ethernet LAN with more than one OSPF router).
Carries: The list of routers attached to this multi-access network. "Here are the routers sharing this LAN."
Floods within: Its own area only.
Link ID: The IP address of the DR's interface on this network.
Type 2 only exists on multi-access segments with two or more OSPF routers. Point-to-point links don't generate type-2 LSAs. If your topology is all P2P (which most modern multi-area designs are), you'll see zero type-2 LSAs in show ip ospf database. That's not a bug — that's the design.
TYPE 3 — SUMMARY LSA (INTER-AREA)
Originated by: ABRs.
Carries: "I, the ABR, can reach this prefix at cost N — but I'm not telling you how." A condensed summary of a network in another area. No topology detail, just reachability + cost.
Floods within: The receiving area. The ABR sends a type-3 into each area it touches, advertising prefixes from the other areas.
Link ID: The destination prefix.
Type 3 is how the four leaf LANs in Lab 8 reach each other. R10's area-1 LAN gets summarised into area 0 as a type-3, then R30 re-originates that type-3 into area 3 so PCs in area 3 know how to reach 192.168.10.0/24. The LSA never carries the area-1 internal topology — area 3's routers see "reachable at cost X" and nothing else.
In the route table, type-3-learned prefixes show up as O IA — OSPF Inter-Area. That two-letter prefix is the giveaway: this route came from a summary LSA, not from a type-1 in your own area.
TYPE 4 — ASBR SUMMARY LSA
Originated by: ABRs.
Carries: "I, the ABR, can reach this ASBR at cost N." A summary advertising the router-ID of an ASBR living in another area.
Floods within: Every area except the ASBR's own area (where it's not needed) and stub-style areas (which block externals entirely).
Link ID: The router-ID of the ASBR being advertised.
Type 4 is the exam's favourite tricky LSA. The logic: if an ASBR redistributes an external route as a type-5 LSA, that type-5 is meaningless to a router in another area unless that router knows how to reach the ASBR itself. The type-4 LSA is what carries that reachability across area boundaries.
If type-4 LSAs are filtered or missing, routers in other areas will see the type-5 external route in their LSDB but won't install it in the route table — they can't resolve the ASBR's router-ID to a forwarding next-hop. Classic CCNA gotcha. Whenever you see externals showing up in show ip ospf database but not in show ip route, your first thought should be type-4.
TYPE 5 — EXTERNAL LSA
Originated by: ASBRs.
Carries: A redistributed route — a prefix that didn't originate in OSPF (static, connected redistributed, BGP, EIGRP, etc.). Includes the external cost and metric type (E1 vs E2).
Floods within: The entire OSPF domain — every area except stub-style areas (stub, totally stubby, NSSA).
Link ID: The external prefix.
Type 5 is how OSPF carries routes from outside the OSPF domain. The classic example: a static default route on the ASBR, redistributed into OSPF with default-information originate. Every router in every normal area gets the type-5, learns the 0.0.0.0/0 with the ASBR as the ultimate origin, and installs it as O*E2 in the route table.
Route-table prefix: O E1 or O E2. E2 (the default) means the metric stays the same across the OSPF domain — the cost you see is the cost the ASBR advertised, no per-hop additions. E1 adds the internal OSPF cost to the external cost, so the metric grows with distance from the ASBR. Use E1 if you want OSPF's normal cost calculation to influence external route choice; use E2 (the default) if you trust the external cost as-is.
TYPE 7 — NSSA EXTERNAL LSA
Originated by: ASBRs inside an NSSA (Not-So-Stubby Area).
Carries: Same content as a type-5 — a redistributed external route. Different type number because regular stub areas would block a type-5 outright; NSSA needs a different LSA type that's allowed inside it.
Floods within: The NSSA only. At the NSSA's ABR, it's translated to a type-5 and re-injected into the backbone.
Link ID: The external prefix.
Type 7 exists only because somebody, somewhere, needed to redistribute externals from inside a stub area. NSSA is the workaround: a stub-like area that allows local externals via type-7, then converts them to type-5 at the ABR boundary so the rest of the domain learns about them normally. Niche, but on the CCNA blueprint.
Type 6 was Multicast OSPF (MOSPF). Effectively dead protocol — replaced by PIM everywhere it mattered. Not on the CCNA, not in any modern deployment. The CCNA blueprint jumps straight from 5 to 7. If a question lists "type 1 through 7" verbatim, type 6 still belongs in the count but its content isn't testable.
★ HOW LSAs MOVE — THE FIVE OSPF PACKETS
LSAs are the cargo. They don't fly through the air on their own — they ride inside OSPF packets, of which there are exactly five. Don't confuse the LSA types you just read (the contents of the database) with the OSPF packet types (the transport that moves database entries between routers). They have separate numbering schemes and serve different layers.
| PKT | NAME | JOB | SEEN IN STATE |
|---|---|---|---|
| 1 | Hello | Discover neighbours, maintain the relationship, elect DR/BDR. | DOWN → INIT → 2-WAY, then forever |
| 2 | DBD (Database Description) | Trade summaries of what's in each side's LSDB — headers only, no full LSA content. | EXSTART → EXCHANGE |
| 3 | LSR (Link-State Request) | "You mentioned LSA X in your DBD — send me the full copy." | LOADING |
| 4 | LSU (Link-State Update) | The truck. Carries one or more actual LSAs — replies to LSRs and floods new/changed LSAs sitewide. | LOADING, then on every change |
| 5 | LSAck (Link-State Acknowledgement) | "Got your LSU." Confirms receipt so the sender stops retransmitting. | Any time an LSU arrives |
If you've read the adjacency-states article, the right-hand column should look familiar — every state in the OSPF state machine is named after the packet types being exchanged at that moment. Hellos build neighbour relationships. DBDs sync the headers. LSRs and LSUs trade the actual LSA payloads. LSAcks close the loop so nothing gets retransmitted forever.
When a router originates a new LSA (or one in its database changes), the LSA is wrapped in an LSU packet and sent to the relevant neighbours. Each neighbour replies with an LSAck. The neighbour then re-floods the LSU out its other adjacencies (subject to the LSA's flooding scope — area-local for type-1/2, sitewide for type-5, etc.). This is the reliable flooding OSPF is built on: every LSU is acknowledged, so a dropped packet doesn't silently desync the database.
The takeaway for the CCNA: when you read "type-3 summary LSA floods into area 1," what's physically happening is the ABR packs that type-3 into an LSU packet, sends it out the area-1 interfaces, every area-1 neighbour LSAcks it, and they all install it in their area-1 LSDB. The LSA is what the database stores; the LSU is what crossed the wire.
★ FLOODING SCOPE — ONE TABLE
This is the single most testable table in the whole multi-area chapter. Memorize it cold.
| TYPE | NAME | ORIGINATOR | FLOODING SCOPE |
|---|---|---|---|
| 1 | Router | Every router | Within area only |
| 2 | Network | DR on multi-access | Within area only |
| 3 | Summary (inter-area) | ABR | All areas except totally stubby |
| 4 | ASBR Summary | ABR | All areas except stub-style |
| 5 | External | ASBR | All areas except stub-style |
| 7 | NSSA External | ASBR (inside NSSA) | NSSA only (translated to type-5 at ABR) |
The pattern: type 1 and 2 stay inside their area — they describe the area's internal topology and nobody outside needs that detail. Type 3 and 4 are ABR-originated summaries — they're the bridge between areas. Type 5 and 7 carry externals — type 5 floods almost everywhere, type 7 lives inside an NSSA until the ABR converts it.
★ READING SHOW IP OSPF DATABASE
This is the command. Everything above shows up in it. Run it on an ABR for the full effect — the output is broken into sections by area, then by LSA type. From Lab 8, on R10 (ABR into area 1):
What's interesting: R10 is an ABR, so its database lists both area 0 and area 1. In area 0, the type-3 summaries for the leaf LANs come from each leaf's own ABR (R20 originates 192.168.20.0, R30 originates 192.168.30.0, R40 originates 192.168.40.0). In area 1, R10 itself originates type-3 summaries for everything outside area 1, condensing the rest of the world into reachability advertisements.
"Link ID" means different things for different LSA types. For type 1 it's the originating router's router-ID. For type 3 it's the destination prefix being summarised. For type 4 it's the ASBR's router-ID. For type 5 it's the external prefix. The column heading doesn't change, but the meaning does — that's why show ip ospf database can feel disorienting at first.
Filter by type when you're hunting for something specific:
★ STUB, TOTALLY STUBBY, NSSA — ONE PARAGRAPH EACH
OSPF area variants exist to cut more LSA types out of an area than the default multi-area config does. Each one is a tradeoff: less LSDB pressure on the routers inside, but the routers lose the ability to learn certain prefix types directly. CCNA wants you to know they exist and what each one blocks.
Blocks type-5 (external) LSAs at the ABR. Routers inside the stub still learn type-3 inter-area summaries normally. To reach external destinations, the stub ABR auto-injects a default route as a type-3 summary. Use case: branch sites where you don't care about specific external routes — just send everything unknown back to the WAN.
Stub + blocks type-3 inter-area summaries too. The only OSPF route inside a totally stubby area is the default route the ABR injects. Maximum LSDB compression. Cisco proprietary keyword: area X stub no-summary. Use case: tiny branches where even inter-area detail is too much.
Stub area that also needs to redistribute its own externals (because there's an ASBR sitting inside it that has to talk to a non-OSPF neighbour). Type-5 still blocked; local externals carried as type-7 and converted to type-5 at the ABR. Niche but elegant — solves the "we need a stub area but we also have a static-redistribution requirement here" problem without compromising the rest of the design.
Stub areas are CCNA-blueprint material but you'll rarely deploy them in a homelab. Worth recognising the syntax in show ip ospf output and knowing what each variant blocks. Beyond that, this is more of a "see it once, remember the shape" topic than something to grind on.
★ CCNA EXAM GOTCHAS
Type 1 = intra-area, originated by every router, describes the area's topology. Type 3 = inter-area, originated by ABRs, condenses other areas into "reachable at cost N." The question on the exam will hand you a prefix and ask which LSA type would carry it. Inside its home area → type 1. Outside → type 3.
If the topology is P2P (point-to-point links between routers), there are zero type-2 LSAs. If the question says "all links are point-to-point" and then asks about type 2, the answer is "none originated." Don't pattern-match on the diagram having a switch in it — what matters is whether OSPF sees the network as multi-access.
If a router sees a type-5 external in its LSDB but can't install the route in the table, the type-4 ASBR summary is missing. The receiving router knows the external prefix exists but can't resolve the ASBR's router-ID to a next-hop. Look for ABR config that filters or summarises away the type-4.
Topology question, with one router that has G0/0 in area 0 and G0/1 in area 5, plus another router redistributing static routes into OSPF. Label them. The first is the ABR. The second is the ASBR. A router that does both gets both labels — they're not mutually exclusive.
The exam may show a topology with an area that doesn't touch area 0 and ask how to make it reachable. "Virtual link across an intermediate area" is the technically-correct answer, but in real life you'd redesign instead. Know the term, know what it does (extends area 0 across a transit area), don't expect to use it.
★ BUILD IT — LAB 8
Reading about type-3 summaries is one thing. Watching them appear in show ip ospf database after you bring up an ABR is another. Lab 8 — OSPF Multi-Area is the build that makes all of the above real: four leaf areas hanging off a backbone, three ABRs with loopback router-IDs, one router configured in interface-mode, end-to-end ping across every area boundary, and a verification section that walks you through reading every LSA type that appears in the topology.
show ip ospf database with one command. Build the lab and watch the type-3 summaries appear as each ABR comes up.
Network Warrior (Gary Donahue) is the real-world OSPF companion — what these LSA types actually look like in a production carrier network. Amazon affiliate.