When does a multi-building network need a separate core?

Focus on distribution-block connections, not building count ↑

A distribution block groups several access segments and the distribution layer above them into one design unit. It may coincide with a building, but it need not. Service paths and maintenance responsibilities may call for several blocks within one building, or one block spanning several small buildings.

Treat the earlier two-tier example as one distribution block. Now suppose blocks A and B each have their own access and distribution roles. PC-A in block A needs App-B in block B. Distinguish traffic that stays within a block from traffic that travels between blocks.

With few blocks and simple connections, directly linking the distribution devices may be an option. A design is not wrong merely because it lacks a separate core. Check whether the current connections meet capacity, failure-handling, policy, and expansion requirements.

If adding blocks makes connections and changes harder to manage, there may be a reason to give interblock forwarding its own core role. Each distribution layer still aggregates its access segments; the core forwards between distribution blocks, carrying their packets. Compare how much this simplifies connectivity and reduces the scope of changes.

If different teams manage the blocks, decide who may change the shared forwarding infrastructure. Separating equipment tiers without clarifying change authority and coordination can lead to conflicting work on the shared core. Design the connections and assign responsibility for their configuration together.

The case for a core therefore rests on connectivity and operating needs—not a rule such as having three buildings. Record how much existing blocks must change when a new one is added, and whether shared forwarding needs independent maintenance. Clear requirements let you compare the problems a core solves with the risks of multiple blocks depending on that same core.

Place the earlier access-and-distribution design in both block A and block B, then give forwarding between them to the core. The dashed areas mark distribution blocks whose design and maintenance are considered together, not the outside walls of buildings.

Trace each role from PC-A to a server in another building ↑

Suppose C1 and C2 form a core between blocks A and B, with each block's distribution devices connected to both core devices by L3 paths. The point is not to draw three rows of equipment. It is to separate forwarding within a block from forwarding between blocks.

PC-A is 10.60.10.21; App-B is 10.70.20.10. The endpoint sends a frame to its gateway, and traffic follows block A's routing path to distribution. That distribution device selects a route to the destination in block B and forwards toward the core.

The core sends the packet along a route toward the destination in block B. It reaches App-B through block B's distribution and access segments; the reply follows a route back to PC-A's address. Requests and replies may cross different core devices, so check the actual routes and policies in both directions.

Traffic within the same VLAN between two endpoints on the same access switch does not need to travel through the core. Distinguishing paths that need the core from those that do not clarifies the demand on shared forwarding devices. That is why the sum of all endpoint port speeds is not the core's actual traffic demand.

If traffic crosses a stateful security device, show the conditions needed for it to handle both directions. Different physical paths may work differently depending on supported behavior and state sharing. Verify asymmetric routing against the way that security device handles bidirectional connection state.

To keep the core focused on forwarding, decide where user policies and service boundaries belong. Simplifying the design does not mean removing required security. Place user policy and service protection explicitly, then let the core concentrate on reliable forwarding between blocks.

Follow the request from PC-A in block A to App-B in block B. Distinguish the chosen and alternate paths, then check the reply's path separately.

Route summaries simplify routing but can hide lost reachability ↑

Planning addresses by block allows routes advertised upstream to be summarized. Here, suppose block A is assigned 10.60.0.0/16 and block B 10.70.0.0/16. These are planning allocations; they do not mean every subnet within them actually exists.

When block A advertises 10.60.0.0/16 to the core, the core can send traffic for that range toward block A. But if the route to the actual destination subnet has disappeared inside block A, the summary alone cannot complete delivery. An upstream route and a reachable downstream service are separate checks.

For example, the /16 summary may remain because other subnets still exist even after the 10.60.10.0/24 route is lost. The core can show a healthy summary while traffic to PC-A fails. Troubleshooting must follow the destination's more-specific route down to the actual forwarding point.

Also decide what happens to traffic for addresses inside the summary that have no actual route. Depending on the design, a discard route at the summarization point can prevent forwarding loops, but verify its behavior and preference in the routing implementation you use. A discard route decides what to do with misdirected packets; it does not restore a missing downstream service.

Overlapping addresses between blocks, or moving addresses to another block, changes the assumptions behind a summary. When allocating addresses, do not look only for unused space: check which block will receive and forward packets for those addresses. The assigned block and the routing path must agree for a summary to make the packet's destination block clear.

A summary can remain in the core while a specific subnet route disappears inside the block. This example shows why the upstream summary and the actual downstream route must be checked together.

Core-device failure and distribution-block failure are different ↑

If C1 fails, the design should carry interblock traffic through C2. Both blocks need routes to each other's destinations through C2, and the links to C2 need enough remaining capacity. Checking that the cables are connected is not enough.

Redraw the path from PC-A to App-B with only C2 available. Check that block A's distribution can forward to C2 and that C2 can forward to block B. Then trace the reply from App-B to PC-A separately, checking each direction's policy and the requirements of stateful devices.

When C1's traffic moves to C2, the load on individual connections changes, too. A low average in normal operation can hide concentrated demand on one block's connection. Do not treat total core throughput and the limits of individual ports or queues as interchangeable.

By contrast, if both distribution devices in block A become unreachable, the block can lose external connectivity even with C1 and C2 healthy. Shared power or a common circuit route can take both distribution devices down. Core redundancy does not protect against every failure in a downstream block.

Reflect that distinction in incident reports. Is the problem in the whole core or one block? Does traffic within the block still work, with only external traffic failing? Use the same block names and failure domains defined in the design to report the extent of the impact.

Check the benefits during changes and maintenance, too ↑

A separate core can clarify not only normal packet forwarding but also the scope of changes and maintenance on each device. Explain how that scope differs when adding access, maintaining one distribution block, or replacing shared forwarding devices.

When adding a business subnet to block A, check whether block B's access configuration must change. Suitable address planning and summaries can keep some changes within a block. Security policies or shared-service allowlists may still need separate changes, however; not every change stays local.

Before maintaining C1, verify that C2 alone can support the required services. It must provide the endpoints with working paths and sufficient upstream capacity, with management access and policy still functioning. Actual business requests and replies matter more than simply having established routing neighbors.

A new block adds more than core ports and circuits: it also adds routes, policy effects, and failure tests. Free ports alone do not prove the network can expand. Document the conditions that should trigger a design review so the same criteria guide future growth.

Check whether maintenance access itself passes through the core being maintained. The business path may have a backup while losing the management path delays rollback. Trace access from the operator's location to the target device separately and verify a dependable alternative.

An alternate path on a diagram still needs a test showing whether it can carry the work during a real failure. Design validation sets out the failures and services to test, acceptable downtime, and rollback conditions. We have now examined the internal network. The next part covers the circuits, addresses, and routing policies needed to connect it to branches, the cloud, and the Internet.