OSPF area types — backbone, standard, stub, totally stubby, NSSA, totally NSSA

An OSPF area is a flooding boundary. Inside the boundary, every router must hold an identical link-state database (LSDB) and re-run SPF on every change. Across the boundary, an Area Border Router (ABR) summarises the topology with Type 3 Summary LSAs and filters the LSAs the area is not allowed to learn. The choice of area type is the choice of which LSAs the ABR is allowed to inject across the boundary.

This lesson catalogues the six area types RFC 2328 and RFC 3101 define: the backbone, the standard non-backbone area, the stub area, the totally stubby area, the Not-So-Stubby Area (NSSA), and the totally NSSA. xx-02 goes deep on the stub / NSSA mechanism. xx-03 covers summarisation at the ABR. xx-04 covers the virtual-link escape hatch. xx-05 covers the design patterns that decide which area type a site should run. xx-06 covers the operational failure modes that surface when the type is wrong.

The catalogue at a glance

The columns that say “no” are the engineering guarantee of each area type: the LSA type the area must not learn is filtered at the ABR. The columns that say “yes” are the price: the area still needs to reach those destinations, so the ABR injects a default route (Type 3 with metric 10 for stub / NSSA, a single default for the totally variants).

flowchart LR
  subgraph "Backbone area 0"
    ABR1[ABR-1]
    ABR2[ABR-2]
    ASBR[ASBR — external]
  end
  subgraph "Standard area 10"
    R10A[R-A]
    R10B[R-B]
  end
  subgraph "Stub area 20"
    R20A[R-A]
    R20B[R-B]
  end
  subgraph "NSSA area 30"
    R30A[R-A]
    R30ASBR[ASBR-NSSA — redistributes static]
  end
  ABR1 --- R10A
  ABR1 --- R20A
  ABR2 --- R10B
  ABR2 --- R30A
  ASBR -. "Type 5 (external)" .-> ABR1
  ABR1 -. "Type 5" .-> ABR2
  ABR1 -- "no Type 5 to stub" --> R20A
  ABR2 -- "no Type 5 to NSSA" --> R30A
  R30ASBR -- "Type 7" --> ABR2
  ABR2 -- "Type 7 -> Type 5 (P-bit set)" --> ASBR

Backbone area 0

The backbone area is special in two ways. First, every other area must connect to it through an ABR — the OSPF topology is a hub-and-spoke with the backbone as the hub. Second, every Type 3 summary LSA that crosses an ABR originates from an ABR attached to the backbone, so the backbone is the only area where inter-area prefixes have a transit path that every router can validate against the LSDB.

A router can be a member of the backbone in two ways: directly, by having at least one interface in area 0, or indirectly, by being an ABR with at least one interface in area 0 and at least one in another area. The second case is normal; the first is what makes the backbone physically present in a router. A router with no interface in area 0 is not in the backbone and cannot inject inter-area prefixes on its own.

The backbone carries every LSA type the routing domain allows. There is no restriction on Type 5 (external), Type 3 (inter-area summary), or Type 4 (ASBR-summary). The design trade-off is that the backbone LSDB can grow very large in a multi-area estate, which is why operators limit summarisation at the area boundary (xx-03) and limit the number of areas a router is a member of (xx-05).

flowchart TB
  subgraph "Backbone area 0.0.0.0"
    direction LR
    ABR1[ABR-1]
    ABR2[ABR-2]
    ABR3[ABR-3]
    ABR4[ABR-4]
    EXT[ASBR<br/>redistributes BGP]
    ABR1 --- ABR2
    ABR2 --- ABR3
    ABR3 --- ABR4
    ABR4 --- ABR1
    EXT --- ABR1
  end
  ABR1 --- A10[Area 10<br/>standard]
  ABR2 --- A20[Area 20<br/>stub]
  ABR3 --- A30[Area 30<br/>NSSA]
  ABR4 --- A40[Area 40<br/>totally-stubby]

VyOS 1.5 LTS configuration:

set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.0.1.0/24
set protocols ospf area 0 authentication message-digest
set protocols ospf area 0 message-digest-key 1 md5-key 'change-me'

The area 0 keyword is the literal area ID. VyOS accepts area 0 as a shorthand for area 0.0.0.0; the underlying FRR configuration uses the fully-qualified dotted form. An operator who types set protocols ospf area 0.0.0.0 gets the same result.

Standard non-backbone area

A standard non-backbone area is the default. It accepts every LSA type the routing domain carries — Type 1, Type 2, Type 3, Type 4, Type 5, and Type 7 are all allowed (Type 7 is only originated in NSSA, see below, but the standard area accepts them if an ABR forwards them). The area runs its own SPF computation against its own LSDB and learns external prefixes from Type 5 LSAs the ABR floods in.

The standard area is the right choice when the area must learn external prefixes for itself (e.g. a transit area for a regional aggregation point) or when it cannot tolerate the default-route injection that the stub variants perform. The cost is LSDB size: every Type 5 LSA in the routing domain is present in every standard area.

