Mental model
Classic campus networks are three-tier: access → distribution → core. That model was optimised for north-south traffic — users at the access edge talking to servers or the internet, which sat at or beyond the core. Modern applications flipped it: microservices, virtualisation, container orchestration, and big-data workloads generate huge east-west traffic (server-to-server within the same DC), and three-tier’s per-tier oversubscription makes east-west slow and unpredictable.
Spine-leaf flattens the DC to two tiers. Every leaf switch (the top-of-rack, connecting servers) is directly cabled to every spine switch (the backbone). Two servers on different racks always talk over the same two-hop path: server → leaf1 → spine → leaf2 → server. Latency is deterministic. Bandwidth is easy to scale.
The layout
Spine 1 Spine 2 Spine 3 Spine 4
│ │ │ │
┌──────┼──────┬───────┼──────┬───────┼──────┬───────┼──────┐
│ │ │ │ │ │ │ │ │
Leaf-A Leaf-B Leaf-C Leaf-D Leaf-E ...
│ │ │ │ │
servers servers servers servers servers
Rules:
- No leaf-to-leaf uplinks. All east-west goes leaf → spine → leaf.
- No spine-to-spine uplinks. Spines only forward between leaves.
- Every leaf connects to every spine. With 4 spines and 24 leaves, that’s 96 spine-leaf uplinks.
- Uniform port count on spines (so all leaves have equal reach).
Why it beats three-tier for the DC
| Property | Three-tier (core/dist/access) | Spine-leaf |
|---|---|---|
| Layers between two servers | 5 hops (worst case: access → dist → core → dist → access) | 2 hops always (leaf → spine → leaf) |
| Latency | Variable — depends on where the two servers sit | Deterministic — same for any pair |
| Scaling bandwidth | Upgrade core links (expensive, disruptive) | Add another spine (parallel, non-disruptive) |
| Scaling port count | Add distribution + access | Add another leaf |
| Spanning-Tree convergence | Central bottleneck | Rarely uses STP — routing overlays instead |
| Redundancy | Distribution-tier bottleneck if one distro fails | Any single spine or leaf can fail; all others keep forwarding |
What runs on spine-leaf in practice
- Layer 3 to the edge. Every leaf terminates an L3 boundary — no VLANs stretched across leaves. This kills classic STP problems.
- ECMP (Equal-Cost Multi-Path) routing — traffic is spread across all spines. OSPF, BGP (usually eBGP-in-the-DC), or IS-IS handle the underlay.
- VXLAN overlay — L2 segments needed by tenants are extended over the L3 fabric via VXLAN tunnels between leaves, letting VMs move between racks without renumbering.
- EVPN control plane — BGP EVPN advertises MAC/IP reachability across the overlay.
When you’d still use three-tier
- Campus networks with heavy north-south traffic (users at access edge → internet/central servers). Three-tier’s aggregation model handles this well.
- Very small deployments — a two-tier collapsed-core is often enough.
- Environments with legacy L2 requirements where the applications assume flat VLAN behaviour and can’t tolerate L3 boundaries at every rack.
The classic CCNA question
“Which topology is most common in modern data centers?” → spine-leaf.
“What kind of traffic does spine-leaf optimise for?” → east-west (server-to-server).
“How many spine switches does each leaf connect to?” → all of them (leaves fan out to every spine).
The #1 mistake
Cabling a spine-leaf like a three-tier network — adding leaf-to-leaf uplinks or spine-to-spine uplinks. This creates layer-3 forwarding loops or convergence issues and defeats the deterministic 2-hop property. The whole point is that spines never talk to each other and leaves never talk to each other directly.
Related deep-dives
- Hierarchical network design — the classic three-tier campus model
- VXLAN basics — the overlay that runs on top of the fabric
- SDN controllers — the controller model that manages large spine-leaf fabrics