VMware ESXi and vSphere Cluster Management

OSPF Link-State Advertisements (LSAs) Explained

Learn how OSPF LSAs describe topology, synchronize the LSDB, support SPF calculations, and produce routing-table entries.

A Link-State Advertisement (LSA) is an OSPF topology-information record. Depending on its type, an LSA can describe routers, links, multiaccess networks, inter-area prefixes, external routes, or other area-related information.

OSPF routers flood LSAs within a defined flooding scope. Routers use the LSAs they receive to build a shared view of the relevant topology, then calculate routes from that information. An individual LSA is not the same thing as the entire link-state database (LSDB).

LSAs, the LSDB, SPF, and the Routing Table

The normal flow is:

  1. OSPF receives complete LSAs through flooding and database synchronization.
  2. The router stores applicable LSAs in its LSDB.
  3. The SPF algorithm examines the LSDB as a topology graph and uses OSPF interface costs to calculate best paths.
  4. OSPF installs selected results in the IP routing table, subject to route selection and other routing decisions.

The LSDB is therefore not a routing table. An LSDB contains topology records, while a routing table contains usable destination routes and their forwarding information. LSAs do not normally carry a routed packet's next-hop value. Next-hop and outgoing-interface information are derived during route calculation.

Routers in the same area aim to synchronize the relevant LSDB information. OSPF does not require every router in an entire routing domain to have one identical database. Areas and LSA flooding scopes limit which topology records each router receives, reducing database size and SPF work.

ConceptWhat it isRelationship to LSAs
LSAAn OSPF topology recordDescribes a portion of topology or reachability
LSUAn OSPF packetCarries one or more complete LSAs
LSDBA collection of known LSAsProvides the topology input for SPF
SPF calculationShortest Path First processingUses LSDB topology and interface costs to calculate paths
Routing tableInstalled destination routesContains selected results, not raw LSAs

For a detailed review of this subject, see OSPF Link-State Advertisements.

How OSPF Synchronizes LSAs

LSA synchronization occurs while an OSPF neighbor relationship progresses through its states. The most important states for database exchange are ExStart, Exchange, Loading, and Full.

  1. ExStart: The neighbors establish master-and-slave roles and agree on database-exchange sequencing.
  2. Exchange: The routers exchange Database Description packets.
  3. Loading: Each router requests missing or newer LSAs and receives the complete records.
  4. Full: The relevant databases are synchronized, so normal adjacency operation continues.
Packet typeCarriesPurposeTypical neighbor-state context
DBD or DDLSA headers and summariesLets neighbors compare database contents without initially sending every full LSAExStart and Exchange
LSRA request identifying an LSARequests a missing or newer complete LSALoading
LSUOne or more complete LSAsDelivers requested LSAs or floods changed LSAsLoading and normal flooding
LSAckLSA acknowledgment informationConfirms reliable LSA floodingLoading and normal flooding

During Exchange, a router compares the LSA headers in received DBD packets with the headers in its own LSDB. If an LSA is absent or its copy is older, the router sends an LSR. The neighbor returns the requested full LSA in an LSU, and the receiving router acknowledges it with an LSAck. After synchronization, topology changes cause new or updated LSAs to be flooded within their permitted scope.

LSA Structure and Freshness

Every LSA includes a header that helps routers identify, compare, age, and validate it. Important fields include:

FieldPurposeWhy it matters during synchronization
LS ageTracks how long the LSA has existed in the OSPF domainHelps manage lifetime and eventual flushing
OptionsIndicates supported OSPF capabilitiesHelps determine compatibility and handling
LSA typeIdentifies the kind of topology recordDetermines interpretation and flooding behavior
Link State IDIdentifies the advertised object for that LSA typeWorks with type and Advertising Router to identify an LSA
Advertising RouterContains the router ID of the originatorDistinguishes records originated by different routers
Sequence numberVersions successive instances of an LSAUsually identifies which copy is newer
ChecksumValidates LSA contentsHelps detect corruption and participates in freshness comparison
LengthSpecifies the size of the LSAAllows the complete record to be parsed correctly

An LSA is uniquely identified by the combination of LSA type, Link State ID, and Advertising Router. OSPF compares instances using sequence number, checksum, and age rules. In normal operation, a higher sequence number represents a newer version. When sequence numbers are equal, checksum and age rules help determine which instance should be retained.

