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?

NOCTIS designs scalable multi-area routing on MikroTik and Cisco across Crete — sane area boundaries, stub/summary design, and tables that stay small as the network grows.

Book a Discovery Call →