OSPF Deep Dive Part 2: LSA Types and the Area Type Hierarchy
Part 1 covered how two routers reach Full and start sharing a database. This post covers what’s actually in that database. The link-state database is a collection of LSAs, and almost every area-design decision in OSPF, stub, totally stubby, NSSA, whether to summarize at an ABR, comes down to controlling which of these LSA types a router is allowed to receive.
The LSA types worth knowing
RFC 2328 defines more LSA types than get used in a typical design, so this list only covers the ones that show up in real networks, including this series’ three-router, three-area lab from Part 1.
Type 1, Router LSA. Every router originates exactly one per area it participates in. It lists the router’s own interfaces in that area and their costs. This is the LSA that tells the rest of the area “here is what I connect to and what it costs to use me to get there.” Flooded within the originating area only.
Type 2, Network LSA. Originated by the DR on a broadcast or NBMA segment, not by every router on it. It lists every router attached to that segment. This is the payoff for the DR/BDR election from Part 1: instead of every router describing the segment from its own point of view, one authoritative LSA describes it once. Also flooded within the area only.
Type 3, Summary LSA. Originated by an ABR (Area Border Router), a router with interfaces in more than one area. It takes what the ABR learned as Type 1/2 LSAs in one area and re-advertises the resulting prefixes into another area as Type 3s. This is the only LSA type that crosses an area boundary for intra-AS routes, and it’s also the LSA type that stub and totally stubby areas restrict.
Type 4, ASBR Summary LSA. Also originated by an ABR, but instead of describing a prefix, it describes how to reach an ASBR (Autonomous System Boundary Router) that lives in a different area. Without a Type 4, a router in Area 1 would have no way to resolve the next hop for external routes injected by an ASBR sitting in Area 0.
Type 5, AS External LSA. Originated by an ASBR for routes redistributed from outside OSPF, static routes, connected routes, or another routing protocol. Flooded through the entire OSPF domain unmodified, which is exactly what stub areas exist to prevent, since a stub area’s whole purpose is to keep Type 5s out.
Type 7, NSSA External LSA. Functionally a Type 5 that’s allowed to exist inside an NSSA, where Type 5s are normally forbidden. The NSSA’s ABR translates every Type 7 it sees into a real Type 5 before flooding it into the rest of the domain. This translation step is the entire reason NSSA exists as a distinct concept instead of just “a stub area that allows externals.”
Type 1 and 2 within a virtual link’s transit area deserve a mention here too, since Part 4 depends on it: a virtual link doesn’t create a new LSA type. It uses the existing Type 1/4 mechanism across a transit area to let two ABRs that aren’t directly connected still exchange Area 0 information as if they were.
What each area type actually filters
Every area type in OSPF is really just a policy about which of the LSA types above an ABR is willing to forward into it. None of them change the state machine from Part 1. They only change what ends up in the LSDB once a router is Full with its neighbors.
| Area type | Type 3 (inter-area) | Type 4 (ASBR summary) | Type 5 (external) | Type 7 (NSSA external) |
|---|---|---|---|---|
| Standard (Area 0 or a regular area) | Allowed | Allowed | Allowed | Not applicable |
| Stub | Allowed | Blocked | Blocked | Not applicable |
| Totally stubby | Blocked (replaced by one default route) | Blocked | Blocked | Not applicable |
| NSSA | Allowed | Blocked | Blocked | Allowed, translated to Type 5 at the ABR |
| Totally NSSA | Blocked (replaced by one default route) | Blocked | Blocked | Allowed, translated to Type 5 at the ABR |
A stub area still knows about every other area’s prefixes via Type 3s, it just can’t see routes from outside the OSPF domain entirely. A totally stubby area goes further and doesn’t even get individual inter-area prefixes, only a single default route from its ABR, on the assumption that a stub-of-a-stub site never needs granular knowledge of the rest of the network to make a correct forwarding decision. NSSA exists for the specific case of a stub-style area that still needs to originate its own external routes, most often a branch site with its own internet breakout or a redistributed static default, which a plain stub area can’t do because it can’t carry Type 5s or their Type 7 stand-ins.
Area 1 in this series’ lab is exactly that NSSA case. It’s a stub-style area that still needs to redistribute a static route locally, which is why Part 4 configures it as NSSA rather than plain stub. Area 0 stays standard, because the backbone always has to carry everything. Area 2 stays standard too in this post, though it becomes relevant to virtual links in Part 4 for an unrelated reason: it has no direct connection to Area 0 at all.
The rule every area type shares
Area 0 itself can never be a stub, totally stubby, or NSSA. It’s definitionally the area that carries everything, since every other area’s Type 3 and Type 4 information has to transit it to reach any other non-backbone area. A stub area also can’t contain an ASBR performing redistribution unless it’s specifically NSSA, because a stub area’s ABR has nothing to translate a Type 5 from in the first place: Type 5s are dropped, not converted, everywhere except at an NSSA’s ABR.
One consequence worth internalizing before Part 3: none of the filtering in this post touches Type 1 or Type 2 LSAs. Every router always has full router and network LSA visibility within its own area, area type notwithstanding. Area type only ever restricts information about prefixes outside that area. That distinction matters for the SPF calculation covered next, because intra-area SPF runs on complete information regardless of area type, and it’s only the inter-area and external route calculations that ever see a filtered view.