Campus design arguments tend to be about technologies — which loop prevention variant, whether to use a virtual pair, how to arrange the gateway redundancy. Almost all of them are downstream of one decision that is rarely argued about explicitly: where the boundary between switching and routing sits.
Put it at the distribution layer and the access layer is a switched domain, which requires loop prevention, gateway redundancy and a convergence story built from both. Put it at the access switch and all three disappear, replaced by a routing protocol and an addressing plan that costs more space and forbids a VLAN from existing in two places. Those are genuinely different networks with different failure modes, and the choice between them settles most of what follows.
This article covers the unit a campus is designed in, where that boundary should sit and what each answer costs, when a core is actually justified, what summarisation at the distribution buys, and the designs that work on the day they are built and age badly. 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.
The distribution block is the unit a campus is designed in, and the position of the routing boundary within it determines what the access layer needs, how fast it converges and what a failure looks like.What Is the Unit of Design?
What do you design in?
Blocks, not switches. A block is a set of access switches and the pair of distribution switches they attach to, and it is the unit that repeats: adding capacity means adding a block rather than adding devices to an existing one. Everything inside a block is one failure domain and one addressing region; everything outside sees only a summary of it. That structure is what makes a campus scale and what makes a fault stay where it happened.
A Deeper Dive into the Block
Why the block rather than the switch
A design expressed as a collection of switches has no natural boundaries, so a change anywhere can affect anything. A design expressed as blocks has one boundary that matters — the edge of the block — and everything inside it is somebody's local problem.
The practical consequence is that adding a floor, a building or a department means adding a block built from the same template, rather than reasoning about how the addition interacts with everything already there.
What belongs inside one
The access switches serving a contiguous area, the distribution pair, the subnets those switches serve, and the loop prevention or routing that operates between them. A VLAN belongs inside a block; a subnet belongs inside a block; a summary describes the block to everything outside.
Anything that crosses a block boundary is a design decision requiring justification, and the most consequential of those is a VLAN — covered below and in the final section, because it is the thing that most often destroys an otherwise sound design.
What the distribution pair does
It is the boundary. It terminates whatever the access layer runs, it is where the routing begins, it is where the block's subnets are summarised, and it is where policy is applied if policy is applied anywhere below the core.
That makes it the most feature-heavy layer in the campus, deliberately. Concentrating the complexity there keeps the access layer simple and the core simple, which is the point of the arrangement.
WHAT LIVES WHERE
ACCESS ports, port security, classification and marking,
power to devices, and as little else as possible
DISTRIBUTION the routing boundary, summarisation, policy,
gateway redundancy if the access layer is switched
CORE routing and speed. No policy, no services,
no boundaries. Its job is to be boring.
The access layer's job
Connect devices, classify and mark what they send, apply the port-level protections, and deliver power. Everything else is somebody else's layer.
Resisting the temptation to put more there is worth doing deliberately, because the access layer is the largest population of devices and anything placed there is multiplied by that population — in configuration, in licensing, in upgrade effort and in the number of places a mistake can be made.
The core's job
Move packets between blocks, quickly, and nothing else. No policy, no services, no address boundaries, no features that could fail in an interesting way.
A core that is boring is a core that stays up. Every service placed there is a reason to touch it, and a layer that everything depends on should be touched as rarely as possible.
The services block
Shared infrastructure — controllers, security devices, shared servers — attaches as its own block rather than being distributed among the others or placed in the core. That keeps the core clean and gives the services their own boundary, policy point and failure domain.
It also means the shared services can be changed without touching a layer that everything depends on, which is the same argument as everything else in this section.
| Layer | Carries | Should not carry |
|---|---|---|
| Access | Ports, marking, port protections | Anything multiplied by the port count |
| Distribution | The routing boundary, summarisation, policy | — |
| Core | Routing and speed | Services, policy, boundaries |
| Services block | Shared infrastructure | — |
Where Should the Routing Boundary Be?
What are the choices?
Three. At the distribution pair with a switched access layer, which is the traditional arrangement and needs loop prevention plus gateway redundancy. At the distribution pair presented as a single logical device, which removes the blocked links and most of the convergence problem while keeping the access layer switched. Or at the access switch itself, which removes loop prevention and gateway redundancy entirely and costs an addressing plan with a subnet per switch and no VLAN in more than one place.
A Deeper Dive into the Three Positions
The traditional arrangement
Access switches run switching, the distribution pair provides the gateway, loop prevention blocks the redundant path and gateway redundancy decides which distribution switch is active. Convergence is the sum of the loop prevention's reaction and the gateway redundancy's.
Its virtue is that the access switches need no routing capability and a VLAN can exist on several of them, which some applications require. Its cost is that two protocols must agree with each other, and when they do not the traffic path is not the one anybody drew.
! Traditional switched access: the two must agree, per VLAN
DIST-A(config)# spanning-tree vlan 10,30 root primary
DIST-A(config)# spanning-tree vlan 20,40 root secondary
DIST-A(config)# interface Vlan10
DIST-A(config-if)# standby 10 priority 110
DIST-A(config-if)# standby 10 preempt delay minimum 60 reload 180
!
DIST-B(config)# spanning-tree vlan 20,40 root primary
DIST-B(config)# spanning-tree vlan 10,30 root secondary
DIST-B(config)# interface Vlan10
DIST-B(config-if)# standby 10 priority 100
!
! Root and active gateway on the same switch, per VLAN.
! Alternate across VLANs if both uplinks should carry traffic.
The virtual pair
The two distribution switches present themselves as one, so an access switch aggregates its two uplinks into a single logical link to a single logical peer. There are no blocked links, loop prevention has nothing to block, and a failure of one distribution switch is a link member failure rather than a topology change.
This is the common modern arrangement for a switched access layer and it resolves most of the objections to it. The cost is that the pair is now one logical device with shared state, which introduces its own failure modes around the link that joins them.
! Virtual pair: the access switch sees one logical peer
ACCESS(config)# interface Port-channel1
ACCESS(config-if)# switchport mode trunk
ACCESS(config-if)# switchport trunk allowed vlan 10,20,110,120
!
ACCESS(config)# interface range TenGigabitEthernet1/1/1 - 2
ACCESS(config-if-range)# channel-group 1 mode active
!
! One aggregated link, two physical members, two chassis.
! Nothing is blocked, so nothing has to reconverge.
ACCESS# show etherchannel 1 summary
The routed access layer
The access switch is the routing boundary. Its uplinks are routed links, there is no loop prevention operating between it and the distribution, no gateway redundancy is needed because the gateway is local, and convergence is the routing protocol's.
That is the cleanest of the three by some distance. The costs are real: every access switch needs a subnet of its own, which consumes address space and makes the addressing plan larger; a VLAN cannot exist on two access switches; and the access switches must be capable of routing, which is a licensing and hardware question.
THE SAME FAILURE, THREE WAYS
An access switch loses one of its two uplinks.
Switched, traditional loop prevention recalculates,
gateway redundancy may follow.
Seconds, and two protocols involved.
Switched, virtual pair one member of an aggregated link
fails. Sub-second, nothing recalculates.
Routed access one routing adjacency drops,
the other path is already installed.
Sub-second, one protocol.
! Routed access: no loop prevention, no gateway redundancy
ACCESS(config)# interface TenGigabitEthernet1/1/1
ACCESS(config-if)# description To DIST-A
ACCESS(config-if)# no switchport
ACCESS(config-if)# ip address 10.1.254.1 255.255.255.252
!
ACCESS(config)# interface Vlan10
ACCESS(config-if)# description Data - local to this switch only
ACCESS(config-if)# ip address 10.1.10.1 255.255.255.0
!
ACCESS(config)# router ospf 1
ACCESS(config-router)# passive-interface default
ACCESS(config-router)# no passive-interface TenGigabitEthernet1/1/1
ACCESS(config-router)# no passive-interface TenGigabitEthernet1/1/2
What forbids the routed access layer
An application or a device requiring the same subnet on two access switches. Wireless arrangements that assume a spanning VLAN. A campus whose addressing cannot accommodate a subnet per switch. Access hardware without routing capability.
Where none of those applies, the routed access layer is the better answer and the argument against it is usually familiarity rather than technology.
What the choice decides downstream
Whether loop prevention matters at all. Whether gateway redundancy exists. What a convergence number looks like. Whether a VLAN can span. How large the addressing plan is. And what the failure modes are — a switched access layer fails in ways involving two protocols disagreeing, and a routed one fails in ways involving routing.
That is a long list from one decision, which is why it is worth making explicitly rather than inheriting.
| Position | Access needs | Convergence | VLAN can span |
|---|---|---|---|
| Distribution, pair | Loop prevention | Seconds | Yes |
| Distribution, virtual pair | Link aggregation | Sub-second | Yes |
| Access switch | Routing capability | Sub-second | No |
When Do You Actually Need a Core?
What decides it?
The number of distribution blocks. With two, connecting them directly costs four links and a core adds a hop and a pair of devices for no benefit. With three, direct connection costs twelve links and a core costs six — and the core's cost stops growing while the mesh's keeps going. Three blocks is the usual crossover and four makes it unambiguous. Below that, collapsing the core into the distribution is the right answer and not a compromise.
A Deeper Dive into the Core Decision
The arithmetic
Connecting every pair of distribution blocks to every other, with redundancy, grows as the square of the number of blocks. Connecting each block to a core pair grows linearly. The two cross at three blocks and diverge rapidly afterwards.
That is the whole argument and it is worth stating numerically in a design document, because it is the kind of decision that otherwise gets made on the basis of what the previous network had.
THE CROSSOVER, COUNTED
Blocks Direct mesh (redundant) Via a core pair
2 4 8
3 12 12
4 24 16
5 40 20
6 60 24
Two blocks: mesh them, no core.
Three: equal, and the core scales while the mesh does not.
Four or more: not a decision.
The collapsed arrangement
Distribution and core functions in one pair of devices. For a single building or a small campus that is the correct design, not a reduced one — the functions the core provides are not needed when there is nothing to aggregate.
The thing to plan for is the transition. A collapsed design that will grow should be built so that a core can be inserted without re-addressing anything, which means the distribution function is already summarising and the addressing already has block boundaries.
What the core must not become
A policy point. A services attachment. A boundary for anything. Each of those gives a reason to change it, and the core is the layer where a change affects everything.
The discipline is to refuse the first exception. A firewall attached to the core because it was convenient becomes the reason the core is upgraded, and the upgrade affects every block.
Sizing the links
Conventional starting points exist for how much the access-to-distribution and distribution-to-core links may be oversubscribed, and they are starting points rather than rules. The figures that matter are the ones this campus produces, which come from measuring rather than from a table.
The useful discipline is to state the assumed ratio in the design document alongside what it was derived from, so that a later question about whether a link needs upgrading has a basis.
Redundancy in the core
A pair, with each distribution block connected to both. That is sufficient and anything beyond it adds paths without adding survivability, because the failure that matters is a device or a link and both are already covered.
The temptation to add a third core device comes from a sense that more is safer. It is more states to reason about for a failure scenario the pair already handles.
Where the boundary of the campus is
The core connects blocks and the edge connects the campus to everything else — the wide area, the internet, the data centre. Those are their own blocks attaching to the core, not functions of it.
Keeping them separate means the campus's external connectivity can change without the core changing, which is the same argument once more. 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.
| Campus size | Arrangement | Reason |
|---|---|---|
| One or two blocks | Collapsed | Nothing to aggregate |
| Three blocks | Either, leaning to a core | The crossover point |
| Four or more | A core | The mesh stops being manageable |
| Any size | Services in their own block | Keeps the core unchanged |
| Any size | Edge connectivity in its own block | Same |
What Does Summarisation Buy?
What does it do?
It stops events from propagating. An access port flapping produces a routing change inside its block and nothing outside it, because everything outside was told about a summary that did not change. Without summarisation, every flap anywhere is a recomputation everywhere, and a campus of six blocks has six times the events and every device processes all of them. This is the whole scaling story of a hierarchical design and it is a property of the addressing plan rather than of any protocol setting.
A Deeper Dive into Summarisation
Why it depends on the addressing
A summary is possible only if the addresses inside a block are contiguous. Allocating subnets as they are needed, from a single pool, produces a network where nothing can be summarised anywhere and no amount of configuration will fix it.
So the addressing plan is the summarisation design. Reserving a contiguous range per block, generously, at the start, is what makes everything afterwards possible — and it costs address space that is not scarce internally.
AN ADDRESSING PLAN THAT SUMMARISES
Block 1 10.1.0.0/16 one summary toward the core
Block 2 10.2.0.0/16 one summary
Block 3 10.3.0.0/16 one summary
Services 10.9.0.0/16 one summary
Loopbacks 10.255.0.0/16 host routes, deliberately
Inside block 1:
10.1.10.0/24 access switch A, data
10.1.11.0/24 access switch A, voice
10.1.20.0/24 access switch B, data
...
Generous, contiguous, and boring. That is the requirement.
What it costs
Address space and the discipline to allocate from the right range. Both are cheap internally, and the alternative — allocating as needed and summarising later — means re-addressing, which is a project rather than a change.
The judgement to make early is how many blocks the campus will ever have and how large each might become. Being generous costs nothing and being tight costs a renumbering.
The routing protocol's part
Whichever protocol is used, summarisation happens at the distribution layer toward the core, and the mechanism differs by protocol without the principle changing. What matters is that it happens there and that the summary covers exactly the block.
A summary that is larger than the block advertises reachability for addresses that do not exist, which black-holes traffic to them. A discard route covering the summary, at the distribution, resolves that and is a standard accompaniment.
! Summarise the block toward the core, and discard the rest
DIST-A(config)# router ospf 1
DIST-A(config-router)# area 1 range 10.1.0.0 255.255.0.0
!
! A discard route so the summary does not black-hole
DIST-A(config)# ip route 10.1.0.0 255.255.0.0 Null0 254
!
! And send the block a default rather than everything
DIST-A(config-router)# area 1 stub no-summary
!
CORE# show ip route ospf | include 10.1.0.0
O IA 10.1.0.0/16 [110/20] via 10.0.0.1, Vlan100
What is deliberately not summarised
Device loopbacks, which frequently need to be individually reachable for management and for anything depending on a specific address. Those are usually carried as host routes from a separate range, and the range being separate is what allows everything else to be summarised.
That is an exception worth stating in the design document, because a later engineer tidying up the addressing may summarise them and break things that depend on individual reachability.
The other direction
What the blocks learn from the core can be summarised too, and frequently a default route is sufficient. An access layer that needs to know about every prefix in the campus is carrying information it never uses.
Sending a default plus whatever specific prefixes are genuinely needed keeps the access layer's table small, which matters on hardware whose table capacity is modest.
Verifying it
The core's routing table should contain one prefix per block plus the loopback range. Anything else means the summarisation is incomplete, and the count is the check — a core carrying two hundred prefixes for six blocks is not summarising.
That single number, checked periodically, catches the addition made outside the plan before it becomes the reason a summary has to be widened.
THE CHECK, ONE NUMBER
Expected in the core's table:
one prefix per block 6
the services block 1
the loopback range 1 (or host routes)
external and default a handful
Actual: count them.
A core carrying two hundred prefixes for six blocks is
not summarising, whatever the configuration says.
| Without summarisation | With it |
|---|---|
| Every flap recomputes everywhere | Events stay inside the block |
| Table size grows with every subnet | One prefix per block |
| Convergence scales with the campus | Convergence scales with the block |
| Fixing it means re-addressing | Free, if planned at the start |
Which Designs Age Badly?
What should be avoided?
Four. A VLAN spanning two distribution blocks, which makes switching the core's problem permanently. Addressing allocated as needed rather than by block, which forecloses summarisation forever. Services attached to the core, which turns the most stable layer into the most frequently changed. And an access layer accumulating features, each multiplied by the number of access switches. All four work perfectly on the day they are built.
A Deeper Dive into Ageing
The spanning VLAN
An application needing the same subnet in two blocks, accommodated by extending the VLAN between them. It works. It also means switching now operates across whatever joins the blocks, loop prevention has a topology spanning the campus, and the failure domain is no longer the block.
That decision is almost always made as a temporary accommodation and almost never removed, because by the time anybody wants to remove it several things depend on it. It is the single most consequential concession in campus design.
Addressing allocated as needed
Subnets handed out from a single pool in the order they were requested. Perfectly reasonable at the time and it produces a campus where no summary is possible, because the addresses in a block are scattered across the range.
The cost appears years later as a routing table that grows with every subnet and events that propagate everywhere. Fixing it is a renumbering, which is why the allocation discipline at the start is worth insisting on when it feels bureaucratic.
Services in the core
Covered earlier and worth listing here because it is a slow failure. Each service attached to the core is individually defensible and the accumulation turns the layer everything depends on into the layer with the most change requests.
The version to watch for is a security device inserted into the core path because it needed to see everything. That makes the core's availability dependent on that device's, which is the opposite of the intent.
Features in the access layer
Each addition is small and there are several hundred access switches. A feature requiring a licence, or an upgrade, or a configuration that must be consistent, is multiplied by that number in every dimension.
The test before adding anything to the access layer: multiply the effort by the switch count and ask whether it is still worth it. Frequently the same outcome is achievable at the distribution layer at a fraction of the multiplication.
THE MULTIPLICATION TEST
A feature at the distribution layer: 12 devices
The same feature at the access layer: 340 devices
Configuration to maintain x 28
Licences x 28
Upgrade effort x 28
Places to get it wrong x 28
If the outcome can be achieved one layer up, it should be.
What ages well
A block that is a copy of every other block. An addressing plan with room in it. A core with nothing in it. A routed access layer, where it is possible. And a design document stating the trade-offs that were made, so that the next engineer knows which decisions were deliberate.
That last one is underrated. A design whose reasoning is recorded survives its author; one whose reasoning is not gets changed by somebody who assumed a deliberate choice was an oversight.
Planning the transition
Campus designs are replaced rather than upgraded, and the replacement is easier if the current one has clean boundaries. A campus of independent blocks can be migrated one block at a time; a campus with VLANs spanning everything cannot be migrated at all without a large coordinated change.
That is the strongest long-term argument for the discipline in this article: it is what makes the next design possible.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers campus architecture within its design domain. What is examined is generally the reasoning — where the boundary sits, when a core is justified, what summarisation buys — rather than a specific topology, and the published topic list is the authority on scope.
| Decision | Works initially | Costs later |
|---|---|---|
| VLAN spanning blocks | Yes | The campus is one failure domain |
| Addressing as needed | Yes | Summarisation is impossible |
| Services in the core | Yes | The stable layer changes constantly |
| Features in the access layer | Yes | Everything multiplied by the switch count |
| Blocks as copies | Yes | Nothing — this is the one that ages well |
Conclusion
A campus is designed in blocks rather than switches, and the block is what makes the structure work: one failure domain, one addressing region, one summary to the outside world. The access layer connects devices and does as little else as possible, because everything placed there is multiplied by the number of access switches. The core routes and does nothing else, because the layer everything depends on should have an empty change window.
Within the block, one decision settles most of the rest: where the routing boundary sits. At the distribution with a switched access layer means loop prevention and gateway redundancy must agree with each other, and convergence is the sum of both. Presenting the distribution pair as one logical device removes the blocked links and most of the problem. Putting the boundary at the access switch removes both protocols entirely, at the cost of a subnet per switch and no VLAN in two places — which is the cleanest answer where nothing forbids it.
And the designs that age badly all work perfectly on the day they are built. A VLAN spanned between blocks for one application makes switching the core's problem permanently, and nobody removes it because by then things depend on it. Addressing allocated as it was needed forecloses summarisation, which cannot be recovered by configuration and requires a renumbering instead. Both of those are decisions taken in an afternoon that shape the next decade, which is the argument for making them deliberately and writing down why. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 3439 — Some Internet Architectural Guidelines and Philosophy
- RFC 1918 — Address Allocation for Private Internets
- RFC 4632 — Classless Inter-domain Routing (CIDR)
- RFC 2328 — OSPF Version 2
- IEEE 802.1Q — Bridges and Bridged Networks
- RFC 2072 — Router Renumbering Guide
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 3439 argues that complexity carries costs frequently underestimated in network design, and that reducing the number of interacting components improves predictability.
- RFC 4632 describes classless inter-domain routing and the aggregation of contiguous address blocks into a single advertisement, which is the mechanism underlying summarisation.
- RFC 4632 notes that aggregation requires the addresses being aggregated to be contiguous, which makes the addressing plan the determinant of whether summarisation is possible.
- RFC 1918 allocates the private address ranges from which campus addressing is normally drawn, and whose size makes generous allocation practical.
- RFC 2328 specifies OSPF, including area boundaries and the summarisation performed at them, which limits the propagation of topology changes.
- RFC 2328 describes how a topology change within an area requires recomputation by routers in that area, which is the basis of containing events within a block.
- IEEE 802.1Q defines VLANs and the bridged domain they create, whose extent determines the scope of a Layer 2 failure.
- IEEE 802.1Q defines the spanning tree mechanisms whose topology spans the extent of a VLAN, so extending a VLAN extends the loop prevention topology with it.
- RFC 2072 describes the practical difficulty of renumbering a network, which is why an addressing plan that forecloses summarisation is expensive to correct.
- Cisco campus design guidance describes the distribution block as the unit of campus design and discusses the placement of the Layer 3 boundary.
- Cisco campus design guidance describes the convergence characteristics of switched and routed access designs and the interaction between spanning tree and first hop redundancy.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include campus architecture within the design domain.