OSPF LSA Types Explained: What Each Type Carries and How to Filter Them

Open Shortest Path First is the most widely deployed interior gateway protocol in enterprise networking, and its Link-State Advertisement structure is the mechanism that makes it work. Every routing decision an OSPF router makes traces back to the contents of its Link-State Database, and every entry in that database is an LSA of a specific type, generated by a specific role, flooded within a specific scope. Engineers who can describe that structure precisely are the ones who resolve OSPF incidents in minutes instead of hours.

OSPF defines six LSA types that matter in day-to-day IPv4 operations: Type 1 Router LSA, Type 2 Network LSA, Type 3 Summary LSA, Type 4 ASBR Summary LSA, Type 5 AS External LSA, and Type 7 NSSA External LSA. Types 1 and 2 never leave the area in which they were generated. Types 3, 4, 5 and 7 exist specifically to carry information across an area boundary, and that boundary is the only place where they can be filtered without breaking the protocol's synchronisation guarantee.

This guide provides a complete walkthrough of the OSPF LSA structure and the filtering mechanisms that operate on it. It begins with what each LSA type carries and who generates it, then explains how the special area types — stub, totally stubby, NSSA and totally NSSA — suppress specific LSA types by design. It then examines the four distinct filtering tools Cisco IOS provides, showing precisely where each one acts and which requirement each one satisfies. Finally, it covers the verification workflow and the design mistakes that most commonly produce LSA-related outages in production networks.

What Are the OSPF LSA Types and What Does Each One Carry?

OSPF is a link-state protocol, which imposes a strict requirement: every router inside a given area must hold an identical copy of that area's Link-State Database. Each router independently runs the Shortest Path First algorithm against that database and arrives at the same view of the topology. If two routers in the same area hold different databases, they compute different topologies, and the result is a routing loop or a black hole that no amount of interface troubleshooting will explain.

This requirement is why OSPF filtering behaves so differently from distance-vector filtering. In EIGRP or RIP you can suppress a prefix anywhere along its path with no structural consequence. In OSPF, dropping an LSA in the middle of an area breaks database synchronisation. The protocol therefore provides filtering only at the points where a summary of the topology is being regenerated rather than flooded verbatim — which is to say, at area boundaries and at the autonomous system boundary.

What are the six LSA types I need to know?

The six LSA types you must know for both operational work and certification are: Type 1 Router LSA generated by every router and flooded within one area; Type 2 Network LSA generated by the Designated Router on a multi-access segment and flooded within one area; Type 3 Summary LSA generated by an Area Border Router to advertise inter-area prefixes; Type 4 ASBR Summary LSA generated by an ABR to advertise reachability to an Autonomous System Boundary Router; Type 5 AS External LSA generated by an ASBR for redistributed routes and flooded domain-wide; and Type 7 NSSA External LSA, which carries external routes inside a Not-So-Stubby Area and is translated into a Type 5 by the NSSA ABR.

A Deeper Dive into the LSA Types

Type 1 — Router LSA

Every OSPF-speaking router generates exactly one Router LSA per area in which it has an interface. The LSA describes the router's own directly connected links, the cost of each, and the type of each link — point-to-point, transit, stub, or virtual. It also carries three critically important flag bits: the B bit indicating the router is an Area Border Router, the E bit indicating it is an ASBR, and the V bit indicating it is a virtual link endpoint.

Those flag bits matter more than they appear. A router only behaves as an ABR if it has an interface in area 0 and at least one other area, and the B bit is what advertises that fact to the rest of the area. When an engineer applies an area filter-list command to a router that is not actually an ABR, the command is accepted without error and does absolutely nothing — because the router never generates Type 3 LSAs in the first place. Confirming the B bit is set is the fastest way to rule out that mistake.

Type 2 — Network LSA

On a broadcast or non-broadcast multi-access segment, a full mesh of adjacencies would produce an unmanageable number of Type 1 relationships. OSPF solves this by electing a Designated Router that represents the segment as a pseudonode. The DR generates a Type 2 Network LSA listing every router attached to that segment, and every attached router points at the pseudonode rather than at each other.

