OSPF area configuration — area types, area range, and per-area authentication

Every interface on an OSPF router belongs to exactly one area. The area block in VyOS controls what is allowed inside that area: whether the area accepts external routes (Type-5 LSAs), whether the area generates a default route into itself, whether the area is permitted to carry NSSA-external routes (Type-7 LSAs), whether the area aggregates prefixes at the ABR, and what authentication the area requires.

This lesson covers the three area types production deployments actually use (stub, totally-stubby, NSSA), the area-range aggregation primitive, and the per-area authentication block.

The area types — what each one permits

OSPF has four area types in VyOS 1.5 LTS / FRR 10.x:

The trade-off is LSDB size and SPF cost in exchange for routing flexibility. A totally-stubby area has the smallest LSDB (only intra-area routes and a default), at the cost of being unable to learn about external routes from any source — including from a partner’s redistribution.

flowchart TB
  subgraph Backbone["Backbone area 0"]
    ABR["ABR<br/>VyOS R2"]
    EXT["external routes<br/>(Type-5)"]
  end
  subgraph Area10["Area 10 totally-stubby"]
    R3["R3 (VyOS)<br/>area 10 stub no-summary"]
    R4["R4"]
    INTRA["intra-area routes<br/>(Type-1, Type-2)"]
    DEF["default 0.0.0.0/0<br/>(Type-3 from ABR)"]
  end
  ABR -- "Type-3 default into area 10" --> R3
  ABR -. "Type-5 external NOT flooded into area 10" .-> R3
  ABR -. "Type-3 summary NOT flooded into area 10" .-> R3
  R3 --> INTRA
  R3 --> DEF

Configuring a stub area

A stub area does not accept Type-5 LSAs from outside the area. The ABR injects a default route (0.0.0.0/0) into the area as a Type-3 Summary LSA so routers in the stub area have a default for any prefix they don’t know about.

set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 10 stub
set protocols ospf area 10 network 10.50.0.0/24
commit
save

Every router that has an interface in area 10 must agree that area 10 is a stub area. If one router has area 10 stub and another has area 10 standard, the area-mismatch flags in the Hello packet will prevent the adjacency from forming.

A stub area is appropriate for: small remote sites that need to reach the Internet through a central site, DMZ segments where the operator does not want external route churn, and any deployment where the trade-off (no external routes, gain a default) is acceptable.

Configuring a totally-stubby area

A totally-stubby area is a stub area that also does not accept Type-3 Summary LSAs from other areas. The only Type-3 in the area is the default route injected by the ABR. The LSDB inside a totally-stubby area contains only Type-1 (router) LSAs, Type-2 (network) LSAs, and the single default Type-3.

set protocols ospf area 10 stub no-summary
commit
save

no-summary is the keyword that turns a stub area into a totally-stubby area. The keyword is configured only on the ABR — the routers inside the totally-stubby area continue to configure area 10 stub (without no-summary). The no-summary flag on the ABR tells the ABR not to flood Type-3 LSAs into the area except for the default.

Configuring an NSSA

A Not-So-Stubby Area is a hybrid: external routes can be redistributed into the NSSA as Type-7 LSAs (NSSA-external), but the area does not accept Type-5 LSAs from the rest of the OSPF domain. The ABR translates Type-7 into Type-5 when it leaves the NSSA, so the rest of the domain sees the external route as ordinary Type-5.

set protocols ospf area 10 nssa
set protocols ospf area 10 nssa default-information originate
commit
save

The canonical use case for an NSSA is a remote site that runs an IGP internally and redistributes a partner’s BGP routes into OSPF at the remote site. The remote site is not a stub (it has external routes to inject), but it also does not need to receive the backbone’s full external route table.

flowchart TB
  subgraph Area10["Area 10 NSSA"]
    R3["R3<br/>area 10 nssa<br/>redistributes BGP into OSPF"]
    R4["R4<br/>area 10 nssa"]
    T7["Type-7 LSAs<br/>from R3"]
  end
  subgraph Backbone["Backbone area 0"]
    ABR["ABR<br/>translates Type-7 to Type-5"]
    R1["R1<br/>standard area"]
    R2["R2<br/>standard area"]
  end
  R3 -- "Type-7 NSSA-external" --> ABR
  ABR -- "Type-5 external (translated)" --> R1
  ABR -- "Type-5 external (translated)" --> R2
  ABR -. "Type-3 summary into area 10" .-> R3

Area range — summarising at the ABR

An ABR with interfaces in a non-backbone area can summarise multiple intra-area prefixes into a single Type-3 Summary LSA that floods into the backbone. The configuration is area-range at the area block:

set protocols ospf area 10 range 10.50.0.0/16
set protocols ospf area 10 range 10.50.0.0/16 cost 20
commit
save

