A network built from zero, not a network already broken — Router ID and interface addressing, bringing up OSPF in a single Area 0, then growing into a backbone plus a stub area with an ABR as the network expands, DR priority on shared segments, and the verification commands that confirm each stage before you add the next.
By the AtlasCommTech engineering team — 13 years of carrier & enterprise network deployments · Updated July 2026
Most OSPF content assumes OSPF is already running and something's wrong with it. This note assumes neither — a routed core that doesn't exist yet, planned and built area by area.
An OSPF deployment usually doesn't start life as one flat area either. It starts as one router, then two, then a redundant path between two buildings, then a branch office that shouldn't see every route from headquarters. Configuring OSPF correctly at each of these stages — not just getting a neighbor relationship to come up once and hoping it holds — is a different problem from troubleshooting one that already exists.
This note starts with the smallest working OSPF network: two routers, one area, sharing routes. Then it grows the same design into two areas — a backbone Area 0 and a stub Area 1 at the network edge, the point where most enterprise OSPF designs actually need to go. If a neighbor relationship refuses to come up in your own network, our OSPF neighbor state-machine troubleshooting note covers that separately; if the two ends are from different vendors, see our Huawei-Cisco OSPF interop note for the DR/BDR and timer pitfalls specific to that pairing.
Get a single Area 0 solid on its own first — then extend a stub area off the one router that touches both.
Diagram labels are kept in English for engineering clarity.
Stage 1 Addressing — Single Area 0
| Router / Interface | IP Address | OSPF Area |
|---|---|---|
| RouterA — Vlanif10 | 192.168.1.1/24 | Area 0.0.0.0 |
| RouterA — GigabitEthernet3/0/0 | 192.168.0.1/24 | Area 0.0.0.0 |
| RouterA — LoopBack0 (Router ID) | 1.1.1.1/32 | Router ID only |
| RouterB — Vlanif20 | 192.168.2.1/24 | Area 0.0.0.0 |
| RouterB — GigabitEthernet3/0/0 | 192.168.0.2/24 | Area 0.0.0.0 |
| RouterB — LoopBack0 (Router ID) | 2.2.2.2/32 | Router ID only |
Stage 2 Addressing — Adding Area 1 as a Stub Area
| Router / Interface | IP Address | OSPF Area |
|---|---|---|
| RouterA — GigabitEthernet1/0/0 | 192.168.2.1/24 | Not in OSPF — imported via import-route direct |
| RouterA — GigabitEthernet2/0/0 | 192.168.0.1/24 | Area 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet2/0/0 | 192.168.0.2/24 | Area 0.0.0.0 |
| RouterB (ABR) — GigabitEthernet1/0/0 | 192.168.1.2/24 | Area 0.0.0.1 — stub |
| RouterC — GigabitEthernet1/0/0 | 192.168.1.1/24 | Area 0.0.0.1 — stub |
Six moves: Router ID and addressing, a working single area, deciding the ABR, adding the stub area, matching the stub attribute everywhere it's needed, and DR priority on shared segments.
#
sysname RouterA
#
router id 1.1.1.1
#
vlan batch 10
#
interface Vlanif10
ip address 192.168.1.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 10
#
interface GigabitEthernet3/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.1.0 0.0.0.255
network 192.168.0.0 0.0.0.255
##
sysname RouterB
#
router id 2.2.2.2
#
vlan batch 20
#
interface Vlanif20
ip address 192.168.2.1 255.255.255.0
#
interface Ethernet2/0/0
port link-type trunk
port trunk allow-pass vlan 20
#
interface GigabitEthernet3/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.2.0 0.0.0.255
network 192.168.0.0 0.0.0.255
#A different, larger network illustrates the next stage: RouterB becomes the ABR between Area 0 and a new Area 1, and Area 1 is marked stub so RouterC only ever needs a default route to reach everything behind the backbone.
#
sysname RouterA
#
router id 1.1.1.1
#
interface GigabitEthernet1/0/0
ip address 192.168.2.1 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.1 255.255.255.0
#
interface LoopBack0
ip address 1.1.1.1 255.255.255.255
#
ospf 2
import-route direct
area 0.0.0.0
network 192.168.0.0 0.0.0.255
##
sysname RouterB
#
router id 2.2.2.2
#
interface GigabitEthernet1/0/0
ip address 192.168.1.2 255.255.255.0
#
interface GigabitEthernet2/0/0
ip address 192.168.0.2 255.255.255.0
#
interface LoopBack0
ip address 2.2.2.2 255.255.255.255
#
ospf 2
area 0.0.0.0
network 192.168.0.0 0.0.0.255
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
##
sysname RouterC
#
router id 3.3.3.3
#
interface GigabitEthernet1/0/0
ip address 192.168.1.1 255.255.255.0
#
interface LoopBack0
ip address 3.3.3.3 255.255.255.255
#
ospf 2
area 0.0.0.1
network 192.168.1.0 0.0.0.255
stub
#RouterA's GigabitEthernet1/0/0 LAN is deliberately left out of the OSPF network statement and imported instead with import-route direct — a common pattern for a locally attached segment that doesn't need its own OSPF adjacency.
Full state on the single-area pair first, then Full state on both sides of the ABR, then a routing table on the stub-area router that's noticeably shorter than the backbone's.
<RouterA> display ospf peer brief
OSPF Process 2 with Router ID 1.1.1.1
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet3/0/0 2.2.2.2 Full
----------------------------------------------------------------------------
Total Peer(s): 1<RouterB> display ospf peer brief
OSPF Process 2 with Router ID 2.2.2.2
Peer Statistic Information
----------------------------------------------------------------------------
Area Id Interface Neighbor id State
0.0.0.0 GigabitEthernet2/0/0 1.1.1.1 Full
0.0.0.1 GigabitEthernet1/0/0 3.3.3.3 Full
----------------------------------------------------------------------------
Total Peer(s): 2<RouterC> display ip routing-table
Destinations : 2 Routes : 2
Destination/Mask Proto Pre Cost NextHop Interface
0.0.0.0/0 O_ASE 150 1 192.168.1.2 GigabitEthernet1/0/0
192.168.1.0/24 Direct 0 0 192.168.1.1 GigabitEthernet1/0/0RouterC's routing table stays short on purpose — that's the entire point of marking Area 1 stub; it never receives the individual external or inter-area routes an ordinary area would carry.
The ones that turn a working single area into a multi-area design that only half works.
SYMPTOMOn a shared Ethernet or VLANIF segment with three or more OSPF routers, the DR turns out to be the router you least wanted — often just whichever one's interface came up first.
CAUSEEvery OSPF-enabled interface starts with DR priority 1 by default. When priorities tie, the router with the highest Router ID wins — which has nothing to do with which router actually has the best hardware or placement to be DR.
FIXSet ospf dr-priority explicitly on each interface in the segment — a higher value on the router you want as DR, priority 0 on any router that should never become DR or BDR at all.
SYMPTOMA router at the edge of what's supposed to be a stub area either won't form an adjacency at all, or the area doesn't behave as stub — full external routes still show up somewhere inside it.
CAUSEThe stub attribute is negotiated in the Hello packet's option flags. If the ABR is configured stub but one router inside that area isn't (or vice versa), the mismatch alone is enough to block the adjacency — it isn't a setting one router can carry alone for the whole area.
FIXConfigure the stub keyword under that area on every single router inside it, ABR included. The same rule applies to NSSA — it's a matching, not optional, per-router requirement for every router sharing that area.
SYMPTOMAn interface that should clearly belong to an OSPF area never brings up a neighbor, or an interface that shouldn't be running OSPF at all somehow gets advertised.
CAUSEThe network command under an OSPF area uses a wildcard mask, not a subnet mask — network 192.168.0.0 0.0.0.255 matches the 192.168.0.0/24 range, but a typo here (an extra or missing bit) silently changes which interfaces get pulled into the area.
FIXDouble-check the wildcard math against the actual interface address, and confirm with display ospf interface which interfaces the process actually picked up — don't just trust the configuration as typed.
SYMPTOMA newly added router won't form an adjacency with anyone on an existing OSPF network, despite reachable interfaces and configuration that looks correct on both sides.
CAUSEIf the new router's Router ID collides with one already active elsewhere in the OSPF domain — easy to happen with auto-selected Router IDs or copy-pasted configurations — the domain sees a conflict rather than a usable second router.
FIXAssign Router ID explicitly with router id under the OSPF process, tied to a stable LoopBack0 address — never leave it to auto-selection from a physical interface address that might change or already be in use elsewhere.
This note is based on two worked configurations: a two-router single-Area-0 network, and a three-router design with an ABR and a stub Area 1. It doesn't walk through NSSA in full (a close variant, briefly described above), OSPF virtual links across a transit area, route aggregation at the ABR, or OSPF authentication — all reasonable next steps once the basic multi-area design is in place. It also doesn't cover what happens when adjacent routers are from different vendors — see our Huawei-Cisco OSPF interop note for that, or our OSPF neighbor troubleshooting note if an adjacency in your own network refuses to come up.
Pulled from the same configuration cases this note is built on.
Start flat. A single Area 0 is the right design until the network actually grows past what one area comfortably handles — extra areas add ABR planning and stub/NSSA decisions you don't need yet. Add Area 1 (or more) when there's a genuine boundary to draw: a branch office, a data-center block, or a link where you want to hide detailed routing information rather than pass all of it through.
The ABR is simply whichever router physically touches both Area 0 and the new area — it's a topology fact more than a choice. What is a choice is what you configure on it: whether the area behind it stays a plain area, becomes a stub area, or becomes an NSSA, based on whether that area needs to originate its own external routes.
That's the entire purpose of a stub area — the ABR replaces every external (Type 5) LSA it would otherwise flood into that area with a single default route, cutting down the routing table and the LSA flooding a small edge router has to carry. If that edge router also needs to originate its own external routes into the area, NSSA is the variant built for that.
That note assumes an OSPF network already exists and a neighbor relationship is stuck or flapping — it reads the neighbor state machine to find out why. This note assumes nothing exists yet: it's the configuration that gets you to a working neighbor relationship and a working multi-area design in the first place.
No — DR/BDR election is a broadcast (multi-access) network concept. Point-to-point-type interfaces have no DR to elect at all, so dr-priority has nothing to act on there; it only matters on Ethernet/VLANIF-type broadcast segments with more than one OSPF router attached.
The area, network and stub logic here is vendor-neutral OSPF behavior, but default timers, DR eligibility on certain interface types, and cost calculation can differ enough between vendors to keep a design that works within one vendor from working across vendors. See our Huawei-Cisco OSPF interop note for the specific defaults that don't match out of the box.
Tell us how many sites, how many routers, and where you expect the area boundaries to fall, and we'll help you plan the area design and ABR placement.