OSPF LSA types — Type 1 through Type 11 and what each one carries

OSPFv2 carries topology in nine LSA types, numbered 1 to 11 with two gaps: Type 6 was the MOSPF multicast LSA and is deprecated, and Type 8 in OSPFv2 was an external-attributes LSA that never saw deployment. Each type has its own flooding scope and its own job. An engineer who knows what each type carries can read the database and spot the failure directly: a missing Type 5 in an area that should see externals, a Type 7 that never became a Type 5, a Network LSA that should exist and does not.

This lesson is the reference map. The rest of the OSPF parts extend the model defined here.

The LSA type table

Scope is the property that explains almost every LSA question. Type 1 and Type 2 stop at the area boundary, which is exactly why an ABR must translate the topology it knows into Type 3 prefixes rather than forwarding the originals: an area never sees another area’s graph, only its distances.

flowchart TB
  subgraph Area0["Area 0 — backbone"]
    R1["R1 originates Type 1"]
    R2["R2 originates Type 1"]
    DR["DR originates Type 2"]
  end
  subgraph Area1["Area 1"]
    R3["R3 originates Type 1"]
  end
  ABR1["ABR1 sits in both areas<br/>originates Type 3 and Type 4<br/>into each of them"]
  ASBR["ASBR originates Type 5<br/>flooded to the whole domain"]
  Area0 --- ABR1
  ABR1 --- Area1
  Area0 --- ASBR
  NSSA["Inside an NSSA:<br/>the local ASBR originates Type 7<br/>and the NSSA ABR translates it to Type 5"]
  ABR1 --- NSSA

The view the engineer holds:

vyos@r1:~$ show ip ospf database

       OSPF Router with ID (1.1.1.1)

              Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
1.1.1.1         1.1.1.1         1245 0x80000005 0x9ab2 3
2.2.2.2         2.2.2.2          893 0x80000004 0x44cc 2

              Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
10.0.0.4        2.2.2.2          893 0x80000002 0xaabb

              Summary Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Route
192.168.1.0     3.3.3.3         1200 0x80000003 0x1122 192.168.1.0/24

              AS External Link States

Link ID         ADV Router      Age  Seq#       CkSum  Route
0.0.0.0         4.4.4.4          360 0x80000001 0x9944 E2 0.0.0.0/0 [0x0]

Read the section headers before the rows. “Router Link States” is Type 1, “Net Link States” is Type 2, “Summary Link States” is Type 3, “ASBR-Summary Link States” is Type 4, “AS External Link States” is Type 5 and appears once for the whole domain rather than per area, “NSSA-external Link States” is Type 7. Each area-scoped section carries its area in the header, so on an ABR you will see the same header repeated per area — and the difference between those repetitions is usually the answer to whatever you are debugging.

Type 1 — Router LSA

Every OSPF router originates exactly one Type 1 per area it participates in. It describes:

• The router’s router-id (which is also the Link State ID).
• Every interface the router has in that area, as a list of links.
• The cost of each link.
• Flag bits saying whether this router is an ABR, an ASBR, or a virtual-link endpoint.

Each link in the list has a type, and the type decides what the two ID fields mean:

vyos@r1:~$ show ip ospf database router 1.1.1.1

       OSPF Router with ID (1.1.1.1)

              Router Link States (Area 0.0.0.0)

LS age: 1245
Options: 0x2  : *|-|-|-|-|-|E|-
LS Flags: 0x6
Flags: 0x0
LS Type: router-LSA
Link State ID: 1.1.1.1
Advertising Router: 1.1.1.1
LS Seq Number: 80000005
Checksum: 0x9ab2
Length: 48

 Number of Links: 2

  Link connected to: a Transit Network
   (Link ID) Designated Router address: 10.0.0.4
   (Link Data) Router Interface address: 10.0.0.1
    Number of TOS metrics: 0
     TOS 0 Metric: 10

  Link connected to: Stub Network
   (Link ID) Net: 10.10.0.0
   (Link Data) Network Mask: 255.255.255.0
    Number of TOS metrics: 0
     TOS 0 Metric: 10

