OSPF LSA types are the kinds of link state advertisement routers exchange, each defined by who originates it and how far it floods.
RFC 2328 defines Type 1 router-LSAs from every router, Type 2 network-LSAs from the Designated Router, Type 3 and 4 summary-LSAs from area border routers, and Type 5 AS-external-LSAs from AS boundary routers, the only one that floods beyond an area, except into stub areas. RFC 3101 adds Type 7 for NSSAs, and RFC 5250 adds opaque Types 9, 10 and 11, scoped to link, area and AS.
- Type 1 router-LSA: every router, flooded within its area
- Type 2 network-LSA: the Designated Router, flooded within its area
- Types 3 and 4 summary-LSAs: area border routers
- Type 5 AS-external-LSA: AS-wide, except stub areas
- Type 7 stays inside an NSSA; opaque 9, 10, 11 are link, area and AS scope
On this page
What an LSA isWhat an LSA is, and why there are several kinds
OSPF is a link state protocol: every router in an area holds the same database describing the area, and each one runs its own shortest path calculation over it. The OSPF overview covers areas, costs and adjacencies. The link state advertisement is the unit that database is built from.
Different things need describing. A router's own links, a shared segment with several routers on it, a network in another area, and a route learned from outside OSPF are different kinds of fact, originated by different routers. Each LSA type is one of those kinds.
Scope is the reason areas work. RFC 2328 states that all the LSA types it defines, except the AS-external-LSAs, are flooded throughout a single area only. That is what keeps a change in one area from forcing detailed recalculation everywhere else: the other areas receive a summary, not the detail.
Reading an LSA database is reading the OSPF LSA types. When a router's database looks wrong, the useful questions are which type is missing, who should have originated it, and where its flooding stopped.
Types 1 to 5The five types in RFC 2328
Type 1, router-LSA. RFC 2328 says each router in an area originates a router-LSA, which describes the state and cost of the router's links to that area, all of them in a single LSA. A router in three areas originates three router-LSAs, one per area, and none of them leaves its area.
Type 2, network-LSA. A network-LSA is originated for each broadcast and NBMA network in the area that supports two or more routers, and it is originated by that network's Designated Router. It describes all the routers attached to the network, including the Designated Router itself. A point-to-point link has no Designated Router and no network-LSA.
Type 3, summary-LSA for a network. Summary-LSAs are originated by area border routers, ABRs, and describe inter-area destinations. Type 3 is used when the destination is an IP network. This is how a router in one area learns that a network exists in another, without receiving that area's router-LSAs and network-LSAs.
Type 4, summary-LSA for an AS boundary router. When the destination is an AS boundary router, an ASBR, rather than a network, the ABR uses a Type 4 summary-LSA. It exists so that routers in another area can work out how to reach the ASBR that originated an external route.
Type 5, AS-external-LSA. AS-external-LSAs are originated by ASBRs and describe destinations external to the AS, such as routes redistributed from BGP or from static configuration. They are the exception to the single-area rule: RFC 2328 floods them throughout the entire autonomous system, except into stub areas.
Type 7Type 7, and why not-so-stubby areas need it
A stub area solves one problem and creates another, and RFC 3101 exists for the second.
The problem with a stub area. A stub area keeps Type 5 LSAs out. That is its purpose. It also means a router inside it cannot inject external routes of its own, because an external route in OSPF version 2 is a Type 5 LSA.
Type 7 carries external routes inside the NSSA. RFC 3101, the Not-So-Stubby Area option, says Type 7 LSAs provide for carrying external route information within an NSSA, and have virtually the same syntax as Type 5 LSAs apart from the link-state type. As with stub areas, Type 5 LSAs are not flooded into an NSSA and do not originate there.
Type 7 stays in its own area. RFC 3101 is explicit that Type 7 LSAs are advertised only within a single NSSA and are not flooded into the backbone or any other area by border routers.
The information reaches the rest of the network through translation: the NSSA's border router acting as translator turns Type 7 LSAs into Type 5 LSAs, which then flood like any other external route.
Neighbors have to agree. RFC 3101 notes that both NSSA neighbors must agree on the setting of the N-bit, or the OSPF neighbor adjacency will not form. An area configured as an NSSA on one router and as a normal or stub area on its neighbor produces an adjacency that never comes up.
Opaque LSAsTypes 9, 10 and 11: opaque LSAs
RFC 5250 describes opaque LSAs as a generalized mechanism to allow for the future extensibility of OSPF, carrying application-specific information after a standard LSA header, and their type number is their flooding scope.
Type 9, link-local. RFC 5250 says type 9 denotes a link-local scope, and type 9 opaque LSAs are not flooded beyond the local subnetwork.
Type 10, area-local. Type 10 opaque LSAs are not flooded beyond the borders of their associated area.
Type 11, AS-wide. Type 11 opaque LSAs are flooded throughout the autonomous system, with the same flooding scope as Type 5 AS-external-LSAs.
Why they matter to an operator. Opaque LSAs are how extensions to OSPF carry their own data without inventing new flooding rules. If an extension's information appears on one router and not another, the opaque type number tells you whether it was ever supposed to cross the boundary between them.
Area typesWhich LSAs each area type keeps out
Area types are defined by what they refuse, and the refusals follow directly from the LSA types above.
A normal area receives Type 1 and Type 2 LSAs for itself, Type 3 and Type 4 summaries about other areas, and Type 5 external routes from anywhere in the AS.
A stub area receives no Type 5 LSAs. RFC 2328 describes AS-external-LSAs as not flooded into or throughout stub areas, with routing to external destinations based on a default route instead. One or more of the stub area's border routers must advertise that default into the area through summary-LSAs, which flood throughout the stub area and no further.
RFC 2328 says an area can be configured as a stub when there is a single exit point, or when the choice of exit does not need to be made per external destination.
A not-so-stubby area also receives no Type 5 LSAs, and it can hold Type 7 LSAs for external routes that originate inside it, which its border router translates to Type 5 for the rest of the network.
The backbone and other normal areas carry Type 5 LSAs, including those translated from Type 7 at an NSSA border.
PitfallsWhere people go wrong
Expecting to see another area's router-LSAs. Types 1 and 2 never leave their area, so the topology of one area is invisible from the next. A router in area 1 sees area 2 only through Type 3 summaries, and that is correct behavior, not a fault.
Looking for a network-LSA on a point-to-point link. Network-LSAs are originated for broadcast and NBMA networks with two or more routers, by the Designated Router. A point-to-point link does not have one.
Redistributing into a stub area and wondering where the routes went. A stub area accepts no Type 5 LSAs. If a router inside the area has to inject external routes, the area has to be an NSSA, where they travel as Type 7.
Mismatching the area type on neighbors. Stub and NSSA configuration has to match on both sides of an adjacency. RFC 3101 states that disagreement on the N-bit prevents the adjacency from forming.
Losing external routes at the NSSA border. Type 7 LSAs do not leave the NSSA themselves; the ABR translates them. If the rest of the network never sees an external route from inside the NSSA, check the translation on the border router rather than the flooding.
Trying to learn every numbered type. The types that decide day-to-day OSPF behavior are 1, 2, 3, 4, 5 and 7. The opaque types matter when an extension uses them, and their number tells you the scope.
ComparisonWho originates each LSA, and how far it floods
| Criterion | Originated by | Describes | Flooding scope |
|---|---|---|---|
| Type 1 router-LSA | Every router | Its links to the area | Its area |
| Type 2 network-LSA | Designated Router | Routers on a multi-router segment | Its area |
| Type 3 summary-LSA | Area border router | A network in another area | The area it is sent into |
| Type 4 summary-LSA | Area border router | The location of an AS boundary router | The area it is sent into |
| Type 5 AS-external-LSA | AS boundary router | A route from outside OSPF | Whole AS, not stub areas or NSSAs |
| Type 7 NSSA LSA | Router inside an NSSA | An external route in the NSSA | That NSSA only, translated to Type 5 |
| Types 9, 10, 11 opaque | Extension dependent | Extension data | Link, area, AS |
The flooding scope column is the one to read when a route is missing: it says where the LSA was ever allowed to go.
FAQFrequently asked questions
What are the OSPF LSA types?
In OSPF version 2, RFC 2328 defines Type 1 router-LSAs, Type 2 network-LSAs, Type 3 and Type 4 summary-LSAs, and Type 5 AS-external-LSAs. RFC 3101 adds Type 7 for not-so-stubby areas, and RFC 5250 adds opaque Types 9, 10 and 11.
What is a Type 1 LSA?
A router-LSA. Every router in an area originates one for that area, describing the state and cost of its links to it. It is flooded only within that area.
What is a Type 2 LSA?
A network-LSA, originated by the Designated Router for each broadcast or NBMA network in the area with two or more routers. It lists all routers attached to that network.
What is the difference between Type 3 and Type 4 LSAs?
Both are summary-LSAs originated by area border routers. Type 3 describes an IP network in another area. Type 4 describes the location of an AS boundary router, so routers can reach the originator of external routes.
Which LSA types are flooded outside an area?
Among the RFC 2328 types, only Type 5 AS-external-LSAs, which flood throughout the autonomous system except into stub areas. Type 11 opaque LSAs have the same AS-wide scope.
What is a Type 7 LSA?
An external route inside a not-so-stubby area, defined in RFC 3101. It is advertised only within that NSSA and is translated into a Type 5 LSA by the NSSA border router for the rest of the network.
Why does a stub area have no Type 5 LSAs?
Because that is what a stub area is: RFC 2328 keeps AS-external-LSAs out of stub areas and has the area border routers advertise a default route into them instead, which reduces the size of the area's database.
What is the difference between a stub area and an NSSA?
Both keep Type 5 LSAs out. An NSSA also allows external routes to originate inside the area as Type 7 LSAs, which a stub area cannot do.
What are opaque LSAs?
LSAs defined in RFC 5250 for carrying data for OSPF extensions. Type 9 stays on the local link, Type 10 stays in its area, and Type 11 floods through the whole autonomous system.
Why is my OSPF adjacency not forming in an NSSA?
A mismatch in area type is one cause. RFC 3101 states that NSSA neighbors must agree on the N-bit setting or the adjacency will not form.
Does OSPFv3 use the same LSA types?
OSPFv3, used for IPv6, is defined in a separate specification. This page covers OSPF version 2 as defined in RFC 2328 and its extensions.
How do LSA types relate to other routing protocols?
They are specific to OSPF. The comparable link state protocol is IS-IS, and the choice between dynamic protocols and fixed routes is covered in static vs dynamic routing.
Keep readingRelated concepts
Read next · Routing What Is BGP? One protocol whose routes reach OSPF as the external routes a Type 5 LSA carries. Open this next12 min- Routing · 12 min OSPF Explained Areas, costs, the Area 0 rule and why adjacencies get stuck.
- Routing · 12 min The IS-IS Protocol, and Why It Runs the Networks You Never See The other link state protocol, organized around levels rather than areas.
- Routing · 9 min BFD, the Fast Way to Notice a Link Has Failed The protocol that reconverges once BFD reports a path down.
- Routing · 9 min Protocol Independent Multicast, and How PIM Builds the Tree A source of the unicast routes PIM uses for its RPF check.