How does Cisco choose a network architecture?

Why might two offices of the same size need different designs? ↑

In the article on scaling from a home router to an enterprise network, we separated the router's functions and examined which business activities stop when one device fails. To choose a suitable structure from Cisco's reference designs, we must also read them in light of business needs and the conditions in which they apply.

Consider two offices as a teaching example. Office A mainly handles documents and can continue working through an approved alternative connection during a circuit outage. Office B needs continuous access to internal business servers; losing communication with those servers also stops work on site. Equal headcounts tell us nothing about this difference.

For A, consider keeping a spare and check whether replacement and configuration restoration fit within the acceptable downtime. B may be unable to stop work while a device is replaced. Its design must then consider alternate paths, device failover, power, and management access. Knowing how long the business can tolerate an interruption is essential to deciding whether device redundancy is needed.

Even a requirement to operate without interruption needs clarification. Briefly being unable to open a new connection is not the same failure as losing a transaction already in progress. The designer asks business owners which activities can stop and for how long, then separates the network's responsibilities from the application's.

Let's compare designs by the functions the business needs, rather than office size. A small site may need redundancy; a simple structure may suit a large site. Defining your site's conditions first makes it easier to choose which reference topologies to examine.

Compare two offices with the same headcount. Different downtime limits can lead to different choices between spare equipment and an alternate path kept ready for use.

What do campus, WAN, and data center mean in Cisco's designs? ↑

First, identify which part of the network you are designing. A network connecting office users, a network linking distant sites, and a network connecting servers and applications may join together, but they do not solve the same problems.

The campus LAN discussed here connects employees' PCs, phones, and wireless endpoints to business services within an office or corporate site. Campus does not mean only a university or a large property. It can range from a small office to a multibuilding site, with a design suited to its size and business needs.

A WAN connects geographically separate sites or service locations. A branch user accessing a headquarters server may cross the branch access network, the intersite connection, and the headquarters service segment. Label the Internet-edge router separately from the campus core: they have different jobs.

Data center design separately addresses connectivity, policy, and availability for applications and servers. A data center spine-leaf fabric and a campus core differ in purpose and connectivity; they are not interchangeable structures. The enterprise function-placement diagram is a starting point for understanding the whole network. Use each area's official guide to distinguish its actual architecture.

For example, draw a line from PC-A to App-S, then mark the access network and the external service segment. Authentication and security needed for the request may span these boundaries. Recording each segment's functions and where the segments connect helps distinguish the uses of designs found in Cisco's documentation.

Follow the path from PC-A to App-S to identify the campus, WAN, and data center segments. Authentication and policy can apply across them.

One, two, or three tiers describe roles, not device counts ↑

The number of campus tiers describes how access, aggregation, and forwarding between blocks are arranged. It is neither the total number of switches, APs, and firewalls, nor a count of OSI L2 and L3 layers.

A single-tier design has no dedicated aggregation tier: one access tier provides the site's LAN. Multiple physical devices, such as a switch stack, can still provide one logical access tier. By contrast, SOHO describes a small-office environment. It can describe a one-router example, but it is not Cisco's name for an official zero-tier design.

When multiple access groups feed into distribution without a separate core, the design can be described as two-tier. Combining aggregation and central forwarding in that upper tier is called a collapsed core. Having two devices share the upper-tier role does not add another tier.

Separating forwarding between distribution blocks into a core creates a three-tier design. This is not an automatic step whenever the building count grows. Compare where traffic converges and which areas can tolerate an interruption during a failure or maintenance. Along with the ability to manage the separated devices, these factors determine whether a core is needed.

L2 access and routed access are a separate design choice within that structure: how far to extend a VLAN and where to route. A two-tier design can use either L2 or L3 uplinks. Mark the gateway, VLAN boundaries, and routing links separately alongside the tier diagram. When a packet is forwarded, whose MAC address is used? Three boxes alone cannot answer that.

The upper part compares how many tiers separate access, aggregation, and forwarding between blocks. The lower part separately shows how far VLANs extend and where routing begins within those tiers.

Specify the required communication and acceptable downtime ↑

Requirements become useful for design when they state who must communicate with what, and which failures are acceptable. Saying a network must be fast and reliable is not enough to choose ports or paths.

Consider a business endpoint, PC-A, using an HTTPS service on business server App-S. Go beyond the request path: check name resolution, authentication, and the return path. If one button click triggers several services in sequence, record which services must be working first.

Do not size capacity by the circuit's advertised speed alone. Investigate how many endpoints send data at once and at what times, and how file transfers overlap with short transaction requests. Label unobserved values as assumptions, not measurements. Record how each assumption will be checked and who will check it.

Failure conditions need more detail than a generic device failure. Record what happens when an uplink, a switch, or a power circuit fails: which endpoints are affected and how much capacity remains. If both devices use one power circuit, also consider a circuit failure that stops them together.