Two habits pay off here. First, count the links against what the router actually has in that area — a missing link is a missing adjacency or a missing network statement, and it is invisible in show ip route. Second, read the transit links from both ends. Dijkstra only follows a link it can confirm from the far end’s LSA as well, so a transit link that appears in one Router LSA and not in the matching Network LSA is a link that will never carry traffic no matter how healthy the adjacency looks.

Type 2 — Network LSA

Only the DR of a broadcast or NBMA segment originates a Type 2, and only once it has at least one full adjacency on that segment. It describes the segment itself: its mask, and the router-ids of every router attached to it — including the DR.

The Type 2 is what turns a multi-access segment into a single node in the graph. Without it, every router on an Ethernet would have to describe a link to every other router, and the Router LSAs would grow with the square of the segment size. On a point-to-point link there is no DR and no Type 2; the two Router LSAs describe each other directly.

vyos@r1:~$ show ip ospf database network

       OSPF Router with ID (1.1.1.1)

              Net Link States (Area 0.0.0.0)

LS age: 893
Options: 0x2  : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: network-LSA
Link State ID: 10.0.0.4 (address of Designated Router)
Advertising Router: 2.2.2.2
LS Seq Number: 80000002
Checksum: 0xaabb
Length: 36
Network Mask: /24
      Attached Router: 1.1.1.1
      Attached Router: 2.2.2.2
      Attached Router: 3.3.3.3

The Attached Router list is the check that matters. Every router you believe is on that segment must be listed. A router that is present on the wire, has a Full adjacency with the DR, and is not in this list has not been picked up by the DR — and every other router in the area will route around it, because the graph says it is not there.

A missing Type 2 for a segment that should have one means either no DR was elected, or the DR has no full adjacency yet. Both are adjacency problems, not LSA problems.

Type 3 — Summary LSA (inter-area)

An ABR sits in two or more areas. Into each attached area, it originates one Type 3 per prefix it can reach in its other areas. The Link State ID is the prefix; the metric is the ABR’s own cost to reach it.

vyos@r1:~$ show ip ospf database summary

       OSPF Router with ID (1.1.1.1)

              Summary Link States (Area 0.0.0.0)

LS age: 1200
Options: 0x2  : *|-|-|-|-|-|E|-
LS Flags: 0x6
LS Type: summary-LSA
Link State ID: 192.168.1.0 (summary Network Number)
Advertising Router: 3.3.3.3
LS Seq Number: 80000003
Checksum: 0x1122
Length: 28
Network Mask: /24
      TOS: 0  Metric: 20

A receiving router adds its own cost to reach the advertising ABR to the metric in the LSA. That addition is the whole inter-area distance model, and it has one consequence worth internalising: an area’s internal topology is invisible outside it. Two areas connected by two ABRs give you two candidate distances to the same prefix and no way to see which path is congested, only which is cheaper.

Type 3 is also where address-plan discipline pays off. A contiguous block per area lets an ABR advertise one summary instead of forty prefixes; a plan that interleaves areas means every prefix crosses every boundary individually, and every flap crosses with it.

Type 4 — ASBR-Summary LSA

A Type 4 does not describe a network. It describes a router: an ASBR in another area, so that routers here can compute a path to it.

The chain matters. To use a Type 5 external route, a router needs a path to the ASBR that originated it. If the ASBR is in the same area, the Router LSAs already provide that. If it is in another area, the ABR of the ASBR’s area originates a Type 4 naming the ASBR’s router-id, and that Type 4 is what makes the external usable elsewhere.

The failure is therefore two-headed: the Type 5 can be present domain-wide and perfectly valid, while the route does not install because the Type 4 is missing or the ASBR is unreachable. Check both:

