Why CLOS? The Problem with Three-Tier Networks
The traditional three-tier network architecture (Core → Aggregation → Access) served us well for decades. But as east-west traffic exploded — driven by virtualization, containerization, and distributed applications — its limitations became critical:
- Oversubscription at aggregation — traffic between access switches must traverse the aggregation layer
- Spanning Tree Protocol (STP) blocks redundant paths, wasting bandwidth
- Scaling requires forklift upgrades — bigger core switches, more expensive linecard modules
- Unpredictable latency — different paths have different hop counts
CLOS (Leaf-Spine) architecture eliminates these problems by design.
CLOS Architecture Fundamentals
In a Leaf-Spine topology:
- Every leaf switch connects to every spine switch — no blocked paths
- Maximum two hops between any two servers — predictable latency
- Adding capacity means adding spine switches — horizontal scaling
- ECMP (Equal-Cost Multi-Path) distributes traffic across all available paths
Sizing Your CLOS Fabric
The math is straightforward:
- Leaf switches: number of uplink ports to spines = number of spine switches
- Spine switches: number of downlink ports = maximum number of leaf switches
- Server ports per leaf: remaining ports after spine uplinks
Example: A leaf switch with 48 x 10G downlinks and 6 x 40G uplinks connects to 6 spine switches, supporting up to 48 servers per leaf. With 6 spine switches having 48 ports each, you can have up to 48 leaf switches — that's 2,304 server connections.
Design Principles from Real Deployments
Having designed CLOS networks for banking environments, here are the principles I follow:
1. Simulate Before You Deploy
Use EVE-NG or GNS3 to build a complete simulation of your fabric. Test:
- BGP/OSPF convergence times
- Failover behavior when a spine goes down
- Traffic distribution under load
- Configuration templates across all switches
2. Choose Your Routing Protocol
eBGP is the modern standard for CLOS fabrics:
- Each switch gets its own ASN
- Simple peering model — leaf peers with all spines
- Well-understood failure domains
- Used by hyperscalers (Facebook, Microsoft, LinkedIn)
OSPF works for smaller fabrics:
- Simpler initial configuration
- Faster convergence in smaller networks
- Consider OSPF unnumbered to reduce IP addressing complexity
3. Standardize Everything
Every leaf switch should have an identical configuration template. Every spine switch should be identical. The power of CLOS is its uniformity. Use configuration management tools from day one.
4. Plan for Day 2
- Monitoring: per-port utilization, BGP session state, ECMP hash distribution
- Automation: zero-touch provisioning for new switches
- Documentation: topology diagrams updated automatically from network state
Migration Strategy
Migrating from three-tier to CLOS without downtime requires careful planning:
- Deploy the spine layer alongside existing core switches
- Migrate access switches to leaf role one rack at a time
- Shift traffic gradually using routing metrics
- Decommission the old core only after full validation
This approach lets you run both architectures in parallel during the transition period.
Key Takeaways
CLOS isn't just for hyperscalers. Any organization with 50+ servers, significant east-west traffic, or plans to grow will benefit from Leaf-Spine architecture. The initial complexity in routing configuration pays off in operational simplicity and predictable performance.
The most important step? Start with simulation. EVE-NG gives you a risk-free environment to validate your design before a single cable is pulled.