Area design is usually taught as a set of numbers — how many routers in an area, how many areas on a boundary router — and those numbers came from hardware that has not been sold for a long time. They are not the constraint any more, and treating them as one produces designs that are carefully partitioned and scale no better than a single area would have.
The actual constraint is how often the shortest path computation runs and how long it takes, plus the memory the database occupies. An area boundary helps because it confines the events that trigger a full computation. It does not confine the events that trigger the partial one, and it does not confine anything at all unless the boundary summarises.
This article covers what genuinely limits the scale, what an area boundary buys and what it does not, where the boundaries should sit, which area type removes which information, and the area designs that partition a network without improving it. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
An area boundary confines the advertisements that trigger a full shortest path computation, and confines nothing else unless the boundary summarises the prefixes crossing it.What Actually Limits the Scale?
What is the constraint?
Three things, none of which is a router count. How often the full shortest path computation runs, which is driven by how often the topology inside an area changes. How long each computation takes, which grows with the number of nodes and links in the area. And how much memory the database occupies, which grows with every advertisement held. The published figures about routers per area were a proxy for the first two on hardware from a different era, and they are not the constraint now.
A Deeper Dive into the Limits
Why the old numbers persist
They were reasonable guidance when a computation over a few dozen nodes took a noticeable time and memory was measured in megabytes. They were also easy to remember, which is why they outlived the hardware they described.
Repeating them today produces two failures. A design partitioned into areas it does not need, which costs configuration and summarisation boundaries for no benefit. And a design assumed to be safe because it is under the number, while the actual constraint — a flapping link generating continuous recomputation — is nowhere near it.
The computation frequency
A change to the topology within an area causes every router in that area to recompute. On a stable network that happens rarely; on one with a flapping link it happens continuously, and the processor cost is real.
That makes the number of unstable links in an area more important than the number of routers. An area with two hundred stable routers is calmer than one with twenty and a link that bounces every few minutes.
The computation cost
Grows with the nodes and links being considered. Modern implementations do this quickly and the growth is not linear, so an area twice as large costs more than twice as much — which is the argument for bounding area size that survives the obsolescence of the specific numbers.
Measuring it is straightforward and rarely done. The routing process reports how long its computations take and how often they run, which converts this from a rule of thumb into a number for this network.
! Measure rather than assume. Both numbers are reported.
R1# show ip ospf statistics
Area 0: SPF algorithm executed 214 times
SPF calculation time (in msec):
Delta T Intra D-Intra Summ D-Summ Ext Total
00:04:12 4 0 1 0 0 6
!
R1# show ip ospf | include SPF|throttle|LSA
R1# show ip ospf database database-summary
The database size
Every advertisement in every area the router participates in. A router inside one area holds that area's topology plus the prefixes reaching it from elsewhere; a boundary router holds one database per attached area.
Summarisation is what bounds the second part, and stub configurations bound the external part. Without either, the database grows with the whole network regardless of how it is partitioned.
The two kinds of recomputation
This is the distinction that makes area design work. A change to the topology — a link or a node — triggers a full computation, and only within its own area. A change to a prefix reaching the router from elsewhere triggers a partial recalculation, which is much cheaper, and it propagates everywhere.
So an area boundary genuinely confines the expensive operation. It does not confine the cheap one, and a network with thousands of prefixes changing frequently is doing a great deal of cheap work everywhere.
THE TWO OPERATIONS, AND WHAT CONFINES THEM
a link or node changes
-> FULL computation
-> confined to that area by the area boundary
a prefix from another area changes
-> partial recalculation, much cheaper
-> propagated to every area
-> confined only by SUMMARISATION
Areas confine the expensive one. Summarisation confines the
cheap one. Doing the first without the second is half a design.
What to check on a real network
How often the full computation runs and how long it takes, per area. How many advertisements the database holds. And whether either is trending upward as the network grows.
Those three numbers turn area design from a rule-following exercise into an engineering one, and they are available from the routing process without any additional tooling.
| Concern | Old guidance | Actual constraint |
|---|---|---|
| Area size | A router count | Computation time and frequency |
| Areas per boundary router | A small number | A database per attached area |
| Stability | Not addressed | Unstable links in the area |
| Database size | Not addressed | Summarisation and stub configuration |
What Does a Boundary Buy?
What does it confine?
Topology. The advertisements describing links and nodes stay inside their area, so a link failure causes a full computation there and nowhere else. What crosses the boundary is a description of the prefixes reachable through it, and by default that is one advertisement per prefix, regenerated whenever the prefix changes — which means the event still reaches every router in the network, cheaply, unless the boundary summarises.
A Deeper Dive into the Boundary
What stays inside
The detailed topology: which routers exist, which links join them, what each costs. That is the input to the expensive computation and confining it is the primary benefit of areas.
A router in one area has no knowledge of another area's internal structure. It knows what prefixes are reachable and at what cost, which is sufficient to route and insufficient to compute a path through it — which is exactly the intent.
What crosses
One advertisement per prefix, generated by the boundary router, describing reachability and cost. When a prefix appears, disappears or changes cost, that advertisement is regenerated and flooded through the rest of the network.
Each such change is cheap to process and there can be a great many of them. A network with several thousand prefixes and ordinary churn produces a continuous background of flooding and partial recalculation everywhere.
What summarisation changes
A range configured at the boundary replaces the individual advertisements with one covering the whole range. A prefix inside the range appearing or disappearing does not change the summary, so nothing is flooded and nothing outside recalculates.
That is the actual containment. Without it, areas separate databases and do not separate events; with it, an area's instability is genuinely invisible to the rest of the network.
! The line that makes areas worth having
ABR(config)# router ospf 1
ABR(config-router)# area 1 range 10.1.0.0 255.255.0.0
!
! And a discard route so the summary does not black-hole
ABR(config)# ip route 10.1.0.0 255.255.0.0 Null0 254
!
! Confirm: one prefix out of area 1, not fifty
CORE# show ip route ospf | include 10.1
O IA 10.1.0.0/16 [110/20] via 10.0.0.1, GigabitEthernet0/1
Why it depends on the addressing
A range can only be configured if the prefixes it covers are contiguous. An addressing plan that allocated subnets as they were requested, from one pool, produces areas whose prefixes are scattered and cannot be summarised.
That makes the addressing plan the area design. Deciding the areas and then allocating a contiguous block to each, generously, is the sequence; deciding the areas after the addressing exists frequently means the areas cannot summarise and the partitioning is decorative.
The discard route
A summary advertises reachability for the whole range including addresses that do not exist. Traffic to those follows the summary to the boundary router, which has no specific route and forwards it according to whatever it does have — possibly back out, producing a loop.
A discard route covering the summary, at the boundary, resolves it by giving the boundary router somewhere definite to send them. It is a standard accompaniment to summarisation and is easy to omit.
What the boundary router holds
A separate database per attached area, plus the computation for each. A router attached to four areas runs four computations and holds four databases, which is the reason the old guidance limited the number.
The modern version of that guidance is to measure. A boundary router attached to several small stable areas is comfortable; one attached to two large unstable ones may not be.
| Crosses the boundary | By default | With summarisation |
|---|---|---|
| Topology detail | No — never | No |
| One advertisement per prefix | Yes | No — one per range |
| A change to any prefix | Flooded everywhere | Nothing leaves |
| Full computation | No | No |
| Partial recalculation elsewhere | Yes, per change | Only when the range changes |
Where Should the Boundaries Be?
What decides the placement?
Two things: where the addressing is naturally contiguous, and where instability should be contained. Those usually coincide, because a campus block, a site or a region is both an addressing region and a place where links fail. The backbone contains the stable infrastructure joining them and should contain nothing that flaps. Access layers belong in their own areas, never in the backbone, because they are where instability originates.
A Deeper Dive into Placement
The backbone's job
Join the other areas, and be stable. Every area attaches to it and it must be contiguous, which makes it the one area whose failure is everybody's failure.
That argues for it containing only the infrastructure that joins areas — the core devices and the links between them — and nothing that changes often. Every additional thing placed in the backbone is a potential full recomputation for every backbone router.
Where instability lives
Access layers, branch circuits, anything terminating users or third parties. Those are where links go up and down for reasons unrelated to the network's design, and they belong inside an area whose boundary summarises.
Placing them in the backbone is the design error with the largest consequence, because it means every user-facing event recomputes the backbone, which is the area every other area depends on.
Matching areas to addressing regions
An area should correspond to a contiguous block of addressing, because that is what makes summarisation possible. A campus block, a building, a region — whatever unit the addressing plan already uses is the natural area.
Where the addressing does not have such units, creating areas first and renumbering to match is the honest sequence, and it is a project. Creating areas that cannot summarise is the alternative and it delivers little.
AREAS FOLLOW THE ADDRESSING, WHICH FOLLOWS THE STRUCTURE
Area 0 10.0.0.0/16 core infrastructure only
Area 1 10.1.0.0/16 campus block 1
Area 2 10.2.0.0/16 campus block 2
Area 10 10.10.0.0/16 branches, region A
Area 11 10.11.0.0/16 branches, region B
Each one summarises to a single prefix at its boundary.
Each one contains its own instability.
The backbone contains nothing that flaps.
How many areas
As many as there are natural addressing regions with distinct stability characteristics, and no more. Creating areas to satisfy a remembered number produces boundaries that summarise nothing and add configuration.
The honest answer for many enterprise networks is fewer than expected: a backbone, one area per major site or campus block, and one per region of branches. A network of that shape with proper summarisation scales a long way.
The single-area question
A network that is stable, whose computation times are short and whose database is comfortable, does not need areas. That is a defensible design and it is rarely stated as one, because partitioning is assumed to be good practice.
The test is the measurement. If the computation runs rarely and completes quickly and the database is modest, adding areas buys configuration complexity and boundaries to maintain.
Repairs that should be redesigns
A mechanism exists to attach an area to the backbone through another area, for cases where the backbone has become discontiguous. It works and it is a repair.
Planning one into a new design is a sign that the areas were drawn wrongly, because a design starting from a contiguous backbone never needs it. Where one already exists, it is worth understanding what it is repairing and whether the underlying shape can be fixed instead. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
! A repair for a discontiguous backbone. Not a design element.
ABR1(config)# router ospf 1
ABR1(config-router)# area 1 virtual-link 10.255.0.5
!
ABR2(config)# router ospf 1
ABR2(config-router)# area 1 virtual-link 10.255.0.1
!
! If a new design needs this, the areas were drawn wrongly.
ABR1# show ip ospf virtual-links
| Belongs in | Because |
|---|---|
| The backbone | Core infrastructure only — it must be stable |
| Its own area | Each campus block or site, with contiguous addressing |
| Its own area | Branch-facing links — where instability originates |
| Nowhere | Areas created to satisfy a remembered number |
Which Area Type?
What do the types remove?
Progressively more. A standard area receives everything. A stub area does not receive external advertisements and gets a default instead. A totally stubby area additionally does not receive inter-area prefixes and gets only the default. Two further variants do the same while still permitting external routes to be injected locally. The choice is about how much an area needs to know, and for most access and branch areas the answer is almost nothing.
A Deeper Dive into the Types
What a stub area removes
External advertisements — routes redistributed into the protocol from elsewhere. On a network with a substantial external table, that is the largest part of the database, and removing it from areas that do not need the detail is a large reduction.
The replacement is a default route injected by the boundary router, which is sufficient whenever the area has one way out. That condition holds for most access and branch areas.
What the totally stubby variant removes
Everything from outside: external advertisements and the per-prefix inter-area advertisements as well. The area receives a default and its own topology and nothing else.
That is the smallest possible database and it is the right choice for any area with a single exit that does not need to make a path decision about where to leave. For a branch area, or an access area behind one pair of boundary routers, it is almost always correct.
! Configure the type on every router in the area, consistently
!
! Stub: no external advertisements, a default instead
ABR(config-router)# area 10 stub
BRANCH(config-router)# area 10 stub
!
! Totally stubby: nothing from outside at all, on the ABR only
ABR(config-router)# area 10 stub no-summary
!
BRANCH# show ip route ospf
O*IA 0.0.0.0/0 [110/11] via 10.10.0.1, GigabitEthernet0/1
! One route. That is the whole external view.
When the area has two exits
A totally stubby area with two boundary routers receives a default from each and chooses between them on cost. That is correct for reaching anything outside, and it cannot distinguish between destinations — everything outside looks the same.
Where one exit is genuinely better for some destinations, the area needs the inter-area detail and the ordinary stub configuration is the right one. That is the discriminating question and it is answerable from the topology.
The variants permitting local external routes
An area that must inject routes from elsewhere — a branch with a local connection to something, or a site running a different protocol — cannot be a plain stub, because stub areas forbid external advertisements entirely, including ones originating inside them.
The variants exist for exactly that: the area behaves as a stub for everything arriving, and still permits routes to be injected locally and carried to the rest of the network. The totally-stub version of the variant is the usual choice for a branch with a local internet connection.
! A branch area that also injects its own external routes
ABR(config-router)# area 20 nssa no-summary default-information-originate
BRANCH(config-router)# area 20 nssa
!
BRANCH(config)# router ospf 1
BRANCH(config-router)# redistribute static subnets
!
! The branch gets a default in, and its local routes get out.
BRANCH# show ip ospf database nssa-external
The consistency requirement
Every router in an area must agree on its type, because the type is carried in the messages that establish adjacency. A mismatch prevents the adjacency forming, which is at least an obvious failure.
The totally-stub variants are configured on the boundary router only, which is a common source of confusion: the area is declared stub everywhere and totally stub in one place.
Choosing, in practice
Backbone: standard, always. A campus block with one pair of boundary routers and no local external routes: totally stubby. A branch area with a local connection to inject: the totally-stub variant permitting local externals. Anything needing to distinguish between exits for different destinations: ordinary stub or standard.
That covers nearly every case, and the default answer for an access or branch area is the most restrictive one that works.
| Area | Type | Because |
|---|---|---|
| Backbone | Standard | Everything transits it |
| Campus block, one exit pair | Totally stubby | Smallest database, one way out |
| Branch with local injection | Totally not-so-stubby | Same, plus local externals permitted |
| Area choosing between exits | Stub | Needs the inter-area detail |
| Anything with transit through it | Standard | Needs the full picture |
Which Designs Do Not Help?
What fails to deliver?
Four. Areas without summarisation, which separate databases and nothing else. Areas drawn without regard to the addressing, which cannot summarise even if somebody tries. Instability inside the backbone, which makes every other area's dependency recompute. And partitioning applied to a network whose measurements never indicated a problem, which is configuration complexity purchased for nothing.
A Deeper Dive into What Does Not Work
Areas without summarisation
Covered throughout and worth stating as the central failure. The topology is confined, which is real, and every prefix still crosses individually and every change to any of them still reaches every router.
The symptom is a network that was carefully partitioned and behaves almost exactly as it did before. The fix is a range per area, and the obstacle is usually the addressing.
Areas the addressing cannot support
Drawing areas around organisational or geographical boundaries that do not correspond to contiguous addressing produces areas whose prefixes are scattered. No range covers them without also covering addresses in other areas, so no range can be configured.
That is discovered after the areas are deployed, and the remedy is renumbering. Doing the addressing and the areas together, before either is implemented, avoids it entirely and costs nothing at that stage.
THE ORDER THAT WORKS
1. Decide the structural units: sites, blocks, regions
2. Allocate a contiguous, generous address block to each
3. Make each unit an area
4. Summarise each area's block at its boundary
5. Choose the most restrictive area type that works
Doing 3 before 2 produces areas that cannot summarise,
and the remedy for that is renumbering.
Instability in the backbone
Anything that flaps, placed in the area every other area depends on. Branch circuits are the usual case and the most damaging, because there are many of them and they are the least stable links in the network.
The general rule is that the backbone contains the infrastructure joining areas and nothing that terminates anything. Applying it means asking, for every link placed in the backbone, whether it can go down for reasons outside the network team's control.
Partitioning without a measurement
A network divided into areas because that is what one does, on evidence that consisted of a remembered router count. If the computation was running rarely and completing quickly, the partitioning bought nothing and added boundaries, summarisation ranges, discard routes and area types to maintain.
The honest sequence is to measure, decide whether there is a problem, and partition if there is. Many enterprise networks measured properly turn out to be comfortable in a single area, and the finding that matters is a flapping link rather than a size.
What to check on an existing design
One prefix per area in the backbone's routing table, or an explanation. The backbone's database containing only core infrastructure. Computation frequency and duration per area, trending flat. And every area at the most restrictive type that its topology permits.
Four checks, all available from the routing process, and between them they establish whether the partitioning is doing anything.
! Is the partitioning actually working? Four checks.
!
! 1. One prefix per area out of each boundary
CORE# show ip route ospf | count 10.
!
! 2. Does the backbone contain anything that flaps?
CORE# show ip ospf database router | include Link ID
!
! 3. How often, and how long?
CORE# show ip ospf statistics | include executed|Total
!
! 4. Could any area be more restrictive?
CORE# show ip ospf | include Area|stub|NSSA
Tuning as an alternative
Where the computation runs too often for comfort, throttling it is available and delays reaction in exchange for absorbing rapid change. That is occasionally the right answer and it is a mitigation rather than a design.
The better answer is almost always to find what is flapping and stop it, or to move it behind a summarising boundary. Tuning the protocol to tolerate instability leaves the instability in place.
! Mitigation, not a design. Find the flapping link instead.
R1(config)# router ospf 1
R1(config-router)# timers throttle spf 50 200 5000
R1(config-router)# timers throttle lsa all 10 500 5000
R1(config-router)# timers lsa arrival 100
!
! And find what is actually causing it
R1# show ip ospf database router | include Advertising|Age
R1# show logging | include OSPF-5-ADJCHG
What a good design looks like
A backbone containing only core infrastructure. One area per structural unit, each with a contiguous address block and a range at its boundary. The most restrictive area type each can use. Discard routes accompanying the summaries. And measurements showing that the computation runs rarely and completes quickly in every area.
That scales further than most enterprise networks will ever need, and none of it depends on remembering a number.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers routing protocol design within its design domain. What is examined is generally the reasoning — what a boundary confines, what summarisation buys, which area type suits which topology — rather than configuration, and the published topic list is the authority on scope.
| Design | Delivers | Fix |
|---|---|---|
| Areas, no summarisation | Database separation only | A range per area |
| Areas the addressing cannot support | Nothing | Renumbering |
| Branch links in the backbone | Backbone recomputes constantly | Move them behind a boundary |
| Partitioning with no measurement | Complexity | Measure first |
| Standard areas everywhere | Largest possible databases | The most restrictive type that works |
| Throttling to tolerate flapping | Slower reaction | Find the flapping link |
Conclusion
The constraint was never a router count. It is how often the full computation runs, how long it takes and how much memory the database occupies — and the first of those is driven by unstable links rather than by size, so an area with two hundred stable routers is calmer than one with twenty and a link that bounces. All three are reported by the routing process, which turns area design from following a remembered figure into an engineering decision with numbers behind it.
An area boundary confines topology, which is the expensive operation, and confines nothing else. Every prefix still crosses individually and every change to any of them still reaches every router in the network, cheaply and continuously. Summarisation at the boundary is what makes an area's instability genuinely invisible to everyone else, and it is possible only where the addressing inside the area is contiguous — which makes the addressing plan the area design, and areas drawn after the addressing frequently unable to summarise at all.
Put the boundaries where the addressing is contiguous and the instability lives, keep the backbone to core infrastructure and nothing that terminates anything, and give each area the most restrictive type its topology permits — for most access and branch areas that is the smallest possible database and a default route. And measure first: many enterprise networks partitioned on principle turn out to have been comfortable in a single area, with one flapping link as the actual problem. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 2328 — OSPF Version 2
- RFC 3101 — The OSPF Not-So-Stubby Area (NSSA) Option
- RFC 5340 — OSPF for IPv6
- RFC 4632 — Classless Inter-domain Routing (CIDR)
- RFC 3509 — Alternative Implementations of OSPF Area Border Routers
- RFC 2072 — Router Renumbering Guide
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 2328 specifies OSPF, including areas, the area border router, and the requirement that the backbone area be contiguous.
- RFC 2328 states that router and network advertisements are flooded only within their own area, which is the basis of confining topology to an area.
- RFC 2328 defines the summary advertisement generated by an area border router to describe inter-area reachability, generated per prefix unless aggregation is configured.
- RFC 2328 defines stub areas, into which external advertisements are not flooded and for which the area border router originates a default route.
- RFC 2328 states that all routers in an area must agree on whether it is a stub area, since the setting is exchanged in hello messages.
- RFC 2328 describes the routing table calculation, distinguishing the shortest path computation over the area's topology from the processing of summary and external advertisements.
- RFC 2328 describes virtual links as a means of connecting an area border router to the backbone when it has no physical backbone connection.
- RFC 3101 defines the not-so-stubby area, which behaves as a stub area while permitting external routes to be originated within it.
- RFC 3509 describes alternative area border router implementations and the resulting differences in how inter-area routes are calculated.
- RFC 4632 describes address aggregation and its dependence on the addresses being contiguous, which is the condition for configuring an area range.
- RFC 2072 describes the practical difficulty of renumbering a network, which is the remedy when areas are drawn without regard to the addressing plan.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include routing protocol design within the design domain.