How to Configure Multi-Area OSPF on Cisco (Step by Step)

Step 1 — Design the areas and pick your ABR (before you type anything)

Multi-area OSPF is a design decision first and a config task second. Two rules drive the whole layout. First, area 0 (the backbone) must be contiguous — you cannot split it in two. Second, every non-backbone area must physically touch area 0 through at least one ABR. An ABR is simply a router with interfaces in two or more areas, one of which is area 0. It is the ABR that generates the inter-area (Type 3) summary LSAs that let one area learn another area's routes without seeing its full topology.

We will use three routers. R1 is an internal router in area 0. R2 is the ABR: one interface in area 0 (toward R1) and one interface in area 1 (toward R3). R3 is an internal router in area 1. Each edge router also has a LAN we want reachable end to end.

Addressing plan: R1 G0/0 = 10.0.12.1/24 (link to R2, area 0); R1 G0/1 = 10.0.1.1/24 (LAN A, area 0). R2 G0/0 = 10.0.12.2/24 (area 0); R2 G0/1 = 10.1.23.2/24 (link to R3, area 1). R3 G0/0 = 10.1.23.3/24 (area 1); R3 G0/1 = 10.1.1.1/24 (LAN B, area 1). Notice the intent baked into the numbering: everything in area 0 starts 10.0.x, everything in area 1 starts 10.1.x. Clean area boundaries in your addressing make the ABR easy to summarize later and make mistakes obvious.

Step 2 — Start the OSPF process and set a router ID

Enable the OSPF process on each router and pin the router ID. The process ID after 'router ospf' (here, 1) is locally significant — it does NOT have to match between neighbors, and it has nothing to do with the area or the AS. Neighbors on R1 and R2 will form even if one runs 'router ospf 1' and the other 'router ospf 99'. Keep it the same across your routers only for your own sanity.

Always set the router ID explicitly. If you don't, IOS picks it automatically — highest active loopback IP, or if there is no loopback, the highest active interface IP — at process start. That auto-selection can change on reboot or an interface flap and quietly reshuffle your DR elections and LSAs. A hardcoded router ID (we use 1.1.1.1 / 2.2.2.2 / 3.3.3.3 to match the router numbers) makes every 'show' output readable. Note: if OSPF is already running, a new 'router-id' does not take effect until you reset the process with 'clear ip ospf process'.

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

R2(config)# router ospf 1
R2(config-router)# router-id 2.2.2.2

R3(config)# router ospf 1
R3(config-router)# router-id 3.3.3.3

! If OSPF was already up before you set the router-id:
R2# clear ip ospf process
Reset ALL OSPF processes? [no]: yes

Step 3 — Place the internal routers' interfaces into their areas

The 'network' statement does two jobs at once: it decides which interfaces run OSPF, and it assigns each of those interfaces to an area. The mask after the network is a WILDCARD mask, not a subnet mask — a 0 bit means 'must match', a 1 bit means 'don't care'. So 'network 10.0.1.0 0.0.0.255 area 0' matches any interface whose address falls in 10.0.1.0/24 and drops it into area 0. Match your wildcards to your real subnets; a wildcard that is too broad will scoop unintended interfaces into an area (a classic cause of the 'wrong area' bug in the last section).

Configure the two internal routers first. R1 has both interfaces in area 0; R3 has both in area 1. There is nothing special about an internal router — every one of its OSPF interfaces sits in exactly one area.

If you prefer, IOS also lets you assign the area directly on the interface with 'ip ospf <process> area <area>'. This is often clearer than reverse-engineering wildcard masks, and the two methods interoperate freely across routers. The interface-based equivalent for R3 is shown below the network-statement version.

! Internal router R1 — everything in area 0
R1(config)# router ospf 1
R1(config-router)# network 10.0.12.0 0.0.0.255 area 0
R1(config-router)# network 10.0.1.0 0.0.0.255 area 0