LS age increases as an LSA is propagated and stored. The originating router periodically refreshes its LSAs, creating a newer instance. MaxAge is the maximum permitted age. A withdrawn or expired LSA can be flooded at MaxAge so routers remove it from their LSDBs after reliable propagation.

Flooding Scope and OSPF Areas

Flooding scope is the portion of the OSPF domain through which an LSA is propagated. Not every LSA is flooded everywhere.

  • Link-local scope: The LSA remains on the local link or interface context. This scope is useful for link-specific information.
  • Area scope: The LSA is flooded throughout an area but normally does not cross the area boundary in its original form.
  • Autonomous-system scope: The LSA can be flooded across the OSPF domain, subject to area-type and policy rules. Type 5 external LSAs are the common CCNA example.

Areas limit detailed topology information and reduce LSDB size and SPF workload. An Area Border Router (ABR) connects multiple areas and advertises inter-area reachability. An Autonomous System Boundary Router (ASBR) injects routes learned from outside OSPF, such as static routes or routes from another routing protocol.

Common OSPFv2 LSA Types

TypeNameOriginated byPurposeFlooding scopeWhere it appears
1Router LSAEvery OSPF routerDescribes the router's OSPF links and interfaces in an areaAreaEach area where the router participates
2Network LSADesignated Router (DR)Describes routers attached to a shared multiaccess networkAreaBroadcast and NBMA segments with a DR
3Summary LSAABRAdvertises network prefixes from one area into anotherInter-area advertisementOther areas receiving the ABR's reachability information
4ASBR Summary LSAABRProvides reachability to an ASBR located in another areaArea/inter-areaAreas that need to reach the ASBR
5AS External LSAASBRAdvertises routes redistributed from outside OSPFAutonomous-system scopeNormal OSPF areas, subject to area-type rules
7NSSA External LSAASBR inside an NSSAAdvertises redistributed external routes within a Not-So-Stubby AreaNSSA areaNSSA; an ABR can translate it to Type 5 when appropriate

Type 2 LSAs are not created on point-to-point links. On a broadcast or NBMA Ethernet-like segment, the DR originates the Type 2 Network LSA. All routers still originate their own Type 1 Router LSAs. Type 6 Group Membership LSAs and Type 8 External Attribute LSAs exist as less common or advanced types, but they are not central to basic OSPF operation.

Example: A broadcast segment

Suppose three routers share one Ethernet segment and elect R1 as DR. Each router originates a Type 1 Router LSA describing its own links. R1 also originates a Type 2 Network LSA listing the routers attached to the shared segment. This network representation is different from a point-to-point link, where no DR and no Type 2 LSA are needed.

Example: Inter-area reachability

An ABR connects Area 0 and Area 10. If a prefix exists inside Area 10, detailed intra-area topology remains within Area 10. The ABR can advertise reachability to that prefix into Area 0 using a Type 3 Summary LSA. Routers in Area 0 can calculate a path to the prefix without receiving every detailed Type 1 LSA from Area 10.

Example: External route injection

If an ASBR redistributes a static route into a normal OSPF area, it originates a Type 5 AS External LSA. When another area must reach that ASBR, an ABR provides the necessary ASBR reachability with a Type 4 ASBR Summary LSA. These records describe external reachability rather than ordinary intra-area link topology.

Worked Example: Two Routers and a LAN

Consider R1 and R2 connected by a point-to-point OSPF link in Area 0. R1 also connects to LAN 10.0.0.0/24. R2 does not have a direct interface on that LAN.

  1. R1 forms an OSPF adjacency with R2. R1's Router LSA describes its OSPF links, including the connection toward the LAN.
  2. During ExStart and Exchange, R1 and R2 exchange DBD packets containing LSA headers and summaries.
  3. R2 compares those headers with its LSDB and notices that the relevant R1-originated LSA is missing or older in its database.
  4. R2 sends an LSR naming the missing or newer LSA.
  5. R1 sends the complete requested LSA inside an LSU.
  6. R2 acknowledges receipt with an LSAck and adds the LSA to its LSDB.
  7. R2 runs SPF as needed. If the resulting path is best, it installs a route to 10.0.0.0/24 in its routing table.

