Build the idea first, then use the next activity to check it.
Why OSPF has areas
What splitting a domain buys you, what an area border router does, and the two mismatches that stop an adjacency dead.
What you will be able to do
- Explain what problem areas solve, and what they cost
- Describe what an area border router holds and what it passes on
- Diagnose an adjacency stuck in ExStart or rejected outright
- Say why every area must touch area 0
Before this: You need the three-stage sequence from "How OSPF builds a routing table" - neighbour, database, calculation.
Why it matters: Multi-area design is where OSPF stops being a protocol you enable and starts being one you plan. It is also where two of the most confusing faults live, both of which look like a cabling problem and are not.
Every router in an area holds an identical database and recalculates the whole thing whenever any part of it changes. That is what makes OSPF converge quickly and correctly, and it is also what stops it scaling for free. A flapping link on the far side of a large domain makes every router in it run the calculation again.
Areas are the boundary that stops the flooding. Inside an area, full topology detail. Between areas, only summaries of what is reachable. The cost of that is that no router outside an area can see its internal shape, which is exactly the point.
The backbone, and the rule about it
Area 0 is the backbone, and every other area must be directly attached to it. Not "eventually connected" - directly attached, through at least one router that sits in both. Traffic between two non-backbone areas always transits area 0, even when the two areas are physically adjacent.
The router in two areas at once
A router with interfaces in two areas is an area border router. It holds a separate database for each area it belongs to, and it does not merge them. What crosses is a summary - the prefixes reachable in one area, advertised into the other with a cost, and none of the topology behind them.
| Type | Where it sits | What it does |
|---|---|---|
| Internal router | One area only | Holds that area's database, nothing else |
| Area border router | Two or more areas, one of them area 0 | Summarises between them |
| Backbone router | Has an interface in area 0 | May also be internal or a border router |
| Autonomous system boundary router | Edge of the OSPF domain | Injects routes learned elsewhere |
Configuring it
router ospf 1
router-id 10.30.0.5
network 10.30.0.0 0.0.0.3 area 0
network 10.30.50.0 0.0.0.255 area 1
There is no separate command that declares a router to be a border router. It becomes one by having network statements naming two different areas, which is worth knowing because it also means a typo in an area number silently creates one.
The two mismatches
Both of these present as "the link is up and the neighbours will not form", and they are distinguishable by one command.
Area mismatch
Two routers on the same link that disagree about which area the link is in will not become neighbours at all. Hellos carry the area, each side discards the other's, and the neighbour table stays empty. Nothing appears in a routing table and nothing obviously complains.
A new link into the showroom
brings up the showroom link and puts the showroom end in area 1, matching the site's other interfaces. The head office end is still in area 0 from the template it was copied from. Both interfaces are up, both are running OSPF, and neither router lists the other as a neighbour. The area numbers on the two ends of one link have to agree, whatever areas the rest of each router is in.
MTU mismatch
This one is stranger, because the adjacency starts to form and then stops. During database exchange the routers compare MTU, and a disagreement leaves them in ExStart, retransmitting forever. The neighbour appears in the table, which makes it look healthier than it is.
show ip ospf neighbor
# Nothing listed at all -> suspect area, subnet or interval mismatch
# Listed, stuck in ExStart -> suspect MTU
show interfaces
# Find the link's Cisco interface name and compare its MTU on both ends
When to split
Areas add planning, a backbone dependency and a class of fault that does not exist in a single-area design. They are worth it when the database is large enough that recalculation or flooding is a real cost, or when one part of the network changes often enough to disturb the rest. Below that, a single area is simpler and no slower.
Terminology
- Area
- A group of OSPF routers sharing one link-state database. Flooding stops at its boundary.
- Backbone
- Area 0. Every other area must attach directly to it.
- Area border router
- A router with interfaces in more than one area, which summarises between them.
- ExStart
- The adjacency state during initial database exchange. Getting stuck here indicates an MTU mismatch.
Key takeaways
- Areas bound the flooding and recalculation that a single database imposes.
- Every area must attach directly to area 0; inter-area traffic transits the backbone.
- An area border router keeps one database per area and passes summaries between them.
- Disagreeing area numbers on one link means no adjacency forms at all.
- An adjacency stuck in ExStart is an MTU mismatch until proven otherwise.
- A router becomes a border router by configuration accident as easily as by design.
Ready to keep going?
Create a free account to save your progress and take the knowledge check.