Design Fundamentals and Methodology
Start with requirements, not boxes
Every credible design begins with a documented requirements-gathering phase: business drivers (growth, compliance, cost), technical requirements (capacity, availability, latency), and constraints (budget, legacy gear, physical plant). A candidate must distinguish functional requirements (what the network must do) from non-functional requirements (how well it must do it - availability targets, throughput, convergence time).
The methodology
Know the classic ordered lifecycle: assess/collect requirements → analyze → design → implement → validate/verify → monitor and optimize. Design documents typically include a logical topology, an addressing plan, a physical topology, a bill of materials, and a migration plan. A high-level design (HLD) states architecture and services; a low-level design (LLD) specifies ports, VLANs, IPs, and configurations.
Traps to watch
- Questions that invert the order: validation does not precede design, and monitoring is not a one-time phase.
- Confusing availability (uptime, often expressed in nines) with resiliency (ability to absorb failure). 99.9% is ~8.76 hours/year; 99.99% is ~52.6 minutes/year.
- Treating a vendor product as a requirement. Requirements are vendor-neutral until the design phase.
- Ignoring scalability headroom - design to a stated growth horizon (commonly 3–5 years), not to today's peak.
Rule of thumb
For any design question, ask: which phase am I in, and what artifact does that phase produce? If the answer choices describe outputs (addressing plan, BOM, test plan), the phase is usually identifiable. A worked example: a customer says "we need 99.99% uptime for the data center." That is a non-functional availability requirement; it drives dual-homed uplinks, redundant power, and fast-convergence routing - not a specific switch model. Choose the answer that traces requirement to design decision.