Two operational consequences follow. First, a Type 2 LSA exists only where a DR exists — on a point-to-point link there is no DR and therefore no Type 2. Second, if the DR changes, the old Type 2 must be flushed and a new one generated, which is why DR instability produces database churn out of proportion to the actual topology change. Setting ip ospf priority 0 on routers that should never become DR is a standard stability measure.

Type 3 — Summary LSA

When an ABR receives Type 1 and Type 2 LSAs describing an area's internal topology, it does not forward them. Instead it computes the resulting prefixes and their costs, and generates one Type 3 Summary LSA per prefix into the adjacent areas. This is the mechanism that gives OSPF its hierarchy: routers in area 1 know that a prefix in area 2 exists and what it costs to reach, but they know nothing about the topology that produced it.

Because the ABR regenerates rather than relays this information, the Type 3 is the natural filtering point. Suppressing a Type 3 removes a prefix from another area's database entirely and does not break synchronisation, because every router in the receiving area is missing it equally.

Type 4 — ASBR Summary LSA

Type 5 External LSAs are flooded domain-wide and carry the Router-ID of the originating ASBR as the advertising router. A router in a different area therefore needs to know how to reach that ASBR before it can use the external route. The Type 4 supplies exactly that: it is generated by the ABR and advertises reachability to the ASBR's Router-ID.

This produces one of the most common OSPF symptoms in multi-area networks. External routes appear in show ip ospf database external on a remote router but never install in the routing table. The cause is almost always a missing Type 4 — the router has the destination but no path to the advertising ASBR. Checking show ip ospf database asbr-summary resolves it immediately.

Type 5 — AS External LSA

Generated by an ASBR when routes are redistributed into OSPF from another source, the Type 5 is flooded across the entire OSPF domain without modification, crossing every area boundary except into stub and NSSA areas. Two external metric types exist and the difference is frequently tested and frequently misunderstood.

• External Type 2 (E2) is the default. The metric is the external cost only; the internal cost of reaching the ASBR is not added. Every router in the domain sees the same metric, so E2 routes are compared purely on the external value, with the forwarding cost used only as a tie-breaker.
• External Type 1 (E1) adds the internal path cost to the external cost. The metric therefore increases with distance from the ASBR, and each router naturally prefers the closest exit point.

An E1 route is always preferred over an E2 route for the same prefix, regardless of metric values. In a network with two redistribution points where traffic should use the nearest one, E1 is the correct choice; using the default E2 produces an arbitrary and often surprising exit selection.

Type 7 — NSSA External LSA

A Not-So-Stubby Area is one that must block Type 5 LSAs but still needs to originate its own external routes — typically because a branch site has a local Internet circuit or a legacy redistribution point. Type 5 is prohibited in the area, so the local ASBR generates a Type 7 instead. The Type 7 floods within the NSSA only. At the NSSA ABR it is translated into a Type 5 and flooded to the rest of the domain.

The remaining types, briefly

Type 6 was defined for Multicast OSPF and is not implemented by Cisco. Types 8 through 11 exist for OSPFv3 and for opaque LSAs. Type 9 has link-local scope, Type 10 has area scope and is used by MPLS Traffic Engineering, and Type 11 has domain scope. For IPv4 enterprise operations and for the CCNP and CCIE blueprints, the six types above are what matter.

How Do LSA Types Behave in Stub, Totally Stubby and NSSA Areas?

Special area types are the built-in, structural form of LSA filtering. Rather than applying an explicit filter, you declare an area to be of a type that prohibits certain LSAs by definition, and every router in that area enforces the rule automatically. This is both the most scalable approach and the one with the fewest failure modes — but it is also all-or-nothing, which is why explicit filtering still has a role.

Which LSA types are blocked in each area type?

A standard area permits all LSA types. A stub area blocks Types 4 and 5 and receives a default route from the ABR instead. A totally stubby area additionally blocks Type 3, leaving only intra-area LSAs plus a single default route. An NSSA blocks Types 4 and 5 but permits Type 7, allowing the area to originate external routes locally. A totally NSSA blocks Types 3, 4 and 5 while still permitting Type 7. In every case the ABR injects a default route to replace what it has suppressed.

A Deeper Dive into Area Types

Configuring each area type

! Stub area — required on EVERY router in the area
router ospf 1
 area 1 stub

! Totally stubby — no-summary on the ABR only
router ospf 1
 area 1 stub no-summary          ! ABR
 area 1 stub                     ! internal routers