show ip ospf database external
show ip ospf database asbr-summary
show ip ospf route

If the external appears in the database but not in show ip ospf route, the forwarding path to the ASBR is what to look at, not the external itself.

Type 5 — AS-external LSA

An ASBR originates Type 5 LSAs for routes it redistributes into OSPF from elsewhere — static, connected, BGP, another IGP. Type 5 floods the entire OSPF domain, crossing area boundaries unchanged, and is blocked only at stub and NSSA boundaries.

vyos@r1:~$ show ip ospf database external

       OSPF Router with ID (1.1.1.1)

              AS External Link States

LS age: 360
Options: 0x2  : *|-|-|-|-|-|E|-
LS Flags: 0x9
LS Type: AS-external-LSA
Link State ID: 0.0.0.0 (External Network Number)
Advertising Router: 4.4.4.4
LS Seq Number: 80000001
Checksum: 0x9944
Length: 36
Network Mask: /0
      Metric Type: 2 (Larger than any link state path)
      TOS: 0
      Metric: 1
      Forward Address: 0.0.0.0
      External Route Tag: 0

Three fields decide how this route behaves:

• Metric Type. E2 (type 2) means the metric in the LSA is the whole cost — the internal cost to reach the ASBR is not added, so every router in the domain sees the same distance. E1 (type 1) adds the internal cost to the ASBR, so routers nearer the ASBR prefer it. E2 is the default. E1 is what you want when two ASBRs inject the same prefix and you want each router to use the closer one; with E2 they tie on metric, and the tie is broken by the cost to the ASBR anyway, which is a subtler mechanism to reason about under pressure.
• Forward Address. 0.0.0.0 means “send it to the ASBR”. A non-zero value means “send it to this address instead”, which avoids a hairpin when the real next hop is a third-party router on a shared segment. A non-zero forwarding address that is not itself reachable via OSPF makes the route unusable, and that is a genuinely confusing outage: the LSA is present, well-formed and ignored.
• External Route Tag. Not used by OSPF at all. It is a 32-bit value carried transparently for policy — typically stamped at redistribution so that a route-map somewhere else can recognise routes that originated outside and refuse to send them back.

Type 7 — NSSA external LSA

An NSSA is an area that will not accept Type 5 but does have its own ASBR. The local ASBR originates Type 7 instead, which floods only within the NSSA. The NSSA’s ABR translates Type 7 into Type 5 as they leave, so the rest of the domain sees ordinary externals.

show ip ospf database nssa-external

Two mechanics decide whether the translation happens:

• The P-bit. Each Type 7 carries a “propagate” bit. Only Type 7 LSAs with P set are translated. An ASBR that is also the NSSA’s ABR clears it, because it would otherwise translate its own LSA and produce a duplicate.
• The translator. When an NSSA has more than one ABR, only one translates, elected by RFC 3101 among the candidates — otherwise the same external would enter the backbone twice. VyOS exposes the election under the NSSA area type, so an ABR can be forced to translate always, or told never to; Part XX covers those settings and when to use them.

The failure mode that actually happens in production is not a Type 7 escaping into the backbone — it cannot, since its flooding scope is the NSSA. It is a Type 7 that stays a Type 7: present and healthy inside the NSSA, with no corresponding Type 5 anywhere else, because no router translated it. Check show ip ospf database nssa-external inside the NSSA and show ip ospf database external outside it, and compare.

Types 9, 10, 11 — Opaque LSAs

Opaque LSAs carry data OSPF itself does not interpret. They exist so that features like MPLS traffic engineering and Segment Routing can use OSPF’s flooding machinery without a new protocol. The three types are the three flooding scopes:

• Type 9 — link-local. Never leaves the link it was sent on.
• Type 10 — area-local. Floods within one area. This is where TE and Segment Routing information lives.
• Type 11 — AS-scoped. Floods the whole domain, and like Type 5 is blocked at stub and NSSA boundaries.

