OSPF Area Types

OSPF Area Types

OSPF uses a hierarchical area design to scale routing across large networks. Every OSPF domain requires a backbone area (Area 0) as the central hub, with all other areas connecting to it through area border routers (ABRs). Area types control which LSA categories are permitted inside each area, allowing administrators to trade routing detail for reduced overhead in areas where full external route visibility is unnecessary.

RouterOS 7 represents a significant configuration change from RouterOS 6. Interface participation is now configured via /routing ospf interface-template rather than the old /routing ospf interface and /routing ospf network menus.

Area Types Overview

Area Type	LSAs Permitted	External Routes	Summary Routes (inter-area)	Use Case
Backbone (Area 0)	1, 2, 3, 4, 5	Yes	Yes	Core routing domain
Standard	1, 2, 3, 4, 5	Yes	Yes	Full OSPF participation
Stub	1, 2, 3	No (default route only)	Yes	Leaf areas, single ABR exit
Totally Stubby	1, 2, 3 (default only)	No	No (default route only)	Maximum simplification
NSSA	1, 2, 3, 7	Type-7 internal, converted to Type-5 at ABR	Yes	Leaf areas needing local redistribution

Backbone Area (Area 0)

The backbone area is the mandatory hub of every OSPF domain. All other areas must connect to Area 0, either directly through physical links or through virtual links when direct connectivity is not possible. The backbone area operates as a standard area with full LSA propagation: router LSAs (Type 1), network LSAs (Type 2), summary LSAs (Type 3 and 4), and external LSAs (Type 5) all flood normally.

Routers with interfaces only in Area 0 are backbone routers. Routers spanning Area 0 and another area are area border routers and maintain separate link-state databases for each connected area.

Configuring the Backbone Area

# Create OSPF instance
/routing ospf instance
add name=ospf1 version=2 router-id=1.1.1.1

# Create backbone area
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1

# Assign interfaces to backbone via interface-template
/routing ospf interface-template
add interfaces=ether1 area=backbone
add interfaces=ether2 area=backbone cost=10

Standard Area

Standard areas accept all five LSA types and behave identically to the backbone area in terms of routing information. Use standard areas for network segments requiring full visibility of external routes and inter-area summaries. Standard areas are appropriate when routers have sufficient memory and CPU to hold external routes, and when traffic engineering across multiple exit points is needed.

/routing ospf area
add name=area1 area-id=0.0.0.1 instance=ospf1

/routing ospf interface-template
add interfaces=ether3 area=area1

Stub Area

A stub area blocks external LSAs (Type 5) from entering the area. The ABR substitutes a single default route (0.0.0.0/0) advertised as a Type 3 summary LSA. All routers in a stub area must agree on the stub designation — a router with standard configuration will fail to form an adjacency with a router configured for stub.

When to use stub areas:

• The area has a single ABR exit point (or all ABRs lead to the same upstream)
• External route details are not needed inside the area
• You want to reduce memory and CPU usage on internal routers

Limitation: Stub areas cannot contain ASBRs. If a router in the area needs to redistribute external routes into OSPF, use NSSA instead.

/routing ospf area
add name=stub-branch area-id=0.0.0.10 instance=ospf1 type=stub

/routing ospf interface-template
add interfaces=ether4 area=stub-branch

Totally Stubby Area

Totally stubby areas extend stub restrictions by also blocking Type 3 summary LSAs from other areas. The ABR generates only a single default route for all destinations — both external and inter-area. Routers inside the area see only their local routes and one default route, giving the smallest possible routing table.

Totally stubby is a Cisco-originated extension; RouterOS implements it with the no-summaries flag on the area:

/routing ospf area
add name=totally-stub area-id=0.0.0.15 instance=ospf1 type=stub no-summaries

/routing ospf interface-template
add interfaces=ether5 area=totally-stub

Only configure no-summaries on the ABR. Internal routers in the area configure it as a regular stub area — they will automatically receive only the default route because the ABR suppresses summary LSA flooding.

NSSA (Not-So-Stubby Area)

NSSA solves a specific problem: a stub-like area that still needs to redistribute external routes. A pure stub area cannot contain an ASBR, but NSSA allows external route injection using Type 7 LSAs, which travel only within the NSSA. The ABR translates Type 7 LSAs into Type 5 when advertising to the rest of the OSPF domain.

When to use NSSA:

• The area has a router performing redistribution (connected routes, BGP, static routes)
• You still want to reduce Type 5 LSA flooding from the rest of the domain
• The area has its own external connectivity (e.g., a branch office with a local internet link)

Stub vs NSSA: The Key Distinction

This is the most common source of confusion in OSPF area design:

