Every OSPF area type question comes down to one thing: which LSAs does this area type actually block? Most explanations answer with a list, and lists are easy to memorise and easy to get backwards. That is why plenty of engineers who can recite "stub blocks Type 5" cannot explain why a branch router lost every inter-area route the morning after somebody appended no-summary on the ABR.
So this article does not assert what gets filtered, it shows you. One internal router, one area, stepped through stub, totally stubby and NSSA while the same box dumped its link-state database and routing table at every stage. You watch specific LSAs disappear, watch the routing table shrink to one line, and watch the default route change its route code depending on which area type produced it.
Everything below is captured output from three IOL-XE routers running IOS XE 17.18.2 in Cisco Modeling Labs, taken on 2026-07-20. If the layer underneath this is still fuzzy, the complete OSPF configuration guide covers adjacencies, costs and areas first, and this page assumes you already have a multi-area design working.
What this was captured on
Three routers, one ABR, one ASBR, and one very ordinary internal router whose life keeps changing:
Area 1 (the area under test) Area 0 (backbone)
+-------------+ +-------------+ +-------------+
| R1 | 10.0.12.0/30 | R2 | 10.0.23.0/30 | R3 |
| 1.1.1.1 |----------------| 2.2.2.2 |----------------| 3.3.3.3 |
| internal | Et0/0 Et0/0| ABR |Et0/1 Et0/0| ASBR |
| Lo0 1.1.1.1 | | area 0 + 1 | | Lo0 3.3.3.3 |
+-------------+ +-------------+ +-------------+
ip route 172.16.99.0/24 Null0
redistribute static -> Type-5
R3 redistributes a static route for 172.16.99.0/24, which makes it an ASBR and puts a genuine Type-5 external into the domain. That prefix is the test packet for the whole article: whether R1 can see it tells you immediately whether R1's area blocks external LSAs.
R1 is the router we watch. No special role: it is the branch router, the box you were trying to protect when you decided to make the area stubby.
The captures came from on-box EEM applets: one set reconfigured area 1 through each type on a timer, another dumped R1's LSDB and RIB to syslog at each stage. Everything below is what the device printed. One artefact is covered in the gotchas: converting the area to NSSA briefly reset the R1 to R2 adjacency before it reconverged.
OSPF area types at a glance
Five area types, and the only thing separating them is which LSA types the ABR will flood into the area, plus what it substitutes for the ones it withholds.
nonearea X stubevery router
area X stub no-summaryABR only
area X nssaevery router
area X nssa no-summaryABR only
Type-4 never appears in that list for a stubby area type, and that is not an oversight. A Type-4 ASBR summary exists purely so routers in other areas can reach an ASBR and resolve a Type-5. Kill the Type-5 and the Type-4 has nothing to point at, so the ABR stops generating it. For the full picture of what each OSPF LSA type actually carries, that is a separate walk through the database. Here we only care which ones survive the ABR.
Normal area: the baseline you are giving up
Before shrinking anything, look at what a normal area gets. Area 0 in this lab is a normal area throughout the run, and R3 is sitting in it with its own redistributed static route. Here is the Type-5 that R3 originated, seen from R3 itself:
R3# show ip ospf database external
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
LS age: 321
LS Type: AS External Link
Link State ID: 172.16.99.0 (External Network Number )
Advertising Router: 3.3.3.3
LS Seq Number: 80000001
Network Mask: /24
Metric Type: 2
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
That is the ordinary case. An ASBR redistributes something, OSPF wraps it in a Type-5, and the Type-5 floods everywhere except into areas told to refuse it. Metric type 2 is the IOS default, so the cost stays at 20 no matter how far the LSA travels. If the redistribution mechanics are new, the walkthrough on how redistribution turns non-OSPF routes into externals covers the seed metrics and filtering that decide what ends up in a Type-5.
Keep 172.16.99.0/24 in mind. From here on, every area type we configure on area 1 is judged partly by whether R1 can still see it.
Stub areas: no externals, have a default instead
A stub area tells the ABR to stop flooding Type-5 externals in and to originate a default route instead, so the area can still reach whatever those externals pointed at. The trade is exact: per-prefix knowledge of external destinations for one 0.0.0.0/0.
Configuration
Every router in the area needs the command. This is not optional and it is not cosmetic, because the stub flag lives in the hello packet and mismatched routers will not form an adjacency at all.
! R1 (internal) and R2 (ABR), both of them
router ospf 1
area 1 stubThree rules, each of them a real deployment blocker:
- Every router in the area must be configured as stub, ABR included.
- No ASBR can live inside a stub area. There is nowhere for its Type-5 to go, so IOS will not let you redistribute into OSPF from inside one.
- Area 0 cannot be a stub area, and neither can a transit area carrying a virtual link.
What the database looks like
This is R1's full LSDB with area 1 configured as a stub:
R1# show ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 47 0x80000004 0x00805C 2
2.2.2.2 2.2.2.2 44 0x80000005 0x00FCE9 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.12.2 2.2.2.2 51 0x80000001 0x00CA48
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 2.2.2.2 95 0x80000001 0x0075C0 <-- default injected by ABR (Type-3)
3.3.3.3 2.2.2.2 46 0x80000001 0x004FD0 <-- inter-area summary
10.0.23.0 2.2.2.2 95 0x80000001 0x003DD1 <-- inter-area summary
Read what is missing as carefully as what is present. There is no "Type-5 AS External Link States" section at all. R3's 172.16.99.0/24 exists in the backbone and R2 knows about it perfectly well, it just refuses to flood it into area 1. No Type-4 section either, for the reason above.
What did arrive is a Summary Net section with three Type-3 LSAs, all advertised by 2.2.2.2. Two are ordinary inter-area summaries for R3's loopback and the backbone transit link. The third, Link ID 0.0.0.0, is the default, and note the mechanism: a stub ABR sends the default as an ordinary Type-3. That detail explains the route code you are about to see.
What the routing table looks like
R1# show ip route ospf
Gateway of last resort is 10.0.12.2 to network 0.0.0.0
O*IA 0.0.0.0/0 [110/11] via 10.0.12.2, 00:00:50, Ethernet0/0 <-- default as Inter-Area (stub default)
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/21] via 10.0.12.2, 00:00:45, Ethernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA 10.0.23.0/30 [110/20] via 10.0.12.2, 00:00:50, Ethernet0/0
O*IA is the tell. O for OSPF, * for candidate default, IA because it arrived inter-area, which is exactly what a Type-3 produces. The two O IA entries are the other Type-3s resolving into routes. Not a single O E1 or O E2 anywhere, which is the whole point.
The metric of 11 is worth a glance: IOS advertises the stub default with a cost of 10 and R1 adds its own link cost. Change it with area 1 default-cost on the ABR, which matters when an area has two ABRs and you would rather traffic left through one of them.
Totally stubby: also drop the inter-area summaries
A stub area still carries a Type-3 for every prefix in every other area, which on a large network is most of the database. Totally stubby (a Cisco extension, not in the standard) tells the ABR to suppress those summaries too, leaving the area with its own topology and a way out.
Configuration
! R2 (the ABR) ONLY
router ospf 1
area 1 stub no-summary
! R1 and every other internal router: unchanged
router ospf 1
area 1 stubno-summary is an ABR-only instruction. It changes what that ABR originates, and internal routers have no say in it, so they keep the plain area 1 stub command. Adding it on an internal router is harmless (it has no summaries to suppress) but misleading to whoever reads the config next.
The database after no-summary
R1# show ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 137 0x80000004 0x00805C 2
2.2.2.2 2.2.2.2 134 0x80000005 0x00FCE9 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.12.2 2.2.2.2 141 0x80000001 0x00CA48
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
0.0.0.0 2.2.2.2 54 0x80000002 0x0073C1 <-- ONLY the default remains
Compare that Summary Net section to the previous one. The 3.3.3.3 and 10.0.23.0 entries are gone, leaving a single Type-3 for 0.0.0.0 whose sequence number ticked from 0x80000001 to 0x80000002 when the ABR reoriginated it. The Router and Net LSA sections are identical to the stub capture, which is correct: no area type ever filters Type-1 or Type-2, because those describe the area's own topology and SPF would be meaningless without them.
The routing table after no-summary
R1# show ip route ospf
Gateway of last resort is 10.0.12.2 to network 0.0.0.0
O*IA 0.0.0.0/0 [110/11] via 10.0.12.2, 00:02:21, Ethernet0/0 <-- ONLY a default route
One line. That is the entire OSPF contribution to this router's routing table. For an access router hanging off a single uplink it is exactly what you want: R1 no longer reloads its database when a prefix somewhere else in the network flaps, because it was never told about that prefix.
The cost is optimality. With only a default, R1 cannot prefer one ABR over another per destination, so in a dual-ABR area traffic for a prefix behind ABR-B may still leave through ABR-A because ABR-A was closer. On a single-uplink branch that is a non-issue; on a distribution block with two upstreams it is the main reason people stop at plain stub. The wider trade-offs are in why OSPF splits a network into areas at all.
NSSA: a stub area that is allowed to have its own ASBR
Both stub flavours share one hard restriction: no ASBR inside the area. That falls apart the moment a branch has a firewall running BGP, a legacy EIGRP island, or a static route somebody needs advertised. You want the LSDB reduction of a stub area and you also need to inject a couple of external prefixes locally.
NSSA, defined in RFC 3101, is the answer. It still blocks Type-5 LSAs from the backbone, but adds a new type, Type-7, that carries locally originated externals inside the area. The ABR translates Type-7 into Type-5 on the way out, so the rest of the domain sees an ordinary external.
Configuration
! R1 and R2, every router in the area
router ospf 1
no area 1 stub
area 1 nssa
! R1 additionally becomes the NSSA ASBR
ip route 172.16.11.0 255.255.255.0 Null0
router ospf 1
redistribute static subnets
! R2 (ABR) if you want the area to receive a default
router ospf 1
area 1 nssa default-information-originateAn area cannot be both stub and NSSA, so converting a live one means removing one flag and adding the other. The gotchas cover what that does to the adjacency.
The Type-7 LSA in detail
This is where NSSA stops being abstract. show ip ospf database nssa-external on R1, once it was redistributing 172.16.11.0/24:
R1# show ip ospf database nssa-external
OSPF Router with ID (1.1.1.1) (Process ID 1)
Type-7 AS External Link States (Area 1)
LS age: 83
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 0.0.0.0 (External Network Number )
Advertising Router: 2.2.2.2 <-- NSSA default from the ABR
LS Seq Number: 80000001
Checksum: 0xD0D8
Length: 36
Network Mask: /0
Metric Type: 2 (Larger than any link state path)
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 0
LS age: 78
Options: (No TOS-capability, Type 7/5 translation, DC, Upward) <-- P-bit set
LS Type: AS External Link
Link State ID: 172.16.11.0 (External Network Number )
Advertising Router: 1.1.1.1 <-- R1's own redistributed external
LS Seq Number: 80000001
Checksum: 0x685E
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
Metric: 20
Forward Address: 1.1.1.1
External Route Tag: 0
Two Type-7 LSAs, and the Options line is the interesting field on both.
On R1's own LSA for 172.16.11.0/24 the options read Type 7/5 translation. That is the P-bit, and it is a request: translate me into a Type-5 and flood me to the rest of the domain. On the default LSA the ABR originated, the same field reads No Type 7/5 translation. That is deliberate. A default that exists only to give this area an exit has no business leaking into the backbone, so the ABR marks its own Type-7 as not translatable.
Forward Address: 1.1.1.1 is the other field to note. A backbone Type-5 usually carries 0.0.0.0, meaning "send traffic to the advertising router". An NSSA Type-7 carries a real address, and it survives translation, so it must be reachable from every router that receives the translated Type-5 or the route is discarded. The rules for when OSPF uses a forwarding address instead of the advertising router are worth reading before you deploy NSSA into a network with filtering in it, because this is a common way for an external to sit in the database and never install.
The full NSSA database
R1# show ip ospf database
OSPF Router with ID (1.1.1.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 69 0x80000009 0x007C59 2
2.2.2.2 2.2.2.2 74 0x80000009 0x00FAE5 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.12.2 2.2.2.2 79 0x80000003 0x00C64A
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
3.3.3.3 2.2.2.2 83 0x80000002 0x004DD1 <-- Type-3 summaries are back
10.0.23.0 2.2.2.2 83 0x80000002 0x003BD2
Type-7 AS External Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 2.2.2.2 83 0x80000001 0x00D0D8 0 <-- NSSA default (from ABR)
172.16.11.0 1.1.1.1 78 0x80000001 0x00685E 0 <-- R1's local external
Three things changed against the totally stubby capture. The Type-3 summaries for 3.3.3.3 and 10.0.23.0 are back, because plain NSSA does not suppress inter-area summaries. There is a Type-7 section that did not exist under either stub type. And there is still no Type-5 section, which is the part people forget: NSSA blocks backbone externals just as hard as stub does. It relaxes the rule in one direction only, for externals originated inside the area.
Also notice what left the Summary Net section: there is no 0.0.0.0 Type-3 any more. The default moved into the Type-7 section. Same destination, different LSA type, and that has a visible consequence.
The NSSA routing table
R1# show ip route ospf
Gateway of last resort is 10.0.12.2 to network 0.0.0.0
O*N2 0.0.0.0/0 [110/1] via 10.0.12.2, 00:01:14, Ethernet0/0 <-- default is now NSSA-external type 2
3.0.0.0/32 is subnetted, 1 subnets
O IA 3.3.3.3 [110/21] via 10.0.12.2, 00:01:19, Ethernet0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA 10.0.23.0/30 [110/20] via 10.0.12.2, 00:01:19, Ethernet0/0
The default route code changed from O*IA to O*N2. That is the single most useful diagnostic in this entire article: the route code of the default route tells you which area type produced it. O*IA means a Type-3 summary default, so the area is stub or totally stubby. O*N2 means an NSSA external type 2 default carried in a Type-7, so the area is NSSA. You can determine the area type of a router you have never logged into before from one line of show ip route.
The metric also dropped from 11 to 1, because an E2 metric does not accumulate internal cost. And 172.16.99.0/24, R3's backbone external, is still absent. NSSA did not let it in.
Proving the Type-7 to Type-5 translation
Everything so far has been from inside the area. The interesting half of NSSA is what leaves it. Here is R3, sitting in area 0, two hops from R1 and with no idea what an NSSA is:
R3# show ip ospf database external
OSPF Router with ID (3.3.3.3) (Process ID 1)
Type-5 AS External Link States
LS age: 89
LS Type: AS External Link
Link State ID: 172.16.11.0 (External Network Number )
Advertising Router: 2.2.2.2 <-- the ABR, NOT R1: this is the TRANSLATED Type-5
LS Seq Number: 80000001
Network Mask: /24
Metric Type: 2
Metric: 20
Forward Address: 1.1.1.1
External Route Tag: 0
LS age: 321
LS Type: AS External Link
Link State ID: 172.16.99.0 (External Network Number )
Advertising Router: 3.3.3.3 <-- R3's own external (native Type-5)
LS Seq Number: 80000001
Network Mask: /24
Metric Type: 2
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0
R3# show ip route ospf
O IA 1.1.1.1 [110/21] via 10.0.23.1, Ethernet0/0
O IA 10.0.12.0/30 [110/20] via 10.0.23.1, Ethernet0/0
O E2 172.16.11.0 [110/20] via 10.0.23.1, Ethernet0/0 <-- R1's NSSA external, now a normal E2
Side by side, the translation is unmistakable. R1's 172.16.11.0/24 is now a Type-5, not a Type-7, and its Advertising Router is 2.2.2.2, the ABR, not the 1.1.1.1 that originated it. R3's own 172.16.99.0/24 sits below it with Advertising Router 3.3.3.3, an untouched native Type-5, so both forms are in one output.
The metric survived at 20, the metric type stayed at 2, and so did the forwarding address of 1.1.1.1. R3 installs this route only because it can resolve 1.1.1.1, which the O IA 1.1.1.1 line above proves it can. Break that reachability and the Type-5 stays in the database while the O E2 route quietly vanishes.
The result on R3 is O E2 172.16.11.0. A router in the backbone treats the NSSA's external exactly like any other redistributed prefix. That translation is the entire reason NSSA exists: the area gets stub-like protection from the domain's externals while still exporting its own.
Totally stubby NSSA
The last combination stacks the two ideas. It blocks backbone Type-5s (NSSA), blocks inter-area Type-3s (no-summary), and still permits local Type-7 externals.
! ABR only
router ospf 1
area 1 nssa no-summary
! Internal routers
router ospf 1
area 1 nssaThis is the smallest database that still lets an area have its own ASBR, which makes it the right answer for the common branch: one uplink, one local firewall or WAN device injecting a couple of prefixes, no interest in the other four hundred prefixes in the enterprise. The lab captured the two component behaviours separately, so treat this section as the union of those two results rather than a third measured state.
One detail is worth verifying on your own gear rather than trusting any article, this one included: with nssa no-summary the ABR originates a default automatically, without default-information-originate, and on IOS it does so as a Type-3 rather than a Type-7. Confirm it in one command. show ip route ospf on an internal router: O*IA is a Type-3 default, O*N2 is a Type-7 default. The distinction matters if you filter summaries anywhere, because a Type-3 default can be caught by a filter a Type-7 sails straight past.
Common mistakes and gotchas
Mismatched area type means no adjacency, not a partial one. The stub flag (E-bit) and the NSSA flag (N-bit) ride in the hello options field and are checked before an adjacency forms. Configure area 1 stub on one router and leave the neighbour normal and you do not get fewer routes, you get no neighbour at all. It looks identical to a subnet or timer mismatch until you check the area config.
Changing a live area's type drops the adjacency. Not theoretical: it happened during this capture. Converting area 1 from stub to NSSA meant removing the stub flag on both routers, R1 and R2 disagreed for the moment in between, and the adjacency reset before reconverging. Scripted on production kit, the ABR and the internal routers are out of step for at least a hello interval. Do it in a window, and if you also run authentication on your OSPF adjacencies, change one thing at a time.
no-summary goes on the ABR only. It controls what that ABR originates. Internal routers keep the plain area X stub or area X nssa command.
Stub areas cannot carry a virtual link, and area 0 cannot be a stub. If an area lost its link to the backbone and you need to reconnect it through a transit area, that transit area must be normal. Making it stubby breaks the virtual link and the backbone at once.
An NSSA does not get a default automatically. Plain area X nssa gives you a Type-7 section and inter-area summaries and no way out to anything that is not in OSPF. Add default-information-originate on the ABR. This bites people who convert a stub area to NSSA and wonder where the default went: it left with the stub flag.
Only one ABR translates. With two ABRs on an NSSA, the one with the highest router ID does the Type-7 to Type-5 translation and the other stands down, so there are no duplicate Type-5s. An external that translated from what looks like the wrong ABR is that election, not a bug. Force it with area X nssa translate type7 always.
The P-bit is cleared on the ABR's own LSAs. Visible in the capture above: the ABR-originated default carries No Type 7/5 translation. That is why the default route does not leak into the backbone. If you are debugging why one Type-7 translates and another does not, read the Options line before you read anything else.
Watch for traffic that relied on a summary. Going totally stubby removes every Type-3, so anything that was longest-matching a specific inter-area prefix instead of the default changes path the instant you type no-summary. Snapshot show ip route ospf before and after, and diff.
Key takeaways
- Stub blocks Type-4 and Type-5, keeps Type-3 summaries, and the ABR injects a default as a Type-3. Proved above: no external section in the LSDB,
O*IA 0.0.0.0/0plusO IAroutes in the RIB. - Totally stubby (
no-summary, ABR only, Cisco extension) additionally suppresses every Type-3 except the default. Proved above: the LSDB Summary section shrank to a single 0.0.0.0 entry and the routing table to a single line. - NSSA still blocks backbone Type-5s but adds a Type-7 section for externals originated inside the area, and restores the Type-3 summaries. The ABR-originated default arrives as a Type-7, which is why its route code is
O*N2. - The default route's code identifies the area type.
O*IAmeans stub or totally stubby,O*N2means NSSA. One line ofshow ip routetells you how the area is configured. - The ABR does the Type-7 to Type-5 translation, rewriting the Advertising Router to itself while preserving metric, metric type and forwarding address. Proved on R3: Advertising Router 2.2.2.2 for a prefix R1 originated.
- Every router in the area must agree on the area type, because the flag rides in the hello. The exception is
no-summary, an ABR-only instruction.
Area types are the cheapest scaling tool OSPF gives you, and you can now prove which one is in effect on any router in ten seconds instead of reading four configs. The full OSPF learning path runs from adjacency states through LSA types, summarisation and filtering, which are the next levers once your areas are the right shape.