! NSSA
router ospf 1
 area 2 nssa

! Totally NSSA — no-summary on the ABR only
router ospf 1
 area 2 nssa no-summary          ! ABR
 area 2 nssa                     ! internal routers

Type 7 to Type 5 translation

Translation is where NSSA deployments most often break, and the mechanism deserves detail. When multiple ABRs connect an NSSA to the backbone, only one performs translation. The election is automatic and deterministic: the ABR with the highest Router-ID becomes the translator. The other ABRs pass the Type 7 through without converting it.

This default is frequently wrong for the topology. If the highest-Router-ID ABR happens to sit on the slower path, all external traffic from the rest of the domain is drawn toward it. The fix is explicit:

router ospf 1
 area 2 nssa translate type7 always

Applied to the ABR you want to translate, this overrides the election. Applying it to more than one ABR simultaneously produces duplicate Type 5 LSAs for the same prefix from different advertising routers, which is legal but wasteful and can cause unnecessary SPF runs.

The forwarding address problem

A Type 7 LSA contains a forwarding address field, and unlike Type 5 it is normally populated with a real next-hop address rather than 0.0.0.0. The translation rule is strict: the forwarding address must be a route known via OSPF inside the NSSA. If it is not, translation silently fails — no error message, no log entry, simply no Type 5 in the backbone.

The usual cause is that the ASBR's connection to the external network is not advertised into OSPF. The fix is to include that interface in the OSPF process, typically as a passive interface so no adjacency is attempted:

router ospf 1
 network 192.0.2.0 0.0.0.255 area 2
 passive-interface GigabitEthernet0/2

Injecting a default route into an NSSA

Unlike a stub area, a plain NSSA does not automatically receive a default route, because the presence of a local ASBR means the area may legitimately have its own path out. If you want one, request it explicitly:

router ospf 1
 area 2 nssa default-information-originate metric 10 metric-type 1

This generates a Type 7 default from the NSSA ABR. Note that it is not translated into a Type 5 — a default route is meaningful inside the area but would be actively harmful if flooded to the rest of the domain.

What Are the Methods for Filtering OSPF LSAs?

When a special area type is too coarse — when you need to suppress one prefix rather than an entire LSA class — Cisco IOS provides four explicit filtering mechanisms. They are not interchangeable. Each acts at a different layer, each has different prerequisites, and choosing the wrong one produces a configuration that appears correct and does not satisfy the requirement.

 

What are the four filtering mechanisms?

Cisco IOS provides four methods. The area filter-list command applies a prefix-list to Type 3 LSAs entering or leaving an area and works only on an ABR. The area range ... not-advertise command suppresses inter-area summaries at an ABR, while summary-address ... not-advertise does the same for Type 5 LSAs at an ASBR. The distribute-list in command prevents a route installing in the local routing table while leaving the LSA in the database. The ip ospf database-filter all out interface command stops LSA flooding out of a specific interface entirely.

A Deeper Dive into Each Filtering Method

Method 1 — area filter-list, the cleanest tool

This is the mechanism most requirements are actually asking for. It applies a prefix-list to Type 3 LSAs at an ABR, in a stated direction, and removes them from the database of every router on the far side.

! Prevent 10.10.0.0/16 from being advertised into area 1
ip prefix-list NO-10-10 seq 5 deny 10.10.0.0/16
ip prefix-list NO-10-10 seq 10 permit 0.0.0.0/0 le 32
!
router ospf 1
 area 1 filter-list prefix NO-10-10 in

Direction is expressed relative to the area, not the router. in filters Type 3 LSAs being generated into area 1 from every other area. out filters Type 3 LSAs being generated out of area 1 toward all other areas. Getting this backwards is common; verify by checking the database on a router inside the area rather than on the ABR itself.

Method 2 — area range and summary-address with not-advertise

Both commands normally perform aggregation. Adding not-advertise converts them into suppression tools, which is often the fastest way to hide an entire block.

! On an ABR — suppress inter-area summary for the whole block
router ospf 1
 area 1 range 10.10.0.0 255.255.0.0 not-advertise

! On an ASBR — suppress the external LSA
router ospf 1
 summary-address 172.16.0.0 255.255.0.0 not-advertise

