Spine-leaf fundamentals

Traditional campus-style data centres used three tiers: access, aggregation and core, held together by spanning tree. That design was built for traffic moving north-south — from users to servers and back. Modern applications talk to each other far more than to users, so most traffic now moves east-west, server to server. Spine-leaf is the topology built for that.

The shape

• Leaf switches sit at the top of each rack and connect servers.
• Spine switches connect only to leaves — never to servers, never to each other.
• Every leaf connects to every spine.

The result: any server reaches any other server in exactly two switch hops (leaf → spine → leaf). Latency is predictable, and there is no single "core" to outgrow.

The rules that matter

1. Route, don't bridge, between leaves and spines. Use a routed underlay (OSPF, IS-IS or eBGP) so every uplink is active through ECMP, instead of half of them blocked by spanning tree.
2. Size by oversubscription. Compare a leaf's server-facing bandwidth with its uplink bandwidth. 48 × 25G down and 8 × 100G up is 1,200G : 800G, or 1.5:1. Storage and AI workloads usually need 1:1; general compute tolerates 3:1.
3. Scale out by adding spines. More spines add bandwidth for every leaf; more leaves add ports. The spine port count sets the maximum number of leaves.
4. Keep the spine layer identical. Same model, same speeds, same configuration — ECMP only works well when the paths are equal.

Where VXLAN fits

A routed fabric breaks the old "stretch a VLAN anywhere" habit. When workloads still need Layer 2 adjacency, VXLAN carries Layer 2 frames over the routed underlay, and EVPN (a BGP address family) distributes MAC and IP reachability so the fabric does not rely on flooding. A later topic in this track covers it.

Rule of thumb: if you have more than two racks of servers that talk to each other, design a spine-leaf fabric from day one. Retrofitting one later costs more than building it.