VyOS 1.5 LTS does not require an explicit keyword to mark an area as standard. The absence of area-type stub or area-type nssa is what makes it standard. The configuration is:

set protocols ospf area 10 network 192.168.10.0/24

A standard area carries every LSA — design discipline is what limits what it sees. Summarisation at the ABR (xx-03) is the primary tool.

Stub area

A stub area blocks two LSA types at the ABR: Type 5 (external) and Type 4 (ASBR-summary). The motivation is that a remote site does not need to learn every external prefix in the routing domain — it needs to reach the Internet, and the Internet is reachable via a default route the ABR injects. The stub area’s LSDB shrinks dramatically (no Type 5 LSAs) and the SPF calculation has fewer inputs.

The ABR injects a default route (Type 3 Summary LSA with destination 0.0.0.0/0 and metric 10 by default) into the stub area. Every intra-stub router installs that default route and uses it for every destination not explicitly summarised by an inter-area Type 3 LSA.

The restrictions are:

• No Type 5 LSAs cross the ABR into the stub. External prefixes are invisible to the stub.
• No Type 4 LSAs cross the ABR into the stub. The stub has no view of where external redistributors are.
• No ASBR may live inside the stub. Type 5 LSAs originate from an ASBR; a stub cannot contain an ASBR by definition.
• The stub cannot be the transit area for a virtual link. Virtual links require a transit area that carries Type 5 / Type 4 traffic in a regular form (xx-04).

VyOS 1.5 LTS configuration:

set protocols ospf area 20 network 192.168.20.0/24
set protocols ospf area 20 area-type stub

The area-type stub line is the only configuration difference between a standard and a stub area. Every router in the area must agree on the type; a mismatch surfaces as an adjacency failure (xx-06).

Totally stubby area

A totally stubby area is a stub with a stronger filter: the ABR suppresses not just Type 5 / Type 4 but also Type 3 inter-area summaries, and injects a single default route. The LSDB inside the totally stubby area contains only the area’s own Type 1 / Type 2 LSAs plus the default route from the ABR.

This is the Cisco term for what RFC 2328 calls “stub area with no summary”. RFC 2328 specifies the mechanism; the operator-facing name stuck. VyOS 1.5 LTS implements it with the keyword no-summary appended to the area-type stub declaration:

set protocols ospf area 40 network 192.168.40.0/24
set protocols ospf area 40 area-type stub no-summary

The no-summary flag is set on the ABR. The intra-area routers do not need the flag (their configuration just says area-type stub); the ABR is the only router that injects summaries, so it is the only router that needs to be told to suppress them.

The trade-off is sharper than the plain stub: the area is operationally simpler but loses the ability to see inter-area prefixes for monitoring or for policies that key off specific destinations. A typical use is a remote branch with a single uplink — the branch does not need to see the corporate inter-area topology, only a default route out.

flowchart LR
  subgraph "Area 40 — totally stubby"
    R40A[R-A]
    R40B[R-B]
  end
  ABR[ABR]
  subgraph "Backbone area 0"
    CORE[Core]
  end
  R40A --- ABR
  R40B --- ABR
  ABR --- CORE
  ABR -. "default only (Type 3 0.0.0.0/0)" .-> R40A
  ABR -. "default only" .-> R40B
  R40A -. "no Type 3 / 5 / 4" .-> R40B

NSSA — Not-So-Stubby Area

NSSA solves a problem the plain stub cannot: the operator has a remote site that needs to run an ASBR (typically to redistribute static routes or a locally-run BGP session) but cannot tolerate Type 5 LSAs in the area. RFC 3101 introduces the Type 7 LSA — the NSSA-internal form of an external prefix.

A Type 7 LSA originates inside the NSSA from the ASBR-NSSA. It carries the same external-prefix information a Type 5 LSA would carry (prefix, mask, metric, forward address, tag). The Type 7 LSA is flooded only inside the NSSA. When the NSSA’s ABR receives a Type 7 LSA with the P-bit (propagate bit) set, it translates the Type 7 to a Type 5 LSA and floods the Type 5 into the rest of the OSPF domain. The rest of the domain sees the prefix as an ordinary OSPF external.

The restrictions are otherwise identical to the plain stub: no Type 4 / Type 5 cross the ABR inbound. The differences:

• Type 7 LSAs originate inside the NSSA. Only NSSA ASBRs can originate Type 7.
• The P-bit is the contract. An ASBR-NSSA that wants its Type 7 translated to a Type 5 at the ABR must set the P-bit. An ASBR-NSSA that wants the prefix to stay inside the NSSA only must clear the P-bit.
• The ABR can refuse translation. A “NSSA totally” ABR can be configured to suppress summary LSAs and inject only a default, the same way a totally stubby ABR does. That variant is the totally NSSA, covered next.

VyOS 1.5 LTS configuration:

set protocols ospf area 30 network 192.168.30.0/24
set protocols ospf area 30 area-type nssa