Note the division of responsibility precisely: area range operates on Type 3 at an ABR, summary-address operates on Type 5 at an ASBR. Applying area range on an ASBR that is not also an ABR has no effect, and vice versa.

Aggregation itself is worth understanding as a resiliency measure, not merely a scaling one. When an ABR advertises a summary, a flap on an individual prefix inside the area produces no LSA change outside it, so no remote router runs SPF. Summarisation therefore bounds the blast radius of local instability — in a large multi-area network this matters more than the reduction in table size.

Method 3 — distribute-list in, and why it is different

This is the mechanism that most often gets chosen incorrectly, so the distinction deserves stating plainly. A distribute-list in applied under the OSPF process does not remove anything from the Link-State Database. The LSA is still received, still flooded onward, still present in show ip ospf database. What the command does is prevent the resulting route being installed in that one router's RIB.

router ospf 1
 distribute-list prefix NO-10-10 in

This is not a limitation — it is a deliberate design decision that preserves database synchronisation, which is why Cisco permits it at all. It maps to a specific class of requirement:

• If the requirement is "router R5 must not install this route", distribute-list in is correct and is the only tool that works on a non-ABR.
• If the requirement is "the LSA must not appear in the database of area 1", distribute-list in is wrong and will not pass verification.

Reading the requirement carefully enough to know which of those two you are being asked for is, in practice, the whole skill.

Method 4 — database-filter all out

Applied to an interface, this stops OSPF flooding any LSA out of that interface while leaving the adjacency established.

interface GigabitEthernet0/1
 ip ospf database-filter all out

It is a blunt instrument and it will desynchronise databases if applied carelessly — which is precisely why it exists. The legitimate use case is a topology where flooding across a particular link is unnecessary and expensive: a low-bandwidth backup circuit, or a hub-and-spoke overlay where the hub already floods to every spoke and spoke-to-spoke flooding would be redundant. Outside those cases, reach for one of the first three tools.

Choosing the right tool

How Do I Verify and Troubleshoot OSPF LSA Problems?

OSPF problems are diagnosed from the database outward, not from the routing table inward. The routing table is the output of a computation; if it is wrong, the input was wrong, and the input is the LSDB. A disciplined verification sequence resolves most OSPF incidents faster than any amount of interface-level investigation.

What commands show me what is actually in the database?

Start with show ip ospf database database-summary for a count of each LSA type held by the router. Then query the specific type you are investigating with show ip ospf database summary for Type 3, asbr-summary for Type 4, external for Type 5, or nssa-external for Type 7. Use show ip ospf database router adv-router <RID> to inspect a specific router's Type 1 and confirm its ABR and ASBR flags. Confirm the router's own role with show ip ospf interface brief and show ip ospf.

A Deeper Dive into Verification and Troubleshooting

The standard verification sequence

! 1. What does this router hold, by type?
show ip ospf database database-summary

! 2. Is the specific LSA present?
show ip ospf database summary 10.10.0.0
show ip ospf database external 172.16.0.0
show ip ospf database asbr-summary

! 3. Is this router actually an ABR / ASBR?
show ip ospf | include Area|border|boundary
show ip ospf interface brief

! 4. Confirm the role flags in the Type 1
show ip ospf database router adv-router 5.5.5.5

! 5. Who is translating Type 7?
show ip ospf | include NSSA|ranslat

Reading LSA age and recognising a flush

Every LSA carries an age field that increments in seconds. The originating router refreshes it every 1800 seconds (30 minutes). When the age reaches 3600 seconds, the LSA has reached MaxAge and is removed from the database throughout its flooding scope.

Two age patterns are diagnostic. An LSA whose age is consistently near 3600 across the network indicates the originator has stopped refreshing — the router has failed, the process has stopped, or reachability to it is broken. An LSA whose age repeatedly resets to zero at short intervals indicates the originator is regenerating it constantly, which points at interface flapping or an unstable DR election on a multi-access segment.

show ip ospf database | include Age|Link ID
! Watch the same LSA across two samples 60 seconds apart
show ip ospf statistics                  ! SPF run frequency and triggers
show ip ospf database router | include Advertising|Age

The five failure patterns that cover most incidents

Confirming the filter did what you intended

