OSPF is a link-state routing protocol that uses the SPF algorithm to calculate the best path between source and destination. Routers running OSPF exchange Link-State Advertisements (LSAs) to build and maintain their Link-State Databases (LSDBs) — LSAs function as the individual database records that describe specific pieces of network topology. Eleven distinct LSA types are commonly documented across OSPF implementations, though the first seven cover the vast majority of what shows up in a typical multi-area deployment.
LSA Type 1: Router LSA
Every OSPF router generates a Type 1 LSA describing its own directly connected links, flooding it only within the area those links belong to — Type 1 LSAs never cross an area boundary in their original form. The Link State ID is the Router ID of the originating router, and the LSA itself contains information about directly connected interfaces, link types, and link states.
Area Border Routers collect Type 1 LSAs from every router in an area and later condense that information into Type 3 Summary LSAs for advertisement into other areas — the mechanism covered in more detail in Types of Routers in OSPF.
LSA Type 2: Network LSA
On multiaccess segments (broadcast or NBMA), the Designated Router sends Type 2 LSAs to every other router in the same area, describing the network segment itself — which routers are attached, and the DR/BDR relationship on that segment. Like Type 1, Type 2 LSAs are confined to their originating area and never flood beyond it. The Link State ID for a Type 2 LSA is the IP interface address of the DR that generated it.
LSA Type 3: Summary LSA
Area Border Routers use Type 3 LSAs to advertise networks learned from one area into another. An ABR collects the Type 1 LSAs from its connected areas, and once that area has converged, generates a Type 3 Summary LSA for each learned network, injecting it into the backbone (and from there, potentially into other areas as well).
Each Type 3 LSA carries the summarized IP information and the Router ID of the advertising ABR. This is the mechanism that lets OSPF scale — routers outside an area only need reachability information (a network and a cost) rather than the full internal topology of every other area. In a large deployment with many networks, unsummarized Type 3 flooding can itself become a scaling problem, which is why manual route summarization on ABRs is a standard best practice.
Type 3 LSAs appear in the routing table as O IA entries (OSPF Inter-Area), and receiving one does not trigger a full SPF recalculation the way a Type 1 or Type 2 change would — only intra-area topology changes require rerunning SPF.
LSA Type 4: ASBR Summary LSA
Type 4 LSAs function similarly to Type 3 LSAs, but rather than advertising a network, they advertise the location of an Autonomous System Boundary Router (ASBR). When an ASBR exists within an area, the ABR generates a Type 4 LSA identifying that ASBR and providing a route to reach it — necessary because routers in other areas need to know how to reach the ASBR before they can make use of any external routes it advertises.
The Router LSA (Type 1) generated by the ASBR itself includes a special flag called the external bit, or E-bit, in its options field, which marks the originating router as an ASBR. When an ABR notices this bit set in a Type 1 LSA it receives, it builds a corresponding Type 4 LSA and floods it into the backbone. The Link State ID of a Type 4 LSA is set to the ASBR’s Router ID.
LSA Type 5: AS External LSA
Autonomous System External LSAs are generated directly by ASBRs and describe routes to networks outside the current OSPF autonomous system — most commonly routes redistributed from another routing protocol, static routes, or a default route pointing to the internet. The Link State ID is the external network number being advertised, and Type 5 LSAs flood throughout the entire autonomous system (with one key exception: they are not flooded into stub areas, which are specifically designed to exclude them).
External routes learned via Type 5 LSAs appear in the routing table as O E1 or O E2 entries, depending on how their cost is calculated — the distinction is covered in more detail in Types of Routers in OSPF. Because a Type 5 LSA on its own doesn’t tell other areas how to physically reach the ASBR that generated it, routers rely on the companion Type 4 LSA for that reachability information.
LSA Type 6: Group Membership LSA
Type 6 LSAs support Multicast OSPF (MOSPF), an extension for multicast routing within OSPF. In practice, this LSA type can be safely set aside for most study and deployment purposes: Cisco has never supported MOSPF, and it never achieved meaningful adoption industry-wide.
LSA Type 7: NSSA External LSA
Type 7 LSAs exist specifically for Not-So-Stubby Areas (NSSAs) — a special area type that, like a regular stub area, blocks Type 5 External LSAs from entering, but still needs a way to support an ASBR located inside it. An ASBR within an NSSA generates Type 7 LSAs instead of Type 5 LSAs to describe its external routes.
Type 7 LSAs carry the same underlying information as a Type 5 LSA, but they’re permitted inside the NSSA where Type 5 is blocked. When a Type 7 LSA reaches the ABR at the edge of the NSSA on its way toward the rest of the OSPF domain, the ABR translates it back into a standard Type 5 LSA before flooding it further. Routes learned via Type 7 LSAs appear in the routing table with an N1 or N2 designation, mirroring the E1/E2 distinction used for Type 5 routes.
LSA Type 8: Link LSA (OSPFv3) / External Attributes LSA (OSPFv2)
Type 8’s meaning differs sharply between OSPF versions, and it’s worth being precise about the split:
In OSPFv2, Type 8 was originally proposed as an “External Attributes LSA,” intended to carry BGP path attributes through an OSPF domain. This never became a finalized RFC and was never implemented in Cisco IOS or, as far as is documented, any other major vendor’s OSPF implementation — it’s essentially a historical footnote rather than something you’ll encounter in a real OSPFv2 network.
In OSPFv3, Type 8 is repurposed entirely as the Link-LSA. Because OSPFv3’s Router and Network LSAs (Types 1 and 2) were redesigned to carry only topology information and no longer carry IP address data directly, OSPFv3 needed a new way to advertise a router’s link-local IPv6 address and the list of IPv6 prefixes on that link — that’s exactly what the Link-LSA does. Link-LSAs have link-local flooding scope only, meaning they never leave the single link they were generated on, not even to travel elsewhere within the same area.
LSA Type 9: Intra-Area-Prefix LSA (OSPFv3) / Link Scope Opaque LSA (OSPFv2)
Type 9 also splits meaning between OSPF versions, and this is a point worth correcting carefully, since it’s easy to conflate with Type 8’s behavior.
In OSPFv2, Type 9 is the Link Scope Opaque LSA — part of the general-purpose Opaque LSA framework that lets OSPF carry additional information beyond its core routing function, scoped to a single link.
In OSPFv3, Type 9 is the Intra-Area-Prefix-LSA, and its actual job is straightforward: it carries the list of IPv6 address prefixes associated with a router or a transit network within an area. This exists because, as with Type 8, OSPFv3 moved prefix information out of the Router and Network LSAs entirely. Unlike Type 8’s Link-LSA, the Intra-Area-Prefix-LSA has area-wide flooding scope — it’s flooded to every router within the area, not confined to a single link. It also has no special connection to stub areas specifically; it carries prefix information within any normal area just as readily as within a stub area.
[See Infographic: OSPFv3’s New LSA Types — Type 8 vs Type 9]
LSA Type 10: Area Scope Opaque LSA
Type 10 extends the Opaque LSA framework with area-wide flooding scope, letting OSPF carry additional, potentially vendor-specific or feature-specific information to every router within an area, even routers that don’t understand or use that particular data. This is what allows OSPF to be extended with new capabilities without requiring every router in the network to support them simultaneously.
LSA Type 11: AS Scope Opaque LSA
Type 11 performs the same general function as Type 10, but with autonomous-system-wide flooding scope rather than being confined to a single area. Like Type 5 External LSAs, Type 11 LSAs are not flooded into stub area types, which are specifically designed to exclude AS-wide external and opaque information to keep routing tables small for routers inside them.
Summary Table
| LSA Type | Name | Generated By | Flooding Scope |
|---|---|---|---|
| 1 | Router LSA | Every router | Single area |
| 2 | Network LSA | DR on multiaccess segment | Single area |
| 3 | Summary LSA | ABR | Backbone / other areas |
| 4 | ASBR Summary LSA | ABR | Backbone / other areas |
| 5 | AS External LSA | ASBR | Entire AS (not stub areas) |
| 6 | Group Membership LSA (MOSPF) | MOSPF routers | Rarely used; not Cisco-supported |
| 7 | NSSA External LSA | ASBR within an NSSA | Within the NSSA only |
| 8 | Link-LSA (v3) / External Attributes (v2, unused) | Router (v3) | Single link only (v3) |
| 9 | Intra-Area-Prefix-LSA (v3) / Link Scope Opaque (v2) | Router (v3) | Area (v3) |
| 10 | Area Scope Opaque LSA | Any supporting router | Single area |
| 11 | AS Scope Opaque LSA | Any supporting router | Entire AS (not stub areas) |
Frequently Asked Questions
Which OSPF LSA types actually matter for the CCNA exam?
Types 1 through 5 cover the core mechanics tested at the CCNA level: Router, Network, Summary, ASBR Summary, and AS External LSAs. Type 7 becomes relevant once NSSA areas are covered, typically at a slightly more advanced level. Types 6, 8, 9, 10, and 11 are worth knowing conceptually but rarely appear in hands-on exam scenarios.
Does receiving a Type 3 Summary LSA trigger a full SPF recalculation?
No. Only Type 1 and Type 2 LSAs, which describe actual topology within an area, trigger a full SPF run. A Type 3 LSA simply updates a reachability entry and its associated cost — the router doesn’t need to recompute its shortest-path tree for that.
What’s the actual difference between OSPFv3’s Type 8 and Type 9 LSAs?
Both carry IPv6 address information that OSPFv2 used to bundle into the Router and Network LSAs directly. The Link-LSA (Type 8) is scoped to a single link and carries a router’s link-local address plus the prefixes on that link. The Intra-Area-Prefix-LSA (Type 9) has area-wide scope and carries prefix information more broadly across the area — it is not, contrary to some older material, specifically tied to stub areas.
Why doesn’t OSPF flood Type 5 LSAs into stub areas?
Stub areas exist specifically to reduce the routing table size and LSDB overhead for routers inside them, by excluding Type 5 External LSAs (and, in a totally stubby area, Type 3 Summary LSAs as well) in favor of a single default route out of the area.
What replaces Type 5 LSAs inside a Not-So-Stubby Area?
Type 7 NSSA External LSAs. They carry the same information as a Type 5 LSA but are permitted to exist inside an NSSA, and get translated back into standard Type 5 LSAs by the area’s ABR before continuing on to the rest of the OSPF domain.
Conclusion
OSPF’s LSA types exist to let different pieces of topology and reachability information flood exactly as far as they need to and no further — Type 1 and 2 stay within an area, Type 3 and 4 cross into the backbone and other areas, Type 5 spans the whole autonomous system except stub areas, and the Opaque LSA family (9, 10, 11) extends this same scoped-flooding model to arbitrary additional data. OSPFv3’s Type 8 and Type 9 LSAs are worth knowing precisely rather than approximately, since they’re easy to mix up: Type 8 is link-local, Type 9 is area-wide, and neither is specifically about stub areas.
