Back to blog

MikroTik / Lab  ·  RouterOS 7  ·  July 2026

MikroTik Lab
Multi-Area OSPF

Single-area OSPF is a tutorial; multi-area is what real networks run. This lab builds five RouterOS 7 routers across three areas — a backbone, a stub, and a regular area — so you see ABRs, the LSA types that actually matter, and how RouterOS 7's instance/area/interface-template model expresses it. The twin of the Cisco multi-area OSPF lab.

MikroTik RouterOS OSPF Multi-Area Lab ABR

Area 1 (stub) Area 0 (backbone) Area 2 R5 R1ABR R2 R3 R4ABR R6 R1 and R4 are ABRs — they sit in two areas and translate between them. Everything transits Area 0.

Areas exist to bound flooding and shrink tables. In a single area, every topology change re-floods every router; split the network into areas joined by a backbone (Area 0) and a change in one area barely ripples into the others. The routers straddling two areas are ABRs — they hold a full topology of each area they touch and advertise summaries (not full detail) between them. A stub area goes further: it refuses external routes and lives off a default from its ABR, shrinking its tables to almost nothing.

RouterOS 7 expresses all this with three objects: an instance, one or more areas bound to it, and interface-templates that place interfaces into areas. This lab wires R1 and R4 as ABRs, makes Area 1 a stub, and proves the LSA types by inspection. It's the RouterOS twin of the Cisco multi-area lab; the theory is shared, the config is v7.

Prerequisites

01

The ABR — Feet in Two Areas

R1 is the border between Area 1 and the backbone. One instance, two areas, and interface-templates that assign each interface to the right area — that assignment is what makes a router an ABR.

RouterOS 7 (R1 · ABR) — backbone + stub area 1
/routing ospf instance add name=v7 router-id=1.1.1.1
/routing ospf area
add name=backbone area-id=0.0.0.0 instance=v7
add name=area1 area-id=0.0.0.1 instance=v7 type=stub   # stub!

# ether1 faces R5 (Area 1); ether2 faces the backbone (Area 0).
/routing ospf interface-template
add interfaces=ether1 area=area1 cost=10
add interfaces=ether2 area=backbone cost=10
# Holding interfaces in two different areas = this router is an ABR.
⚠ Gotcha — Every Area Must Touch the Backbone

OSPF's cardinal rule: non-backbone areas connect to each other only through Area 0. If Area 2 can't reach Area 0 directly, its routes never propagate — and RouterOS won't warn you, you'll just see missing routes. Here R1 and R4 both border the backbone, so it holds together. If a physical layout can't give an area a direct backbone link, you need a virtual-link across a transit area (supported in v7, but a design smell — fix the topology if you can). Confirm Area 0 is contiguous before blaming anything else.

02

The Stub Router — Small Tables by Design

R5 lives entirely in the stub Area 1. It gets a default route from its ABR instead of external detail, so its table stays tiny. The stub type must match on every router in the area.

RouterOS 7 (R5 · internal, Area 1 stub)
/routing ospf instance add name=v7 router-id=5.5.5.5
/routing ospf area add name=area1 area-id=0.0.0.1 instance=v7 type=stub
/routing ospf interface-template add interfaces=ether1 area=area1 cost=10
# R5 learns inter-area (type-3) summaries + a default from R1, but NO
# external (type-5) routes — that's the whole point of a stub.
[R5] > /ip route print where ospf   # note the 0.0.0.0/0 default, few specifics

03

Read the LSAs — Prove the Design Safe to Run

The whole reason to learn areas is what the LSA database shows. Inspect it and you can see intra-area (type-1/2), inter-area summaries (type-3), and the absence of type-5 in the stub.

RouterOS 7 — the LSA walk
[R1] > /routing ospf lsa print
 type=router  area=backbone   ...   # type-1: routers in the area
 type=network area=backbone   ...   # type-2: multi-access segments
 type=summary area=area1      ...   # type-3: inter-area, injected by the ABR
[R1] > /routing ospf neighbor print   # adjacencies Full in both areas
[R5] > /routing ospf lsa print where type~"external"  # EMPTY in a stub
SymptomWhere to look
Neighbours stuck in Exchange/LoadingMTU mismatch on the link — a classic OSPF killer. Match MTU both ends.
Stub area won't form adjacencyStub flag not set on every router in the area (must match).
Area 2 routes missing everywhereArea 0 not contiguous / an ABR not actually in the backbone.
Suboptimal inter-area pathCosts — tune interface-template cost to steer.

Takeaways

  1. Areas bound flooding and shrink tables — a change in one area barely touches the others. That's why real networks are multi-area.
  2. An ABR is just a router with interfaces in two areas — in v7, interface-templates placing interfaces into different areas make it one.
  3. Every area must touch Area 0 — non-backbone areas connect only through the backbone, or routes vanish silently.
  4. Stub areas refuse externals and live off a default — the type must match on every router in the area or adjacencies fail.
  5. The LSA database proves the design — type-1/2 intra-area, type-3 inter-area summaries, no type-5 in a stub.
  6. MTU mismatch is the classic adjacency killer — Exchange/Loading limbo means check MTU first.

An OSPF network that re-floods the world on every little change?

I design multi-area OSPF on MikroTik and Cisco with area boundaries that make sense, proper stub and summary design, and routing tables that stay small as the network grows instead of ballooning with every new site.

Book a Discovery Call →