On the ASBR-NSSA, redistribution is configured separately:

set protocols ospf area 30 nssa redistribute static

Or, for a redistribution with explicit parameters:

set protocols ospf area 30 nssa default-information-originate metric 10 metric-type 1

Totally NSSA

The totally NSSA is the NSSA analogue of the totally stubby: the ABR suppresses Type 3 inter-area summaries and Type 4 / Type 5, and injects only a single default route. The NSSA still allows Type 7 LSAs to originate and be translated to Type 5 at the ABR.

VyOS 1.5 LTS configuration:

set protocols ospf area 50 network 192.168.50.0/24
set protocols ospf area 50 area-type nssa no-summary

The no-summary flag is set on the ABR. The intra-area routers use area-type nssa without no-summary.

flowchart LR
  subgraph "Area 50 — totally NSSA"
    R50A[R-A]
    R50B[R-B]
    R50ASBR[ASBR-NSSA<br/>redistributes static]
  end
  ABR[ABR]
  subgraph "Backbone area 0"
    CORE[Core]
  end
  R50A --- ABR
  R50B --- ABR
  R50ASBR --- R50A
  ABR --- CORE
  ABR -. "single default 0.0.0.0/0" .-> R50A
  ABR -. "single default" .-> R50B
  R50ASBR -- "Type 7 (P-bit set)" --> R50A
  R50A -- "Type 7" --> ABR
  ABR -- "translate Type 7 -> Type 5" --> CORE

How it is configured

The VyOS 1.5 LTS configuration tree for OSPF area types:

set protocols ospf area <id> network <prefix>
set protocols ospf area <id> area-type stub [no-summary]
set protocols ospf area <id> area-type nssa [no-summary]
set protocols ospf area <id> nssa default-information-originate [metric <m>] [metric-type 1|2]
set protocols ospf area <id> nssa redistribute <kernel|static|connected|bgp|...>
set protocols ospf area <id> authentication [message-digest|null]
set protocols ospf area <id> range <prefix> [not-advertise] [substitute <prefix>]

The area-type keyword is mutually exclusive — an area is either standard, stub, or NSSA. The no-summary keyword applies to either stub or NSSA and makes it the totally variant.

How the result is validated

show ip ospf
show ip ospf database
show ip ospf database stub
show ip ospf database nssa-external
show ip ospf border-routers
show ip ospf interface
vtysh -c 'show ip ospf'
vtysh -c 'show ip ospf database'

What the operator looks for:

• show ip ospf lists every area the router is a member of and the Stub flag in the per-area section. A stub area shows Stub; a NSSA shows NSSA; a standard area shows nothing.
• show ip ospf database lists LSA types present. A stub area must NOT show External (Type 5) LSAs in its database. A NSSA shows NSSA-external (Type 7) LSAs.
• show ip ospf border-routers lists the ABRs and ASBRs visible from the area. A stub area sees ABRs but not ASBRs.

How it fails

The production failure modes:

• Area-type mismatch. Every router in an area must agree on the type. A standard router in a stub area (or vice versa) refuses to form an adjacency. The error is a state stuck in Down / Init with area-type-mismatch in the show ip ospf neighbor output.
• Type 5 leaked into a stub area. A misconfigured ASBR that redistributes external routes into a stub area gets a commit error from FRR. The symptom is a refused commit, not silent acceptance.
• Type 7 with P-bit clear. An ASBR-NSSA redistributes static routes, but the routes do not appear outside the NSSA. The diagnostic is show ip ospf database nssa-external showing the prefix with the P-bit clear.
• Stub area used as transit for a virtual link. The ABR rejects the virtual-link configuration because the transit area must be standard. The fix is to convert the transit area to standard or to choose a different transit area.
• A summarisation range includes external prefixes in a stub area. A range statement on the ABR for a stub area can only summarise Type 3 (inter-area) LSAs; external prefixes are not in the area and cannot be summarised.

Rollback

The rollback for an area-type change is the same as any OSPF change: use compare before commit, capture the running configuration, and have the commit-confirm window set short if the change is on a remote router.

compare
commit-confirm 5

If the area-type change causes an adjacency loss and the router is remote, the commit-confirm rollback restores the previous type and the adjacencies re-form. If the change is on the local console and the adjacencies do not re-form, the operator runs:

rollback 1
commit

Production discipline

Cross-course references

• The OSPF fundamentals part (XVIII) covers the LSA types in detail (vyos-xviii-03-lsa-types) and the area concept (vyos-xviii-04-areas).
• The OSPF configuration part (XIX) covers the basic area and interface configuration (vyos-xix-03-ospf-area-config) that this lesson extends.
• The stub / NSSA mechanism in depth is the next lesson (vyos-xx-02-stub-nssa).
• The summarisation behaviour at the ABR (vyos-xx-03-summarisation) interacts with the area-type restrictions described here.
• The virtual-link lesson (vyos-xx-04-virtual-links) shows why the stub / NSSA restriction on transit areas matters.

Quiz