Verify on the wrong device and you will confirm nothing. The rule is simple: check the database on a router that sits on the receiving side of the filter, not on the ABR that applies it. The ABR still holds the LSA it is choosing not to regenerate.

! On a router INSIDE the filtered area — must return nothing
show ip ospf database summary 10.10.0.0

! And confirm the route is gone from the RIB as a consequence
show ip route 10.10.0.0

What Design Mistakes Cause LSA Problems in Production Networks?

Most OSPF incidents in live networks are not configuration typos. They are design decisions made years earlier that only reveal themselves once the network grows past a certain size or a particular failure occurs. Recognising these patterns is the difference between fixing a symptom and fixing a cause.

What are the most common OSPF design mistakes?

The recurring mistakes are: allowing an area to grow too large so that every topology change triggers a domain-wide SPF run; failing to summarise at ABRs so that instability propagates freely; redistributing without filtering or tagging, producing external LSA floods; leaving all routers eligible for DR election on multi-access segments; using a discontiguous backbone patched with virtual links as a permanent design rather than a temporary fix; and mismatched MTU between neighbours, which prevents database exchange from ever completing.

A Deeper Dive into Design Failure Modes

Areas that grew too large

There is no fixed maximum router count for an OSPF area, and any specific number quoted as a rule is misleading. The real constraint is the product of three factors: how many routers are in the area, how frequently the topology changes, and how much CPU each router has to run SPF. An area of 50 stable routers is fine; an area of 25 routers with a flapping WAN circuit is not.

The symptom is a network where an unrelated remote link failure causes a brief, unexplained latency spike everywhere. The cause is that every router in the area is running SPF simultaneously. The fix is either to split the area or — usually more practical — to stabilise the flapping element and apply SPF throttling:

router ospf 1
 timers throttle spf 50 200 5000
 timers throttle lsa 50 200 5000
 timers lsa arrival 100

No summarisation at the ABR

OSPF does not summarise automatically. If nobody configures area range, every prefix from every area is carried as an individual Type 3 into every other area, and every flap generates a domain-wide LSA update. This is the single most common scaling failure in enterprise OSPF, and it is invisible until the network reaches the size where it hurts.

router ospf 1
 area 1 range 10.1.0.0 255.255.0.0
 area 2 range 10.2.0.0 255.255.0.0

Effective summarisation requires an address plan that allocates contiguous blocks per area. Retrofitting summarisation onto a network whose addressing grew organically is often impossible without renumbering — which is why the address plan is an OSPF design decision, not merely an IP administration one.

Uncontrolled redistribution

Redistributing BGP or a large static route set into OSPF without filtering generates one Type 5 LSA per prefix, flooded to every router in the domain that is not in a stub or NSSA area. A few thousand prefixes redistributed by accident will destabilise an otherwise healthy network within minutes.

! Always filter and always tag
route-map BGP-TO-OSPF permit 10
 match ip address prefix-list ALLOWED-EXTERNALS
 set tag 100
!
router ospf 1
 redistribute bgp 65001 subnets route-map BGP-TO-OSPF

The tag serves a second purpose in any topology with two or more redistribution points: matching on it in the reverse direction prevents a route being redistributed back into its protocol of origin, which is the standard cure for mutual-redistribution routing loops.

Uncontrolled DR election

On every multi-access segment, OSPF elects a DR and a BDR. Leaving all routers at the default priority of 1 means the election is decided by Router-ID, which is effectively arbitrary and can change when a router reloads. Since a DR change forces the old Type 2 to be flushed and a new one generated, arbitrary elections produce avoidable database churn.

interface GigabitEthernet0/0
 ip ospf priority 100        ! intended DR
!
interface GigabitEthernet0/0
 ip ospf priority 0          ! never eligible

Where the segment is genuinely point-to-point despite being Ethernet — a routed link between two switches, for instance — the better answer is to remove the DR election entirely with ip ospf network point-to-point. This also removes the Type 2 LSA and speeds up adjacency formation.

Virtual links used as permanent architecture

A virtual link repairs a backbone that has become discontiguous, by tunnelling an extension of area 0 through a transit area. It is a legitimate and necessary tool during a merger, a migration, or an outage. It is a poor permanent design, because it adds a dependency on the transit area's stability and because it is invisible in a topology diagram — the next engineer will not know it is there.

router ospf 1
 area 1 virtual-link 3.3.3.3