Business owners define the desired result; the designer identifies the communication conditions needed to achieve it. For example, increasing circuit bandwidth alone cannot fix a server that cannot process requests. Once the business goal is clear, document which problems the network must solve and which belong to the server or application.

Security and management needs are communication requirements too. If guest endpoints must not reach business servers, specify the enforcement point and how to test it. If administrators must reach devices during a production-network outage, decide whether a separate management path is needed. Defining a test for every requirement helps expose design gaps.

The diagram below maps business requirements into connections. Adding name resolution, authentication, and management access to the round-trip path between PC-A and App-S exposes dependencies that a device-placement diagram can miss.

Check the conditions behind Cisco's validated designs first ↑

When using Cisco Validated documentation, first read what use case and configuration were validated. To apply it to your network, check that your hardware, software, and business conditions fit that configuration.

Distinguish the document's target use case, topology, hardware/software combination, and tested feature scope. A statement that a feature is supported is not the same evidence as a test of a particular combination. If your hardware or software differs, record which assumptions no longer hold.

Older documents can still explain campus LAN roles. However, do not copy the product list or performance figures from the 2020 Campus LAN guide cited here into today's purchasing criteria. Separate the reasons for dividing tiers from the implementation of that period, and consult current product documentation when selecting equipment.

If a reference design exceeds your needs, there is no reason to copy every device. If it falls short, do not omit functions you need. Adding a separate core to a site that access alone can serve requires an additional role, such as forwarding capacity or limiting the change domain. Conversely, if that role is needed, consider separation even with few users.

Record the reference document's publication date in the design record. An older document may explain why roles are separated, but its device limits and software support cannot be assumed to apply today. Treat architectural reasoning and verification of support for an actual product combination as separate tasks.

Clearly distinguish information from official documentation from the examples created for this article. Following Cisco's recommended roles does not mean Cisco validated the author's example. Recording the recommendation used, the conditions that differ, and the tests you must perform preserves the reason for choosing the design.

Trace each requirement through the design to a test ↑

Design decisions should be traceable from requirements to diagrams, then from diagrams to verification. That link lets you reconsider what must remain true even when the equipment changes.

Suppose requirement R-01 states that, even if one uplink fails, PC-A must complete a test transaction with App-S within the allowed time. The HLD, or high-level design, shows two paths and the extent of failure impact. Even before port numbers are assigned, it must show which path carries communication when a particular link fails.

The detailed design, or LLD, maps those two paths to actual ports, addresses, VLANs, routing, and policies. Two lines on a diagram do not show how far a VLAN extends or where the gateway sits. Record the values for normal and failed states so the implementation team can reproduce the design intent.

Build test T-01 by returning to R-01. Specify which link will be interrupted and under what conditions, where to observe packets, which business task will demonstrate recovery, and how to roll back if the allowed time is exceeded. Agree on that time from business needs and the test method, not a product's advertised figure.

Briefly record why other options were rejected. If spare-device replacement is chosen over always-on redundancy, document acceptable downtime and the feasibility of restoration, not just cost. When the business changes, you can identify the assumption that no longer holds and revisit the decision.

Shared identifiers across requirements, diagrams, configuration, and tests also reveal untested areas. Disconnecting an uplink does not test power failure or firewall session failover. Separate tested failures from untested ones so operators can judge the verified recovery scope.

This diagram traces R-01 through the design and configuration to T-01. If operating conditions change, return to the same requirement and review the design and test together.

Recheck design assumptions during operation ↑

After deployment, keep using the design documents as the operational baseline. If observations differ from the original assumptions, identify the changed requirement before adding equipment.

If PC-A's work changes from simple lookups to large uploads, uplink demand changes even with the same endpoint count. Recording only average utilization can miss brief congestion. Comparing assumed concurrency with observations by time of day provides a starting point for investigating capacity or other causes.

Add new guest Wi-Fi and remote access to the existing diagrams. Check whether a new connection bypasses the business network's security boundary or makes management access depend on a common failure source again. Without updated diagrams and responsibility lists, operators may misread paths and policies that have already changed when an outage occurs.

Treat the upcoming examples as options to apply where needed, not steps from smaller to larger equipment. They may suggest adding only an alternate path at a small site or reducing unnecessary VLAN extension at a complex one. Review each topology by the functions to separate, capacity adequacy, and the extent of interruption when something fails.

Compare operational problems with the original requirements and feed the findings back into the design. If restoration took longer than expected, review spare-equipment location and management access as well as equipment selection. Identify the failure and the stage that took too long so the next design change addresses the actual problem.

Next, we'll examine the roles of access, distribution, and core along real communication paths. From small-office designs, we'll work through addressing, capacity, failure domains, and L2/L3 boundaries, then tiers and redundancy connecting multiple wiring closets and buildings. After the internal design, we'll cover branch, cloud, and Internet connectivity. The final part addresses security, validation, and incident recovery.