Dual Core Network Design: Principles, Topology and Testing

A dual core network design places two identical core switches at the centre of the campus. Every distribution block connects to both, so the loss of one switch or one link does not interrupt service. Done well, it gives resilient, load-shared connectivity for sites that cannot tolerate a core outage. This guide explains how the design is built, when it is justified, how failover behaves and how to prove it works before go-live.

Re-solution

Build a More Resilient Network Core

Re-Solution provides Cisco network solutions, infrastructure audits and network surveys to help organisations plan robust connectivity.

Visit

TL;DR

A dual core uses two separate core switches, with each distribution block dual homed to both, so a single failure leaves a working path.
Cisco recommends a routed Layer 3 core with equal-cost paths, because it converges faster and uses bandwidth more efficiently than a Layer 2 core.
A collapsed core is the sensible alternative for smaller, single-building sites. Dual core suits multi-building or multi-block campuses.
Keep the core simple: minimal configuration, no user or server connections, no complex policy.
Test failure of every component before go-live, and again after any major change.

What a dual core network design is
Dual core or collapsed core
How the links are connected
Why a Layer 3 core is the usual choice
First-hop redundancy at the edge of the design
How failover and load sharing work
What to assess before you design
Implementing and testing the design
Common mistakes
Perspective
How Re-Solution can help
FAQ
Sources

What a dual core network design is

In the classic hierarchical campus model, access switches feed distribution switches, and distribution switches feed the core. The core has one job: move traffic between distribution blocks as quickly and reliably as possible. In a dual core, that function is delivered by two switches rather than one, so the core itself is no longer a single point of failure.

Cisco’s Enterprise Campus architecture describes the campus core as a non-stop, 7x24x365 service. It should not carry complex policy services or directly attached user and server connections, and it should combine a minimal control plane configuration with highly available devices and the right amount of physical redundancy. A dual core is how that physical redundancy is usually delivered.

The two core switches are separate devices, both active, and each is a full peer rather than a standby. In Cisco’s Smart Business Architecture the core is based on two physically and logically separate switches, with connectivity to and from the core being Layer 3 only.

Dual core or collapsed core

The first decision is whether a separate core is needed at all. A collapsed core merges the core and distribution functions into one pair of switches. Cisco’s Borderless Campus guidance says that in smaller campus locations with fewer users, or single-building sites, separate core and distribution layers may not be needed, and the two-tier collapsed core is recommended instead.

Cisco Press’s CCDE study guide puts a limit on this: the two-tier model suits small to medium campuses, ideally with no more than three functional blocks interconnected. Beyond that, adding a dedicated core stops the distribution layer becoming a tangle of full-mesh links.

Factor	Collapsed core	Dual core
Typical site	Single building or small campus	Multi-building campus, several distribution blocks
Layers	Two tiers	Three tiers
Cabling	Fewer links, simpler	Two uplinks per distribution block, more fibre
Growth	Limited by the distribution pair	Add distribution blocks without redesigning the core
Resilience	Pair of switches does both jobs	Core failure isolated from distribution

If you are weighing the options for a particular site, our overview of campus network design principles covers the wider context, and the guide to network topology types shows where a dual core sits among them.

How the links are connected

The standard pattern is simple to describe. Each distribution block has a link to core switch A and a link to core switch B. Cisco’s SBA guidance states that each distribution layer block should be dual homed with an EtherChannel or a link to each core switch.

Three design points follow from this:

Routed links. Each uplink is a point-to-point Layer 3 link, not a trunk. No VLAN needs to span the core, which Cisco says increases resilience and stability.
Triangles, not squares. Cisco’s high availability campus guide advises redundant point-to-point Layer 3 interconnections in the core, in triangles rather than squares, because this gives the fastest and most deterministic convergence. A triangle gives every node an equal-cost path to every other, so recovery does not rely on timers.
Equal-cost paths. The same guide recommends equal-cost redundant connections to the core, so both paths carry traffic in normal operation.