show ip ospf database opaque-link
show ip ospf database opaque-area
show ip ospf database opaque-as

Opaque support is negotiated: the O-bit in the options field says whether a router can handle opaque LSAs. A router that cannot will not be sent them, so a mixed estate degrades rather than breaks. If you are not running TE or SR, these sections are usually empty, and an unexpected entry is worth reading rather than ignoring.

Reading the LSDB — the operational discipline

A standard reading pattern:

# 1. What types are populated, and in which areas
show ip ospf database

# 2. Type by type
show ip ospf database router
show ip ospf database network
show ip ospf database summary
show ip ospf database asbr-summary
show ip ospf database external
show ip ospf database nssa-external
show ip ospf database opaque-area

# 3. What did THIS router put into the database
show ip ospf database self-originate

# 4. One specific LSA, or everything from one originator
show ip ospf database router 2.2.2.2
show ip ospf database router adv-router 2.2.2.2

# 5. What SPF made of it all
show ip ospf route

A healthy database on a stable multi-area network:

• One Type 1 per router per area, with a link count matching what that router actually has in the area.
• One Type 2 per broadcast segment that has a DR, listing every router on that segment.
• Type 3 LSAs from each ABR into each attached area.
• Type 4 LSAs wherever an ASBR lives in a different area from the routers using its externals.
• Type 5 LSAs from each ASBR, visible in every non-stub, non-NSSA area.
• No LSA sitting near MaxAge (3600) that ought to have been refreshed at 1800.

And the diagnostic readings:

• No Type 1 for a router you expect? It is not participating in that area — no adjacency, no matching network statement, or an interface that is passive when it should not be.
• No Type 2 for a broadcast segment? No DR, or the DR has no full adjacency. An adjacency problem wearing an LSA costume.
• A prefix in Type 3 with the wrong length? Summarisation on the ABR is covering more than it was meant to, or not covering what it was meant to.
• Type 5 visible in area 0 but not in area 1? Area 1 is a stub or an NSSA. That is the design working, and the question is whether the design is still right.
• Type 5 not visible anywhere? The ASBR is not originating. Check the redistribution configuration and whether the source route is actually in the RIB — OSPF cannot redistribute a route that is not installed.

Configuration — what controls which LSAs enter an area

The LSA-flooding boundary is a property of the area type, set on every router in the area (and, for the Type 3 filtering variants, on the ABR):

# A standard area: no area-type node at all
set protocols ospf area 1 network 10.1.0.0/16

# Stub: no Type 5, no Type 7; the ABR injects a Type 3 default
set protocols ospf area 1 area-type stub

# Totally stubby: as above, and no Type 3 either
set protocols ospf area 1 area-type stub no-summary

# NSSA: no Type 5, but a local ASBR may originate Type 7
set protocols ospf area 1 area-type nssa

# Totally NSSA: as above, and no Type 3 either
set protocols ospf area 1 area-type nssa no-summary

What each one admits:

Two distinctions that are worth being precise about, because they are routinely conflated:

• The stub default is automatic and per-area: it comes from being a stub ABR, and it is a Type 3.
• The global set protocols ospf default-information originate is a different mechanism entirely: it makes this router an ASBR originating a Type 5 default for the whole domain — which by definition cannot enter a stub or NSSA. Using it does not put a default into your stub areas, and expecting it to is a common and time-consuming mistake.

There is no per-area default-information node in the VyOS OSPF tree for stub areas. For NSSAs the ABR can be told to originate a default into the area, and that option lives under the NSSA area type; Part XX covers it alongside the translator settings.

How it fails — the LSA failure modes

The external is missing inside a stub area

A router inside a stub cannot reach an external destination the rest of the domain reaches fine.

Diagnostic: show ip ospf database external on a backbone router lists the prefix; the same command inside the stub returns nothing; show ip ospf on the stub router shows the area marked as a stub; show ip route 0.0.0.0/0 inside the area shows the ABR’s default.