Scenario	Use
Area has no local external routes; single exit to core	Stub
Area needs to redistribute routes (has an ASBR)	NSSA
Area has local internet breakout	NSSA
Area is purely internal with one path out	Stub

The critical rule: if any router in the area performs route redistribution into OSPF, the area must be NSSA, not stub. Configuring stub on an area with an ASBR causes an error — the router will refuse to originate external LSAs into a stub area.

Type 7 LSA Translation

Inside the NSSA, the ASBR originates Type 7 (NSSA external) LSAs. These propagate only within the NSSA — they cannot leave the area as Type 7. The ABR translates them to Type 5 external LSAs for advertisement to the backbone and other areas.

When multiple ABRs connect the NSSA to the backbone, one ABR is elected as the translator. RouterOS uses translator-role to control this:

Value	Behavior
candidate (default)	Participates in translator election; highest router-ID wins
always	Always acts as translator, regardless of election
never	Never translates Type 7 to Type 5

/routing ospf area
add name=nssa-branch area-id=0.0.0.20 instance=ospf1 type=nssa

# Force this ABR to always translate (useful when router IDs make election unpredictable)
/routing ospf area
add name=nssa-branch area-id=0.0.0.20 instance=ospf1 type=nssa translator-role=always

/routing ospf interface-template
add interfaces=ether6 area=nssa-branch

Totally NSSA

Like totally stubby areas, NSSA also supports suppressing Type 3 summary LSAs from entering the area. This is achieved with no-summaries on an NSSA area:

/routing ospf area
add name=nssa-totally area-id=0.0.0.25 instance=ospf1 type=nssa no-summaries

Interface-Template Configuration

RouterOS 7 replaces the per-interface /routing ospf interface menu with /routing ospf interface-template. A template matches interfaces either by name or by network prefix, and applies OSPF parameters to all matching interfaces.

Sub-menu: /routing ospf interface-template

Property	Description	Default
interfaces	Match by interface name(s)	—
networks	Match by network prefix	—
area	Area name this template assigns to	(required)
cost	Interface metric	auto (ref-bandwidth / link-speed)
network-type	broadcast, nbma, point-to-point, ptmp, ptmp-broadcast	broadcast
hello-interval	Hello packet interval	10s
dead-interval	Neighbor dead detection	40s
priority	DR/BDR election priority	1
passive	Advertise prefix but form no adjacencies	no
authentication	none, simple, md5	none

# Match by interface name
/routing ospf interface-template
add interfaces=ether1 area=backbone

# Match by network prefix (all interfaces with addresses in this range)
/routing ospf interface-template
add networks=10.0.0.0/8 area=area1

# Point-to-point link (no DR/BDR election, faster convergence)
/routing ospf interface-template
add interfaces=sfp1 area=backbone network-type=point-to-point

# Passive interface: advertise the prefix but don't form OSPF neighbors
/routing ospf interface-template
add interfaces=lo0 area=backbone passive=yes

# Custom timers for faster failover detection (must match on both ends)
/routing ospf interface-template
add interfaces=ether2 area=backbone hello-interval=3s dead-interval=12s

# Manual cost (overrides auto-calculation)
/routing ospf interface-template
add interfaces=ether3 area=backbone cost=50

Area Border Router Configuration

An ABR is any router with interfaces in two or more OSPF areas, including the backbone. The ABR maintains a separate link-state database for each area and generates Type 3 summary LSAs to advertise routes between areas.

There is no explicit “ABR” configuration — RouterOS automatically assigns the ABR role when a router’s interface-templates span multiple areas.

# This router is an ABR: it has interfaces in backbone AND area1
/routing ospf interface-template
add interfaces=ether1 area=backbone          # backbone-facing link
add interfaces=ether2 area=area1             # area1-facing link

Inter-Area Route Summarization

ABRs summarize routes from one area before advertising them into another. Without summarization, every prefix in an area appears as a separate Type 3 LSA in the backbone. Summarization aggregates multiple prefixes into a single advertisement, reducing LSDB size and dampening the effect of topology changes.

Sub-menu: /routing ospf area range

# Summarize 10.1.0.0/16 from area1 when advertising into backbone
/routing ospf area range
add area=area1 range=10.1.0.0/16 advertise=yes

# Suppress (do not advertise) a specific range
/routing ospf area range
add area=area1 range=10.1.99.0/24 advertise=no

# Summarize NSSA external routes
/routing ospf area range
add area=nssa-branch range=192.168.100.0/22 advertise=yes

Summarization requires careful address planning. Gaps in the summarized range create black holes if no more-specific routes exist. Always verify that all prefixes within a summary are either reachable or excluded.

Multi-Router Example