If a virtual link has been in place for more than one change cycle, the correct action is to fix the underlying topology by extending area 0 physically, not to leave the virtual link in production indefinitely.

MTU mismatch

OSPF exchanges its Database Description packets during the EXSTART and EXCHANGE states, and it verifies that both neighbours agree on interface MTU. A mismatch prevents the exchange completing, and the adjacency oscillates between EXSTART and EXCHANGE indefinitely. This is extremely common where a tunnel, a VLAN sub-interface, or a jumbo-frame-enabled link meets a device configured with defaults.

! Correct fix — make the MTUs match
interface GigabitEthernet0/1
 mtu 9100

! Workaround only when you cannot change one side
interface GigabitEthernet0/1
 ip ospf mtu-ignore

mtu-ignore suppresses the check rather than resolving the mismatch. It brings the adjacency up, but oversized LSAs may still be dropped in transit, producing intermittent database inconsistency that is considerably harder to diagnose than the original stuck adjacency. Treat it as a temporary measure.

Conclusion

OSPF LSA types are not a memorisation exercise. They are a map of how information moves through the protocol, and every operational behaviour follows from that map. Types 1 and 2 describe topology and stay inside one area, which is what makes the intra-area database consistent and what makes SPF correct. Types 3, 4, 5 and 7 exist to carry summarised information across boundaries, and because they are regenerated rather than relayed, those boundaries are the only points where information can be removed without breaking the protocol's guarantees.

That structural fact determines everything about filtering. Special area types — stub, totally stubby, NSSA and totally NSSA — suppress entire LSA classes by definition and are the most scalable approach when the whole class is unwanted. When the requirement is narrower, the four explicit mechanisms each act at a different layer: area filter-list and the not-advertise variants of area range and summary-address modify the database at a boundary; distribute-list in modifies only the local routing table and leaves the database intact; and ip ospf database-filter all out blocks flooding at the interface. Matching the mechanism to the layer named in the requirement is the entire decision.

In production, the problems that consume the most time are rarely syntax. They are areas that outgrew their design, ABRs that never summarised, redistribution that was never filtered, and MTU mismatches introduced by a change nobody connected to routing. Building the habit of diagnosing from the Link-State Database outward — confirming what is actually in the database, on the receiving side of the boundary, before touching any configuration — is what turns an OSPF incident from an afternoon into ten minutes.

External Links Recommendations

1. RFC 2328 — OSPF Version 2, the authoritative specification for all LSA types and flooding rules
2. RFC 3101 — The OSPF Not-So-Stubby Area (NSSA) Option, including Type 7 translation and forwarding address rules
3. RFC 5340 — OSPF for IPv6, for the OSPFv3 LSA types and scoping model
4. Cisco IP Routing Technology Support Documentation, the entry point for IOS and IOS-XE OSPF configuration guides
5. Cisco Learning Network, for community discussion and official exam topic references
6. Cisco Certifications Overview, for current CCNA, CCNP and CCIE blueprint documents

Reference Notes

1. LSA type definitions, flooding scope and the MaxAge value of 3600 seconds — RFC 2328, Sections 12 and 13.
2. Router LSA flag bits (B, E, V) and their role in ABR and ASBR identification — RFC 2328, Section A.4.2.
3. Type 7 to Type 5 translation, translator election by highest Router-ID, and forwarding address requirements — RFC 3101, Sections 2.5 and 3.
4. External metric types E1 and E2, and the rule that E1 is always preferred over E2 — RFC 2328, Section 16.4.
5. Stub and NSSA option bits carried in the Hello packet, and the resulting adjacency requirement — RFC 2328, Section A.2.
6. OSPF LSA refresh interval of 1800 seconds — RFC 2328, Section 12.4.
7. Cisco IOS command syntax for area filter-list, area range, summary-address, distribute-list and ip ospf database-filter — Cisco IOS IP Routing: OSPF Command Reference.
8. SPF and LSA throttling behaviour and default values — Cisco IOS IP Routing: OSPF Configuration Guide, OSPF Shortest Path First Throttling.
9. OSPF MTU verification during Database Description exchange — RFC 2328, Section 10.6.
10. Virtual link transit area restrictions (no stub, totally stubby or NSSA transit area) — RFC 2328, Section 15.