! Internal router R3 — everything in area 1
R3(config)# router ospf 1
R3(config-router)# network 10.1.23.0 0.0.0.255 area 1
R3(config-router)# network 10.1.1.0 0.0.0.255 area 1

! Equivalent, using the interface method on R3:
R3(config)# interface g0/0
R3(config-if)# ip ospf 1 area 1
R3(config-if)# interface g0/1
R3(config-if)# ip ospf 1 area 1

Step 4 — Configure the ABR that joins area 1 to the backbone

R2 is where multi-area actually happens. It has one interface in area 0 (G0/0 toward R1) and one in area 1 (G0/1 toward R3). Assigning each interface to its own area is the entire trick — the moment a router has an interface in area 0 and an interface in another area, IOS treats it as an ABR and it begins its boundary job automatically.

As an ABR, R2 keeps a SEPARATE link-state database for each attached area and does not leak one area's Type 1/Type 2 LSAs into the other. Instead, for every intra-area prefix it learns in area 1, it originates a Type 3 (inter-area summary) LSA into area 0, and vice versa. That is why R1 will learn about LAN B without ever seeing area 1's internal topology — it just receives R2's summary. This is the flooding-containment payoff of multi-area design.

No extra 'make me an ABR' command exists or is needed. Just place the interfaces correctly.

! ABR R2 — one interface in area 0, one in area 1
R2(config)# router ospf 1
R2(config-router)# network 10.0.12.0 0.0.0.255 area 0
R2(config-router)# network 10.1.23.0 0.0.0.255 area 1

Step 5 — Verify the areas, the ABR flag, and adjacencies

Confirm three things: R2 really is an ABR, each interface landed in the area you intended, and neighbors reached FULL.

'show ip ospf' reports the area count and, on R2, the line 'It is an area border router'. If you expected an ABR and don't see that line, an interface is in the wrong area (or missing from OSPF entirely). 'show ip ospf interface brief' is the fastest sanity check for area placement — the Area column must read 0 on R2's link to R1 and 1 on its link to R3. 'show ip ospf neighbor' must show FULL for every intended adjacency; anything stuck in INIT, 2-WAY (on a link where you expected full adjacency), EXSTART, or EXCHANGE points at a mismatch covered in the last section. The DR/BDR roles below fall out of the router IDs: 2.2.2.2 wins DR over 1.1.1.1 on the first link, and 3.3.3.3 wins DR over 2.2.2.2 on the second.

R2# show ip ospf
 Routing Process "ospf 1" with ID 2.2.2.2
 ...
 It is an area border router
 Number of areas in this router is 2. 2 normal 0 stub 0 nssa

R2# show ip ospf interface brief
Interface  PID  Area  IP Address/Mask   Cost  State  Nbrs F/C
Gi0/0      1    0     10.0.12.2/24      1     DR     1/1
Gi0/1      1    1     10.1.23.2/24      1     BDR    1/1

R2# show ip ospf neighbor
Neighbor ID  Pri  State     Dead Time  Address     Interface
1.1.1.1      1    FULL/BDR  00:00:33   10.0.12.1   GigabitEthernet0/0
3.3.3.3      1    FULL/DR   00:00:31   10.1.23.3   GigabitEthernet0/1

Step 6 — Confirm inter-area routes (O vs O IA)

The proof that multi-area works is in the routing table. On R1 (area 0), the prefixes that live in area 1 must appear with the code 'O IA' — OSPF Inter-Area — because R1 learned them from R2's Type 3 summary, not from area 1's own LSAs. A plain 'O' means an intra-area route (same area, learned from Type 1/2 LSAs). If area 1 prefixes show up as 'O' instead of 'O IA' on R1, your area boundary isn't where you think it is.

