CCNA network diagrams often show a cloud symbol, two parallel uplinks, or several switch tiers without explaining which failure domain or forwarding requirement the design addresses. Cisco 200-301 v1.1 requires learners to compare two-tier and three-tier networks, spine-leaf, WAN, SOHO, on-premises and cloud models; it also includes virtualization, containers and virtual routing and forwarding (VRF). These are design concepts, not a mandate to deploy every pattern in a small lab.
A useful exam answer relates each architecture to path length, scale, fault isolation, management, and the role of the default gateway. The design must also make clear where switching ends and routing begins. The complete scope is in Cisco’s v1.1 Network Fundamentals domain.
Interpret a two-tier campus without inventing a third layer
In a two-tier or collapsed-core campus, the access layer connects user endpoints and the distribution/core layer aggregates those switches while handling routing, redundancy or policy. Many smaller enterprises can operate well with this model because there are fewer devices and hops to manage. The trade-off is that the combined distribution/core devices become important shared fault and capacity boundaries.
Imagine two distribution switches serving six access switches. Each access switch has a resilient uplink design, and VLAN default gateways live on the distribution layer. The network needs a decision about VLAN spanning and redundancy: keeping a VLAN across multiple access switches may simplify host movement but extends its Layer 2 failure domain. Routing closer to the access edge can reduce broadcast-domain scope but changes the operating model.
A network diagram is incomplete if it does not indicate which switchports are trunks, where an SVI exists, where the default gateway lives and which protocols handle an uplink failure. Inter-VLAN routing with multilayer switches shows how a multilayer switch can provide that routing boundary.
Explain when three-tier architecture adds value
A three-tier campus separates access, distribution and core. Access connects users and APs. Distribution aggregates and implements local policy or gateway services. Core emphasizes high-speed, predictable transport between distribution blocks. That separation can make fault isolation and scaling easier when an enterprise has many buildings, large numbers of users, or numerous policy domains.
It does not mean every packet must traverse exactly three devices or that the core should always enforce all security rules. Overloading the core with per-user services can undermine its role as stable transport. Conversely, making every access switch fully routed introduces more interfaces and control-plane considerations that small environments may not need.
Compare a two-tier and three-tier design using the same requirements: 20 access switches in three buildings, redundant path to shared services, and a target for failure recovery. Identify the bottleneck and blast radius of one aggregation failure in each diagram. The correct design depends on scale and resilience requirements, not on claiming the more elaborate drawing is automatically professional.
Understand spine-leaf as an east-west forwarding pattern
A spine-leaf fabric typically connects each leaf to every spine, with endpoints attached to leaves. Traffic between leaves is carried through the spine tier with relatively predictable hop count. The pattern suits data centers with substantial east-west application traffic and repeated scale-out needs. Adding leaves adds attachment capacity; adding spines can expand fabric transit capacity and resilience.
This is not the same as extending a giant Layer 2 VLAN across every server. Modern leaf-spine fabrics commonly use routed underlays and overlay constructs, but the Cisco CCNA 200-301 v1.1 requirement is a topology comparison, not mastery of advanced EVPN configuration. Be able to explain where a failed spine affects paths, why redundant spines improve availability and how distributed endpoints differ from a conventional user-access campus.
When comparing a spine-leaf design to campus three-tier, ask where application traffic goes. Server-to-server east-west communication may benefit from repeated leaf-spine paths, while a campus access design must also consider user ports, PoE, wireless clients and building wiring constraints.
Distinguish WAN, SOHO and on-premises/cloud connectivity
A WAN connects geographically separated network locations and introduces carrier, Internet, latency, routing, service-level and sometimes encryption dependencies. WAN is not a synonym for the Internet: a private carrier connection is also a WAN. A tunnel across the Internet may supply secure connectivity, but encryption, routing and underlay reachability are separate design concerns.
A SOHO environment often combines routing, switching, Wi-Fi, DHCP, address translation and stateful security into one compact device. It can be appropriate for a small site but offers different management and fault isolation from separate enterprise components. When that all-in-one device fails, several services disappear together. Label those responsibilities rather than treating the device as just “a router.”
Cloud networks retain familiar IP prefixes, security rules and routing concepts but expose them through virtual networks, gateways and managed control planes. A cloud subnet does not remove the need for correct addressing or next-hop selection. An on-premises-to-cloud connection must still account for overlapping IP space, DNS resolution, encryption where appropriate and how failover routes are chosen.
Treat endpoints, appliances and Power over Ethernet as part of the topology
A topology represents physical and logical components. Routers forward between IP networks. Layer 2 switches forward frames within VLANs; Layer 3 switches can also perform routing. Firewalls apply security policy and may provide VPN/NAT services; intrusion-prevention components inspect or act on malicious traffic. An access point handles wireless client association and connects the radio network to wired infrastructure, often with controller-based management.
Endpoints generate or consume application traffic; servers supply services; controllers coordinate policies or configuration across devices. None of these names alone reveals the exact packet path. A next-generation firewall may have a routed or transparent deployment, and an access point may be local-switching or centrally tunneled depending on architecture.
Power over Ethernet matters to physical designs because APs and IP phones may depend on the access switch’s PoE budget. A perfectly routed network cannot deliver Wi-Fi when the AP lacks power.
Compare virtual machines, containers and VRFs precisely
A virtual machine includes a guest operating system running through a hypervisor abstraction; it has virtual network interfaces attached to virtual switches, port groups or virtual networks. Containers commonly share the host kernel while isolating applications and dependencies. Their network reachability still depends on virtual interfaces, bridges, overlays or orchestrator-managed networking. Do not equate a container directly with a complete independent VM.
VRF separates IP routing tables on one network device or virtual routing environment. Two customers can use overlapping IPv4 prefixes in distinct VRFs because route lookups are performed in separate forwarding contexts. VRF separation does not inherently encrypt packets, implement authorization rules for every data path, or connect different VRFs to each other. Route leaking or inter-VRF connectivity is an additional explicit design operation.
The v1.1 blueprint calls for describing virtualization fundamentals, including server virtualization, containers and VRFs. It does not require deploying large-scale multi-tenant overlays as an entry-level configuration task. A useful exam sketch places two isolated VRF routing tables on one device and asks whether a default route in one VRF automatically serves the other. It does not.
Follow control and data planes through a controller design
Software-defined and controller-managed approaches centralize portions of policy intent and operational management, but the physical devices still forward packets. The control plane determines forwarding information and policy; the data plane forwards traffic according to installed state. Underlay refers to the transport that connects network nodes; an overlay provides a logical network on top of that transport.
Northbound interfaces generally connect a controller to higher-level applications or orchestration, while southbound interfaces connect toward managed network elements. Specific products vary, and API authentication and supported resource models matter more than memorizing a vendor marketing diagram. Controllers also create new operational dependencies: if a controller is unavailable, an already-programmed forwarding plane may continue for some duration, but policy changes, onboarding or telemetry can be affected.
Northbound REST APIs and JSON responses expose the controller or device state that an automation workflow consumes. Recognize which field expresses intended configuration and which reports observed operational state; the two may disagree during a failed change.
One helpful distinction in architecture sketches is physical redundancy versus service redundancy. Two uplinks may survive a broken cable while still depending on the same switch, power supply, gateway or carrier. Similarly, two routers providing first-hop gateway redundancy may not protect a server that has only one application instance. State which failure the design is required to survive. A good topology diagram shows the independent power, network and service boundaries that matter, not simply twice as many lines.
For wireless campuses, note that AP placement follows RF coverage and power/cabling constraints, not just logical switch hierarchy. A remote branch may also terminate management traffic or a secure WAN tunnel locally. Those choices affect where controller reachability, DHCP relay and default gateway responsibilities live, even if the branch is represented as a single cloud icon.
Choose an architecture from constraints, not vocabulary
Practice three scenarios. For a 25-person branch with three APs, decide what a SOHO-style consolidated edge can safely provide and how losing it affects users. For a medium campus, draw access, distribution and core options and mark the routed gateways, policy locations and uplink redundancy. For a data center expanding server-to-server traffic, explain what adding a leaf versus a spine accomplishes.
Then challenge each design with a failed link, failed aggregation device, overlapping IP prefix and a wireless access point that needs PoE. Ask which failures stay local and which have shared impact. A strong CCNA design answer connects an architectural label to forwarding, isolation and operations; it does not assume a named topology fixes every problem by itself.