This is not a fault. It is the area type working exactly as configured. The decision is a design one: accept the default (fine when there is one exit), convert the area to an NSSA if the area itself needs to originate externals, or make it a standard area if it genuinely needs to see them all.

The Type 7 that never became a Type 5

The external is visible inside the NSSA and nowhere else.

Diagnostic: show ip ospf database nssa-external inside the NSSA shows the Type 7 present and refreshing; show ip ospf database external on a backbone router does not list it.

Causes, in the order worth checking: the router you think is the ABR has no interface in the backbone, so it is not an ABR at all and nothing will be translated; another ABR won the translator election and is not translating; or the Type 7’s P-bit is clear, which is correct and expected when the originating ASBR is itself the NSSA’s ABR.

The LSA nobody can delete

A router is decommissioned. Its LSAs are still in the database on every other router, and no command you run locally removes them.

This is worth stating plainly, because the instinct is to reach for a restart and the instinct is wrong. Only the originator of an LSA may withdraw it. RFC 2328 gives that right to the advertising router alone: it flushes its own LSA by re-flooding it at MaxAge. Every other router in the area may only hold the LSA until it ages to MaxAge on its own — up to an hour after the last refresh — and then drop it.

So restarting OSPF on your router does not help. It discards your local copy and then downloads the same LSA back from your neighbours, who still hold it. The options are genuinely limited: wait out the ageing, or bring a router with that router-id back into the area so it can flush its own LSAs. VyOS and FRR expose no operator command to delete another router’s LSA from the database, and any procedure that claims to is describing something else.

In practice this rarely matters, because an LSA from a router that has gone away also stops being reachable in the SPF tree, and an unreachable vertex contributes no routes. The stale entry is untidy rather than dangerous. Where it does matter is router-id reuse: give a new router the router-id of an old one and the two sets of LSAs collide in a way that is much harder to reason about than an hour of untidiness.

Two routers both acting as DR on one segment

You see two Network LSAs for what should be one segment, each advertised by a different router and each listing only a subset of the routers you expect.

OSPF permits exactly one DR per segment, so this is not an OSPF misconfiguration — it is a layer 2 statement. The broadcast domain has been partitioned: a switch, a bridge, or a VLAN mismatch has split the segment into two, and each half elected its own DR without ever hearing the other. Fix the layer 2 partition; the LSAs resolve themselves.

Rollback

Area-type changes are the LSA-related change most likely to need backing out, and the mechanics are unusual enough to plan for.

Removing the area type returns the area to standard:

delete protocols ospf area 1 area-type stub
commit

Two things to expect:

• Every adjacency in the area drops and reforms. The E-bit changes, and the E-bit is checked in the Hello, so the neighbours must re-establish. Until every router in the area has been changed, the ones that have and the ones that have not will not peer with each other.
• The database is rebuilt, not patched. LSAs the area no longer admits are flushed; LSAs it now admits flood in. Expect an SPF run on every router in the area, and expect the default route inside the area to disappear at the moment the stub designation does.

Capture the before-and-after so the change is evidenced rather than remembered:

show ip ospf database > /config/user-data/lsdb-before.txt
show ip ospf > /config/user-data/ospf-before.txt

Production discipline

Cross-course references

• Part XVIII lesson 1 covers how these LSAs are flooded and what triggers the SPF run that consumes them.
• Part XIX (XIX-VyOS-OSPFConfig) covers the redistribution configuration that produces Type 5 LSAs.
• Part XX (XX-VyOS-OSPFAreas) covers area type design, the default-cost and NSSA translator settings, and summarisation on the ABR.
• Part XXII (XXII-VyOS-OSPFTroubleshoot) works the failure modes in this lesson as troubleshooting exercises.
• RFC 2328 appendix A.4 for the LSA formats, RFC 3101 for NSSA, and RFC 5250 for the opaque LSA option.

Quiz