On R1, both LAN B (10.1.1.0/24) and the R2–R3 link (10.1.23.0/24) show as O IA via R2. The metric is cumulative: cost to the ABR plus the cost the ABR advertised in its Type 3 LSA. Exact numbers depend on interface bandwidth and any 'auto-cost reference-bandwidth' setting, so treat the values below as illustrative. To see the summaries themselves, 'show ip ospf database summary' lists the Type 3 LSAs the ABR injected.

R1# show ip route ospf
      10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
O IA     10.1.1.0/24 [110/3] via 10.0.12.2, 00:05:12, GigabitEthernet0/0
O IA     10.1.23.0/24 [110/2] via 10.0.12.2, 00:05:12, GigabitEthernet0/0

! O IA = inter-area (from the ABR's Type 3 summary)
! plain O = intra-area (same area)

R1# show ip ospf database summary
            Summary Net Link States (Area 0)
 Link ID         ADV Router      Age  Seq#       Checksum
 10.1.1.0        2.2.2.2         210  0x80000001 0x00A1B2
 10.1.23.0       2.2.2.2         210  0x80000001 0x00C3D4

Common problems (and the fix)

1) A non-backbone area doesn't touch area 0. This is the cardinal sin of OSPF design: an area whose only path to the backbone runs through another non-backbone area. Its routes never reach the backbone and its ABR can't function. The correct fix is almost always physical/logical redesign — give the area a real link (or a second ABR) into area 0. When you genuinely can't, OSPF's escape hatch is a virtual link: a logical tunnel across a NON-stub transit area that extends the backbone to the stranded ABR. Configure it on both ABRs, referencing each other's router ID and the transit area's ID (the transit area, not area 0). Verify with 'show ip ospf virtual-links'. Treat it as a temporary bridge, not a design.

2) The two ends of a link are configured in different areas. OSPF carries the Area ID in the hello, and both ends of a segment must agree — a mismatch means the hello is rejected and the adjacency never forms (empty 'show ip ospf neighbor', plus an OSPF-4-ERRRCV log about a mismatched area ID). This usually comes from an over-broad wildcard or a fat-fingered 'area' keyword. Fix: put both interfaces on the segment in the SAME area. Confirm with 'show ip ospf interface brief' on both routers.

3) A subnet/mask mismatch on the link. On broadcast networks OSPF also requires both interfaces to share the same subnet and mask; if they don't, hellos are dropped and no neighbor forms. A close cousin is an MTU mismatch: the neighbor gets stuck in EXSTART/EXCHANGE because OSPF checks MTU during database exchange. Fix the addressing/mask so both ends match, and align the interface MTU (or, only if you understand the tradeoff, apply 'ip ospf mtu-ignore' on both ends).

4) An interface landed in the wrong area. Symptoms: a route you expected as 'O' shows up as 'O IA', a router unexpectedly reports 'It is an area border router', or traffic takes a surprising path. The usual cause is a 'network' statement whose wildcard mask is broader than the subnet, sweeping an extra interface into the wrong area. Fix: run 'show ip ospf interface brief', find the interface under the unexpected Area, and correct it — tighten the wildcard, move the 'network ... area' line, or set the area on the interface directly with 'ip ospf <process> area <area>'.

! Fix #1 — virtual link across transit area 1 (R2 is on area 0; R3 is the stranded ABR)
R2(config)# router ospf 1
R2(config-router)# area 1 virtual-link 3.3.3.3

R3(config)# router ospf 1
R3(config-router)# area 1 virtual-link 2.2.2.2

R2# show ip ospf virtual-links
Virtual Link OSPF_VL0 to router 3.3.3.3 is up

! Fix #2 — put both ends of the link in the SAME area
R3(config)# interface g0/0
R3(config-if)# ip ospf 1 area 1     ! must match R2 Gi0/1's area

! Fix #4 — see which area each interface really joined, then correct it
R3# show ip ospf interface brief
R3(config)# interface g0/1
R3(config-if)# ip ospf 1 area 1     ! move it out of the wrong area