The LSA describes topology and reachability information. R2 derives the path, outgoing interface, and next-hop behavior during SPF and route installation; those forwarding details are not simply copied from an LSA.

Minimal Cisco IOS/IOS XE Lab Configuration

Use addressing and interfaces appropriate to the physical or virtual lab. Give each router a distinct router ID and place the shared link in the same OSPF area.

router ospf 1
 router-id 1.1.1.1
 network 10.0.0.0 0.0.0.255 area 0

On the neighbor, use a different router ID, such as 2.2.2.2, and configure the matching interface and area. The exact network statements depend on the lab addressing.

Operational Verification

Verify the neighbor relationship before inspecting LSAs. A healthy adjacency normally reaches Full; this indicates that the neighbors completed database synchronization for the relevant relationship.

show ip ospf neighbor
show ip ospf interface brief
show ip route ospf

Display the LSDB and inspect the fields that identify and version each LSA:

show ip ospf database
show ip ospf database router
show ip ospf database network
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external

These commands help you identify the LSA type, Link State ID, Advertising Router, sequence number, checksum, and age. Use the type-specific commands to inspect a particular router, network, summary, external, or NSSA external LSA. Then use show ip route ospf and show ip route to confirm which calculated routes were installed.

Consistent LSDB output between adjacent routers, appropriate LSA ages and sequence numbers, a Full neighbor state, and expected OSPF routes generally indicate successful synchronization and SPF processing.

Troubleshooting LSA Synchronization

Neighbor stuck in ExStart or Exchange

Common causes include an MTU mismatch, duplicate router ID, unstable connectivity, or incompatible OSPF parameters. Check:

show ip ospf neighbor
show ip ospf interface

Compare MTU, router IDs, area ID, authentication, hello and dead timers, and network type. If DBD exchange cannot complete, the routers cannot finish comparing LSA headers and cannot reach Full.

Neighbor is Full but a route is missing

First determine whether the needed LSA exists. Check whether the prefix is enabled in OSPF, whether an area type restricts the LSA, whether summarization or filtering changes visibility, and whether another route is preferred.

show ip ospf database
show ip ospf database router
show ip ospf database summary
show ip ospf database external
show ip route

If the expected topology or external-route LSA is absent, investigate flooding and area configuration before analyzing SPF route selection.

Stale topology or route information

Inspect LSA age and sequence number, confirm neighbor and interface state, and compare the LSDB on adjacent routers. A failed flood, connectivity problem, or missing MaxAge update can delay removal. Also confirm that the route is not being learned from another routing source.

Expected Type 2 LSA is absent

Check whether the segment is point-to-point, whether its network type uses a DR, and whether a DR was elected.

show ip ospf interface
show ip ospf neighbor
show ip ospf database network

Type 2 LSAs are created by the DR only for applicable broadcast or NBMA multiaccess networks.

Debugging can show adjacency and packet behavior in a controlled lab:

debug ip ospf adj
debug ip ospf packet

Common Misunderstandings

  • LSAs are not the same as route advertisements in a distance-vector protocol. They are topology records used by a link-state protocol.
  • An LSU is an OSPF packet that can carry one or more LSAs. An LSA is the record inside the packet.
  • A DBD packet normally provides LSA headers for comparison; it does not normally transfer all complete LSAs requested during Loading.
  • OSPF routers do not necessarily have one identical LSDB across the entire routing domain. Synchronization follows area boundaries and LSA flooding scope.
  • The DR originates the Type 2 Network LSA, while every participating router originates its own Type 1 Router LSA.
  • An LSDB is not a routing table. SPF must process the database before routes can be selected and installed.

Exam-Relevant Summary

  • Type 1 describes each router's links within an area.
  • Type 2 describes a multiaccess network and is originated by the DR.
  • Type 3 advertises inter-area prefixes and is originated by an ABR.
  • Type 4 provides reachability to an ASBR from another area.
  • Type 5 advertises external routes in normal OSPF operation.
  • Type 7 advertises external routes inside an NSSA and can be translated by an ABR.
  • DBD summarizes, LSR requests, LSU delivers, and LSAck acknowledges.
  • LSA identity is based on type, Link State ID, and Advertising Router.
  • LSAs enter the LSDB, SPF calculates paths, and selected routes enter the routing table.