Whether to link the two core switches to each other is a design choice. In a pure routed design, a link between them is often used for routing adjacency, but the principle is the same: avoid creating a Layer 2 loop in the core, and keep the design easy to reason about.

Why a Layer 3 core is the usual choice

Cisco’s guidance favours a high-speed, hardware-accelerated Layer 3 core over a Layer 2 one. The reasons it gives are faster convergence around link or node failures, better scalability through fewer neighbour relationships and meshing, and more efficient use of bandwidth.

The practical effect is that the core carries routed traffic only. Spanning Tree stops being a factor in the core, so no links sit blocked waiting for a failure. This matters as bandwidth demands grow: Allied Telesis notes that a perennial problem with Spanning Tree is that some links stay blocked during normal operation, becoming active only after a fault. Routed equal-cost paths avoid that waste.

On the routing protocol itself, an IGP such as OSPF or EIGRP is typical in enterprise campuses. Summarising routes at the distribution boundary keeps the core routing table small and limits how far a change propagates. Whichever protocol you choose, keep area and summarisation design consistent across blocks.

First-hop redundancy at the edge of the design

The core is only part of the story. Hosts still need a default gateway that survives a switch failure. Where the gateway sits at the distribution layer, Cisco recommends HSRP, GLBP or VRRP for default-gateway redundancy. These protocols let multiple routers on one subnet act as a single default router.

The differences are practical. An academic study of Layer 3 redundancy describes HSRP as a Cisco proprietary active/standby protocol, GLBP as active/active with load balancing, and VRRP as the standards-based option, typically used where non-Cisco routers are present. In an all-Cisco campus, HSRP is the common default, while a mixed estate points towards VRRP.

If the distribution layer is built from stacked or virtualised switches, a split link aggregation approach can remove the need for a separate gateway protocol. Allied Telesis describes this as grouping links from separate units so they act as a single link, delivering both resilience and better bandwidth use. The principle applies across vendors, though the feature names differ.

In normal operation, each distribution block has two equal-cost paths to the core, so traffic is shared across both. Cisco’s SBA design describes this as ECMP load sharing of IP traffic across the links, with fast failover based on either EtherChannel or ECMP alternate routes, without waiting for routing protocol changes to propagate.

When a link fails, the switch simply stops using that path. When a whole core switch fails, the routing protocol detects the lost neighbour and the remaining core switch carries all traffic. Each distribution block then runs at the capacity of a single uplink, which leads to the most important sizing rule: each core switch, and each uplink, must be able to carry the full load alone, or the design is redundant in name only.

One caution from Cisco: keep redundancy simple. The same guide notes that excessive redundancy can reduce availability by making the network harder to service and less deterministic. Two well-built paths beat four tangled ones.

What to assess before you design

A dual core is a significant investment in switches, optics and fibre. These checks set the specification.

Traffic and capacity

Measure current peak and average utilisation on existing uplinks, not just port speeds.
Identify where traffic concentrates: data centre or server room, internet edge, cloud on-ramps, wireless controllers.
Size for single-switch failure: the surviving core must carry 100% of the peak.
Allow headroom for growth in wireless density, video and IoT devices over the equipment’s life.

Physical and topology constraints

Fibre routes between buildings: are there two diverse paths, or one duct that makes the second link pointless?
Where the two core switches will be housed. Two switches in one rack share power, cooling and a single fire risk.
Power resilience: separate feeds or UPS circuits for each core switch.

Design discipline

Cisco’s campus guidance says the core should have no directly attached user or server connections and no complex policy. Security enforcement, segmentation and access control belong at the distribution and access layers, which keeps the core fast and predictable. Cisco’s high availability guide describes this as a “less is more” approach, where minimal core configuration reduces complexity and the chance of operational error.

Operational readiness

Who monitors the core, and with what alerting and out-of-band access?
How are software upgrades staged? Cisco states the design must allow hardware and software changes without disrupting network applications, which a dual core makes possible only if one switch can be upgraded while the other carries traffic.
Is there a current configuration baseline and documentation? A network audit is the quickest way to establish this before design starts.