This tells the ABR: instead of flooding Type-3 LSAs for 10.50.0.0/24, 10.50.1.0/24, 10.50.2.0/24, …, generate a single Type-3 LSA for 10.50.0.0/16. The LSDB inside the backbone (and inside other non-stub areas reachable through the backbone) carries one Type-3 LSA instead of 256.

flowchart LR
  subgraph Area10["Area 10"]
    S1["10.50.0.0/24"]
    S2["10.50.1.0/24"]
    S3["10.50.2.0/24"]
    S4["... up to /24 #256"]
  end
  subgraph ABRb["ABR"]
    A["area 10 range 10.50.0.0/16"]
  end
  subgraph Backbone["Backbone area 0"]
    B["Type-3 LSA<br/>10.50.0.0/16<br/>cost 20"]
  end
  S1 --> A
  S2 --> A
  S3 --> A
  S4 --> A
  A --> B

The cost keyword sets the cost of the summary LSA; the default is the auto-cost of the ABR’s interface into the backbone. The summary’s cost becomes the cost of the entire range as seen from outside area 10.

Per-area authentication

Per-area authentication overrides per-interface authentication for every interface in the area. The configuration block is set protocols ospf area <id> authentication:

set protocols ospf area 10 authentication plaintext-password SECRET
set protocols ospf area 10 authentication md5 key-id 1 md5-key SECRET
commit
save

The authentication block supports the same authentication types as per-interface authentication (plaintext, MD5, SHA-256, key-chain — covered in detail in lesson xix-05). Per-area authentication is the right choice when an entire area must share a single authentication policy; per-interface authentication is the right choice when individual links need different keys.

The matching requirement: every router with an interface in the area must agree on the authentication type and key. A router inside area 10 with MD5 key-id 1 and a router inside area 10 with plaintext will not form an adjacency; the Hello packets will fail the authentication check at one end.

How the result is validated

show ip ospf border-routers                # ABRs and ASBRs in the local LSDB
show ip ospf database                      # the LSDB summary, area-by-area
show ip ospf database stub                 # Type-3 default in a stub area
show ip ospf database nssa-external        # Type-7 LSAs in an NSSA
show ip ospf database external             # Type-5 LSAs (should be empty in a stub area)
show ip ospf neighbor                      # adjacencies across areas
show ip route ospf                         # routes the local router has installed

A working stub area shows:

• The area is listed in show ip ospf database with the stub flag set.
• The database for the area contains Type-1 and Type-2 LSAs and a single Type-3 default. No Type-5.
• show ip route ospf from a router inside the area shows the default route via the ABR.

A working NSSA shows:

• The area is listed with the NSSA flag.
• show ip ospf database nssa-external lists the Type-7 LSAs.
• show ip ospf database external (on the ABR) lists the translated Type-5 LSAs.

How it fails

The production failure modes the engineer must recognise:

• Area-type mismatch. R3 has area 10 stub, R4 has area 10 nssa. The Hello packets carry the area-type field; the two ends see the mismatch; the adjacency does not form.
• Stub area with a Type-5 source. A router inside a stub area is configured to redistribute BGP into OSPF. The router refuses: OSPF blocks Type-5 origination from a stub area. The fix is to make the area an NSSA (Type-7 is permitted) or to do the redistribution at the ABR.
• NSSA without default-information originate and no upstream. An NSSA without the default-information originate flag has no default route unless the ABR is also configured to generate one. Operators who assume the NSSA behaves like a stub are surprised.
• Area range that hides too much. An operator summarises 10.50.0.0/16 at the ABR; one of the /24s is a partner’s prefix that should remain specific for traffic-engineering. The summary hides the /24, the partner’s traffic flows through the wrong path. The fix is a more specific range exception (or no summary at all).
• Per-area authentication with a per-interface override that disagrees. A router has per-area MD5 and per-interface plaintext (probably a leftover from a migration). The per-interface setting wins; the adjacency fails for every neighbour on that interface.

Rollback

The recovery from a bad area configuration:

• Area-type change. delete protocols ospf area 10 stub (and any nssa flag) and commit; save. The area becomes standard; the ABR stops injecting the default Type-3; Type-5 LSAs may now flood in.
• Area range change. delete protocols ospf area 10 range 10.50.0.0/16 and commit; save. The ABR starts flooding individual Type-3 LSAs for each /24.
• Per-area authentication change. delete protocols ospf area 10 authentication and commit; save. The area falls back to no authentication or to per-interface authentication. The adjacency re-forms within the dead interval.

For any of these, rollback N inside configure reverts to a known-good revision.

Cross-course references

The VyOS lessons vyos-xviii-04-areas covers the area concepts this lesson builds on. The lesson vyos-xix-04-ospf-redistribute covers the redistribution primitives that an NSSA relies on. The lesson vyos-xix-05-ospf-authentication covers the authentication types used in the per-area authentication block. The lesson vyos-xix-06-ospf-cost-tuning covers the cost parameter on the area range. The Linux course’s XIX-Linux-NetFoundations covers the routing-table primitives that the per-area defaults interact with.

Quiz