Network Design
What this lens evaluates
Whether the topology delivers resilience, scalability, modularity, and clean addressing, converges fast enough, and can migrate from today's state - the structural heart of the design, and one of the largest domains.
The questions it forces
- Is the topology hierarchical/modular with bounded failure domains?
- Does it meet resilience/HA and convergence targets?
- Will it scale (devices, routes, sites), with sound IP addressing & summarization?
- How do we migrate from the brownfield without outage?
Core considerations
- Hierarchy & topology -> Network hierarchy and topologies.
- Resilience / convergence -> Fast convergence techniques, Factors affecting convergence, Transport resiliency, diversity, and migration, Layer 2 fault isolation and resiliency.
- Scale & addressing -> Route aggregation and summarization, Generic routing and addressing - PBR, NAT, RIB-FIB.
- Virtualization / overlays -> Overlays and BGP EVPN, Segment Routing.
- Migration -> Reference models and migration considerations.
The AI/ML angle (Exam Topics 3.2 AI network design use cases)
The AI fabric is a Network-Design problem in miniature: a non-blocking, rail-optimized CLOS (Rail-optimized CLOS topology) with the right transport (Fabric transport - Ethernet vs InfiniBand vs UEC), capacity (Bandwidth and capacity planning), and connectivity model (Connectivity models and SDN in AI fabrics).
Campus AI traffic gives the lens a number: measured agentic-AI sessions peak around ~31,000 packets per second per user, against ~15,000 for chatbot use and under 1,000 for traditional browsing - a thirty-fold step that arrives as ordinary client traffic. The design consequence is directional: AI adoption pulls investment upward - access PoE/mGig first, then distribution and core uplinks - and the right response is re-weighting the budget, not reflexively re-platforming every tier.
Design techniques and the availability trade
Four techniques structure any design: failure isolation (contain faults - e.g., stop an L2 broadcast storm crossing sites), avoid shared failure state / fate sharing (do not let independent things fail together), modularity (purpose-built building blocks reused as needs arise), and hierarchy (access -> aggregation -> distribution -> core). Guiding principles include limiting complexity and treating availability as a cost/complexity trade: availability = redundancy (standby resources) + resilience (automatic failover) + reliability (data arrives correctly and on time). As availability rises, complexity and cost rise faster - two links are simple, four can be justified, five-plus is usually diminishing returns. Right-size availability to the required level, and be ready to show a stakeholder the real cost of "never any outage." A useful quantitative rule from the same argument: each additional truly independent parallel path roughly halves the expected concurrent downtime - a rapidly diminishing return that holds only while the paths share no fate (no common conduit, power, or module) and while no stateful device on the path turns "backup available" into "sessions must rebuild". The operational corollary: a redundant pair only works if each member runs at <=50% load, so the survivor can absorb the other's share - headroom is part of the redundancy design, not an efficiency loss.
The top-down design process and life cycle
Good design is top-down: start at the upper OSI layers - applications, data flows, and requirements - and only then choose routers, switches, and media at the lower layers. The opposite, bottom-up ("connect-the-dots" - place devices and wire them up), skips requirements analysis and surfaces scalability and performance surprises after rollout; it is acceptable only when the applications and goals are already well understood and speed matters. Top-down is iterative (get the big picture first, then spiral into detail) and modular (split the problem - campus, WAN, remote-access, services - and design each module in relation to the others), and it always builds the logical design before the physical one. The work runs as a cyclical life cycle of four phases: analyse requirements (business + technical goals, then characterise the existing network and its traffic), develop the logical design, develop the physical design, and test, optimise, and document - with operational feedback looping into the next iteration. Cisco frames the same idea as PDIOO / PPDIOO (Plan - Design - Implement - Operate - Optimize, with Prepare and Retire bracketing it). The two phases designers most often skip are the bookends: validate before rollout with a prototype or pilot against written test/acceptance criteria, and document the design (requirements, the existing network, the logical and physical design, and the rationale for each choice) so the next iteration - and the operators - inherit the reasoning, not just the diagram.
State, optimization, and the cost of complexity
A useful way to reason about why the techniques above work - and what they cost - is the tradeoff between state and optimization. Control-plane state is how much the network must carry and track: the number of reachable destinations and the rate at which they change. More state means more memory, CPU, and convergence time, and larger failure domains. Optimization is how close traffic gets to its ideal path. The lever between them is information hiding (aggregation, summarization, filtering): hiding state shrinks the control plane and the failure domain but pushes traffic onto less-than-ideal paths - a cost measured as stretch, the difference between the best path and the path traffic actually takes (the summary-induced suboptimal routing in Route aggregation and summarization is exactly stretch). It also adds configuration complexity. So aggregation is never free: it trades state for stretch (and config), and the design question is which side the requirements can afford to pay. The deeper principle is that complexity is displaced, not eliminated. You cannot remove complexity from a system, only move it to where it is most manageable - simplify the control plane and you add manual configuration or an overlay; remove an interaction in one place and it reappears in another. "Keep it simple" therefore means put the complexity where the team can operate it and where it does the least harm, not pretend it can be made to vanish. Beware optimizing a single local measure of complexity: driving it down in one place forces it up somewhere else, so the right call always weighs the whole system.
Recognising the use case (and the design-failure method)
Most scenarios are one of five recurring design use cases, usually overlapping and chaining: add or replace a technology or service, merge or divest businesses, scale past an assumption, recover from a design failure, or build greenfield - a merge often becomes an add/replace which becomes a scaling problem. Naming the use case early tells you which questions matter. The one with its own method is design failure: when the business changes and the design no longer fits, root-cause it at the design level - which assumption broke - not at the implementation level - which box failed. A WAN sized for a hundred sites is not misconfigured when a merger brings a thousand; its sizing assumption died. The remedy is always split in two: a short-term mitigation you can do now (policy, QoS, TE, constraining scope) and the long-term redesign planned properly afterwards - and the exam expects you to say both.
How it shows up in a scenario
You design or critique a topology against resilience/scale/convergence requirements, then show a migration path. Think in failure domains and modules; justify redundancy by RPO/RTO from Business Strategy Design.
Tip: Scenario reflex
*Size resilience and scale to the stated tolerance, not to perfection.* If the brief says a site tolerates a six-hour outage, an unprotected single point of failure there may be acceptable - do not flag every imperfection or add redundancy the business never asked for. Match redundancy and convergence to the RPO/RTO and outage tolerance from Business Strategy Design.
Spaced repetition
How do you judge whether a single point of failure is a real problem in a scenario?
Against the stated tolerance - if the business accepts (say) a six-hour outage there, the SPOF may be acceptable; size resilience to the RPO/RTO/tolerance, not to perfection.
What four properties does the Network Design lens optimise?
Resilience/HA, scalability, modularity/hierarchy (bounded failure domains), and clean addressing/summarization - plus a viable migration path.
Why design in failure domains and modules?
To bound the blast radius of a fault and to scale/convergence-tune predictably - hierarchy makes both tractable.
The AI network-design use case is [...].
The AI network-design use case is a non-blocking rail-optimized CLOS with the right transport, capacity, and connectivity model.
Name the four network-design techniques.
Failure isolation, avoid shared failure state (fate sharing), modularity (purpose-built building blocks), and hierarchy (access/aggregation/distribution/core).
Availability decomposes into which three components?
Redundancy (standby resources), resilience (automatic failover), and reliability (data arrives correctly and on time) - and cost/complexity rise faster than availability does.
Top-down vs bottom-up network design - the difference and when each?
Top-down starts at the upper OSI layers (applications, data flows, requirements) and chooses devices/media last - requirements before technology. Bottom-up ("connect-the-dots") places devices first and skips requirements analysis, causing post-rollout scalability/performance surprises; acceptable only when goals are already well understood and speed matters.
Name the four phases of the top-down design life cycle (and the Cisco equivalent).
Analyse requirements -> develop logical design -> develop physical design -> test, optimise, and document - cyclical, with operational feedback looping back. Cisco's equivalent is PDIOO/PPDIOO (Plan-Design-Implement-Operate-Optimize, with Prepare/Retire).
In network design, what is the core tradeoff behind aggregation / information-hiding?
State vs optimization - hiding state (fewer destinations/changes) shrinks the control plane and the failure domain but increases stretch (the gap between best and actual path) and config complexity; aggregation trades state for stretch.
What is 'stretch', and what principle governs complexity overall?
Stretch = the difference between the best path and the path traffic actually takes (the cost of information-hiding). Complexity is displaced, not eliminated - you can only move it to where it's most manageable, so 'simplify' means put complexity where the team can operate it, not make it vanish.
Each additional truly independent parallel path roughly [...] the expected concurrent downtime - a rule that is void under fate sharing or when stateful devices force sessions to rebuild on failover.
Each additional truly independent parallel path roughly halves the expected concurrent downtime - a rule that is void under fate sharing or when stateful devices force sessions to rebuild on failover.
Design failure is root-caused [...] - and answered twice: a short-term mitigation now, the long-term redesign after.
Design failure is root-caused at the design level - which assumption broke - not the implementation level - and answered twice: a short-term mitigation now, the long-term redesign after.
Sources
- Cisco Live BRKENS-2500 (S. Wargo, J. Matela), Advanced Campus Network Design (2026 deck, user-supplied PDF; all 197 pages passed 2026-07-26) - agentic-AI campus traffic anchors (~31K pps) and the invest-upward direction.
- Z. Zsiga, Non-Technical Guide to the CCDE Practical v1.4 (Zigbits, 2020; user-supplied PDF, full pass 2026-07-26) - use-case taxonomy and the design-failure method (v2-era exam logistics excluded as stale).
- Cisco CCDE v3.1 Unified Exam Topics (Domain 3).
- Cisco Press, Top-Down Network Design (Oppenheimer).
- Cisco Press, The Art of Network Architecture (White & Donohue) - state/optimization/stretch and the displacement of complexity.