design-network-topology

name

design-network-topology

description

Design a campus/datacenter/branch/WAN network topology by traversing the topology decision tree (scale -> traffic pattern -> redundancy need -> topology), then return the recommended topology (collapsed-core vs 3-tier vs spine-leaf vs hub-and-spoke/SD-WAN), an IP addressing plan (summarizable, room to grow), the redundancy/failure model (HSRP/VRRP, dual-homing, MLAG), and a labelled diagram description. Reach for this when the user asks to "design the network for <site/DC>". Used by `network-architect` (primary).

Skill: design-network-topology

Invoked by: network-architect (primary).

When to invoke: "design the network for our new office/datacenter/branch"; "what topology for users / ?"; any greenfield or refresh topology question.

Output: topology recommendation + IP addressing plan + redundancy/failure model + diagram description + the trade-off named.

Procedure

1. Gather the inputs that actually drive the design — don't design in a vacuum:
   • Scale: endpoints/users now and at 3-year growth.
   • Traffic pattern: north-south (client→server/internet) vs east-west (server↔server) dominant?
   • Sites: single site, campus, multi-site WAN, hybrid-cloud?
   • Availability target: what failure must be survived (a link? a switch? a site?).
   • Constraints: budget, existing vendor, existing addressing, regulatory segmentation (PCI/OT).
2. Traverse the topology decision tree in ../../knowledge/network-topology-decision-trees.md. The short form:
   • Small site (≤ ~2 switches, north-south traffic) → collapsed-core (core+distribution combined).
   • Larger campus, many access switches → 3-tier (access / distribution / core).
   • Datacenter, east-west dominant, predictable latency → spine-leaf (CLOS), usually with VXLAN/EVPN overlay.
   • Many branches to a few hubs → hub-and-spoke, modern form SD-WAN (transport-independent, policy-driven).
3. Produce the IP addressing plan. Allocate summarizable blocks per site/role (a /16 per site, /24 per VLAN is a common starting frame); leave headroom; reserve management and point-to-point ranges; document the plan — an undocumented IP plan means the network isn't designed.
4. Specify the redundancy / failure model. First-hop redundancy (HSRP/VRRP/GLBP), link aggregation (LACP), multi-chassis (MLAG/vPC/stacking), dual-homing, and for WAN dual-transport + SD-WAN failover. State explicitly: what happens when each component dies.
5. Describe the diagram (layers, devices, links, VLANs/segments, the redundancy paths). The architect renders it; you specify it.
6. Name the trade-off and the rejected alternatives — e.g., "spine-leaf rejected for a 30-user office: east-west is negligible and collapsed-core is a fraction of the cost."

Output contract

Inputs: <scale / traffic / sites / availability / constraints>
Topology: <chosen> — because <decision-tree path>
Addressing: <summarizable plan with headroom>
Redundancy: <first-hop / link / chassis / site failure model>
Diagram: <layers + devices + links + segments described>
Trade-off: <what was chosen against and why>
Seam: <cloud VPC / interconnect parts routed to the cloud plugin>

Then emit the cross-plugin Structured Output Protocol JSON block (../../../ravenclaude-core/skills/structured-output/SKILL.md).