Implementing and testing the design

The design objective Cisco sets for the core is near-immediate data-flow recovery after the failure of any component: switch, supervisor, line card or fibre. Testing should therefore match that list.

Build and document the baseline. Record the routing tables, neighbour states and interface counters with both cores healthy.
Migrate one block at a time. Move distribution blocks onto the new core in sequence, with a rollback plan for each.
Test link failure. Pull each uplink in turn while running a continuous traffic test. Record packet loss and recovery time.
Test switch failure. Power off each core switch in turn. Confirm all blocks stay reachable and that the survivor handles peak load.
Test recovery. Bring the failed device back and confirm traffic returns to both paths without a second disruption.
Test the upgrade procedure. Upgrade software on one core switch while the other carries live traffic, ideally in a maintenance window.
Set monitoring thresholds. Alert on neighbour loss, utilisation above the single-switch limit and interface errors.

Repeat the failure tests after major changes such as adding a block, changing routing policy or replacing optics. For multi-site estates with WAN links, the same thinking carries into SD-WAN design decisions, where the core’s resilience determines how well the overlay can perform.

Common mistakes

Undersized survivors. Two switches at 70% load each cannot cover for each other.
Shared failure domains. Both cores on one power feed, in one room, or on one fibre route.
Policy in the core. ACLs, QoS marking and security services pile up and erode the simplicity that makes failover predictable.
Layer 2 stretching through the core. It reintroduces loops and Spanning Tree dependence.
Untested failover. A design that has never been failed deliberately is an assumption.

Perspective

Most core problems we see in the field are not about hardware. They come from a design that was never sized for failure, or from a core that has slowly collected features it should never have carried.

Our view is that a dual core earns its place when a site has several distribution blocks, a dependence on always-on connectivity, and a team that wants maintenance windows without outages. That describes many of the campuses, factories, warehouses and multi-building hospitality and housing estates we work with. In those settings, we design the core to be routed, symmetrical and deliberately boring, and we put the intelligence at the edge where it can be changed safely.

With more than 35 years of Cisco experience, we start with an audit of what is actually running, then agree the capacity and failure scenarios with the client before any hardware is specified. The same discipline applies after go-live: monitoring and managed support keep the redundancy real, because a second path that has silently failed gives no protection at all.

Jacob

How Re-Solution can help

Re-Solution designs, builds and supports Cisco campus and core networks for education, manufacturing, logistics, hospitality, shared workspaces and property developers. Our professional services cover design and implementation, and our network audits give you a documented baseline of your current core, distribution and access layers before you commit to a redesign.

Once the network is live, our managed services team can monitor and maintain it, and our Network as a Service option suits organisations that prefer a subscription model. To discuss a dual core project, start from the Re-Solution homepage.

FAQ

Is a dual core the same as a collapsed core?

No. A dual core is a dedicated pair of core switches sitting above separate distribution blocks. A collapsed core merges core and distribution into one layer, which Cisco recommends for smaller or single-building campuses. The choice depends mainly on the number of buildings and distribution blocks.

Should the two core switches be linked together?

It depends on the design. In a routed core, each distribution block connects to both core switches and traffic fails over through equal-cost paths. Any link between the cores should be a routed link, and you should avoid creating a Layer 2 loop. Your designer should justify the choice against the failure scenarios you need to survive.

Do I still need a first-hop redundancy protocol?

Often yes. If the default gateway sits on the distribution switches, Cisco recommends HSRP, GLBP or VRRP for gateway redundancy. Stacked or virtualised distribution switches can reduce that need, depending on the platform.

How much capacity does each core switch need?

Each switch and its uplinks should carry the full peak load alone, because after a failure one switch carries everything. Measure real utilisation first, then add headroom for wireless, video and IoT growth over the equipment’s life.

How often should failover be tested?

Test before go-live, then after any significant change such as a new distribution block, routing change or software upgrade. Many organisations also schedule periodic tests during planned maintenance windows, and a managed service can run and document them.