This example builds a three-area OSPF network using two routers:

• staging-router-01 — ABR connecting backbone (Area 0) and stub branch (Area 1)
• staging-router-02 — ABR connecting backbone (Area 0) and NSSA (Area 2), also performs redistribution of connected routes into Area 2

                    Area 0 (Backbone)
   staging-router-01 ─────────────── staging-router-02
        │  10.0.0.1                  10.0.0.2  │
        │                                       │
   Area 1 (Stub)                       Area 2 (NSSA)
   10.1.0.0/24                         10.2.0.0/24
   (branch, no ASBR)                   (with local redistribution)

staging-router-01

# OSPF instance
/routing ospf instance
add name=ospf1 version=2 router-id=1.1.1.1

# Areas
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1
add name=area1-stub area-id=0.0.0.1 instance=ospf1 type=stub

# Interfaces
# ether1: backbone link to staging-router-02 (10.0.0.0/30)
# ether2: stub area link (10.1.0.0/24)
/routing ospf interface-template
add interfaces=ether1 area=backbone network-type=point-to-point
add interfaces=ether2 area=area1-stub

# Summarize area1 prefixes when advertising to backbone
/routing ospf area range
add area=area1-stub range=10.1.0.0/16 advertise=yes

staging-router-02

# OSPF instance
/routing ospf instance
add name=ospf1 version=2 router-id=2.2.2.2

# Areas
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=ospf1
add name=area2-nssa area-id=0.0.0.2 instance=ospf1 type=nssa

# Interfaces
# ether1: backbone link to staging-router-01 (10.0.0.0/30)
# ether2: NSSA link (10.2.0.0/24)
# ether3: external uplink (redistributed as external routes in NSSA)
/routing ospf interface-template
add interfaces=ether1 area=backbone network-type=point-to-point
add interfaces=ether2 area=area2-nssa
add interfaces=ether3 area=area2-nssa passive=yes

# Redistribute connected routes (this router acts as ASBR in the NSSA)
/routing ospf instance
set ospf1 redistribute-connected=yes

# Summarize area2 prefixes
/routing ospf area range
add area=area2-nssa range=10.2.0.0/16 advertise=yes

Verifying the Multi-Area Setup

# On either router: verify areas
/routing ospf area print

# Confirm neighbors are in FULL state
/routing ospf neighbor print

# Check that stub area has only a default route for external destinations
# (run on a router inside area1-stub)
/ip route print where ospf~"."

# Check LSA database — stub area should have no Type-5 LSAs
/routing ospf lsa print where area=area1-stub
/routing ospf lsa print where area=area1-stub and type=external
# ^^^ should return nothing

# In NSSA, Type-7 LSAs should be present
/routing ospf lsa print where area=area2-nssa and type=nssa-external

# On staging-router-02: verify Type-7 to Type-5 translation
/routing ospf lsa print where type=external

Common Issues and Troubleshooting

Adjacency Fails Across Area Boundary

Neighbors in different areas cannot form adjacencies directly — OSPF adjacencies are always between routers in the same area (or via virtual links for backbone connectivity). If two routers on the same link are configured for different areas, they will not form a neighbor relationship.

# Verify both sides of a link use the same area
/routing ospf interface-template print detail

Stub Area: Neighbor Stuck at Init

If one router configures an interface as stub and the other does not, their hello packets will not match on the stub/external-routing-capable flag. The adjacency will not advance beyond Init.

# Verify area type matches on both ends
/routing ospf area print

NSSA: External Routes Not Appearing in Backbone

Type 7 LSAs do not leave the NSSA. They must be translated to Type 5 by the elected translator ABR. If translation is not happening:

1. Verify the ABR has the area configured as NSSA on both its area-facing and backbone-facing instances.
2. Check translator election with /routing ospf lsa print — look for translator flag in NSSA external LSAs.
3. Force a specific ABR to translate by setting translator-role=always.

# Check NSSA LSA translation status on ABR
/routing ospf lsa print where type=nssa-external
/routing ospf area print detail

Route Summarization Not Working

Area ranges only take effect on ABRs. If a summarization command exists on an internal router (not an ABR), it has no effect.

# Confirm this router is acting as ABR (has interfaces in multiple areas)
/routing ospf interface-template print
/routing ospf area print

# Verify the range covers the actual prefixes being advertised
/routing ospf area range print

Related Documentation

• OSPF — OSPF fundamentals, LSA types, neighbor states, authentication, and monitoring
• BGP — Border Gateway Protocol for inter-domain routing
• Route Filters — Controlling route redistribution into OSPF
• BFD — Bidirectional Forwarding Detection for fast failure detection on OSPF links