Spine-Leaf vs Three-Tier: STP Blocking and Bandwidth

The classic argument for spine-leaf is usually stated as "it scales better". The concrete mechanism is less often explained: in a three-tier design, spanning tree blocks redundant links, so a large fraction of the cabling you paid for carries no traffic at all, and east-west traffic gets tromboned up and down a hierarchy built for north-south flows. This article quantifies the differences that actually drive design decisions - bandwidth utilisation, hop count, failure behaviour and where three-tier still makes sense.

What Each Topology Optimises

• Three-tier (access, distribution/aggregation, core): designed when most traffic left the building. Loops are prevented by STP, capacity is added by scaling up boxes (bigger chassis, more line cards), and east-west traffic crosses the hierarchy.
• Spine-leaf (two-tier Clos): every leaf connects to every spine, no leaf-to-leaf or spine-to-spine links, and every endpoint is exactly two hops from every other. ECMP uses all uplinks simultaneously, and scaling happens by adding leafs (ports) or spines (bandwidth).

The Bandwidth Argument in Numbers

With four spines and layer-3 ECMP, a leaf's east-west capacity is roughly four times that of a single active uplink - and every flow that lands on a different spine avoids the blocked-link penalty entirely, because there is no blocked link.

Where Traffic Actually Matters

If 80% of your traffic is server-to-server (virtualisation, distributed storage, AI training, container east-west), a topology designed for client-to-server traffic will be the bottleneck even with generous uplink counts. That is the real justification for spine-leaf, and it is also why the migration order matters: move the workloads with heavy east-west patterns onto the fabric first.

Choosing, and Migrating

1. Small campus, north-south traffic, no automation team: three-tier or collapsed core is still the cheaper, lower-risk design. Do not build a fabric you will not operate.
2. Medium data centre with significant east-west: spine-leaf with a routed underlay, adding VXLAN when Layer 2 extension across racks is needed.
3. Large or multi-pod: spine-leaf with EVPN-VXLAN and BGP as the single control plane, super-spine tier only when you outgrow a single pod.
4. Migration path: keep the existing three-tier for north-south, introduce the fabric as a new pod, move workloads rack by rack with routing at the fabric border, and retire the old distribution layer last.

Design Rules Worth Keeping

• Use the same leaf model and harness length everywhere - mismatched port counts and speeds across leafs are the practical limit on fabric symmetry.
• Keep the underlay boring: BGP or OSPF with ECMP, no cleverness, minimal policy.
• Size the leaf-to-spine uplink against the leaf's access capacity; oversubscription is a design decision, not an accident.
• Monitor per-link ECMP utilisation - hash polarisation can silently leave one spine idle while another is saturated.

Related reading: Leaf-spine vs three-tier data center design, Spine-leaf architecture in the data center and Leaf-spine vs three-tier: 2026 design guide.

原文链接：Layer23: Spine-Leaf vs Traditional Architecture