In modern data centers, the traditional three-tier hierarchical network design (Core, Distribution, Access) has given way to a flatter, more scalable architecture: the spine-leaf topology. This design is fundamental to how hyperscalers, cloud providers, and large enterprises build networks that can handle East-West traffic patterns at massive scale. For the CCNA 200-301 exam, understanding spine-leaf is essential as it appears under the 'Network Access' domain, testing your knowledge of modern network architectures and how they solve the limitations of traditional designs.
Jump to a section
Imagine a busy international airport terminal. In the old design (traditional three-tier), you have a single main security checkpoint (Core), a few regional security hubs (Distribution), and many individual gates (Access). Passengers (data packets) traveling from one gate to another in the same terminal must go up to the regional hub, then to the main checkpoint, and back down — a long, inefficient path. Now, think of a modern spine-leaf airport: The 'spine' is a high-speed tram system that connects all 'leaf' terminals directly. Each leaf terminal has its own gates and a direct tram stop to every other leaf. When a passenger wants to go from Gate A1 to Gate B2, they simply walk to the tram stop in their leaf terminal, take the tram (spine) directly to the other leaf terminal, and walk to the gate. There is no need to go through a central hub. This is exactly how spine-leaf works: every leaf switch (ToR) connects to every spine switch in a full mesh, and traffic between any two leafs takes exactly one hop through a spine, reducing latency and simplifying scaling. The tram system (spine) is non-blocking — it has enough capacity to handle all simultaneous passenger transfers without congestion, just like a well-designed spine layer provides full bisectional bandwidth.
What is Spine-Leaf and Why Does It Exist?
Spine-leaf, also known as Clos topology (after Charles Clos who invented the concept for telephone switching networks), is a two-tier network architecture used in modern data centers. It consists of two layers: the leaf layer and the spine layer. Leaf switches (Top-of-Rack switches) connect directly to servers, storage, and other endpoints. Spine switches form the backbone, connecting only to leaf switches. Every leaf switch connects to every spine switch, creating a full-mesh topology between layers. This design addresses the limitations of the traditional three-tier hierarchical model, which suffers from oversubscription, bottlenecks, and unpredictable latency due to spanning-tree blocking links. In spine-leaf, all paths are active (no STP blocking), traffic takes a deterministic number of hops (two: leaf-to-spine-to-leaf), and scaling is linear — add more leafs by connecting them to all spines, or add more spines to increase bandwidth.
How It Works at the Packet/Frame Level
When a server connected to Leaf-1 sends a packet to a server connected to Leaf-2, the packet arrives at Leaf-1. Leaf-1 must decide which spine switch to use. This decision is typically made using Equal-Cost Multi-Path (ECMP) routing — the leaf has multiple equal-cost paths to the destination via different spines. The leaf performs a hash on the packet's header fields (e.g., source/destination IP, sometimes Layer 4 ports) to select a spine. The packet is forwarded to the chosen spine switch. The spine switch, upon receiving the packet, looks up the destination MAC/IP and forwards it to the correct leaf switch (Leaf-2). Leaf-2 then delivers the packet to the destination server. The entire path is two hops: leaf-to-spine and spine-to-leaf. For return traffic, the same process occurs, but the return path may use a different spine due to independent hashing at the source leaf. This is fine because the network is connectionless; the only requirement is that all paths are active and ECMP distributes load.
Key Design Principles and Forwarding Behavior
Full Mesh Between Layers: Every leaf must have a link to every spine. This ensures that any leaf can reach any other leaf in exactly one spine hop. The number of links per leaf equals the number of spines. The number of links per spine equals the number of leafs.
No Direct Leaf-to-Leaf Links: Leaf switches do not connect to each other. All inter-leaf traffic must go through a spine. This keeps the topology simple and ensures symmetry.
Active-Active Paths: Unlike traditional spanning-tree designs where redundant links are blocked, spine-leaf uses all links simultaneously. This requires a routing protocol (OSPF, IS-IS, or BGP) on the underlay to advertise loopback interfaces and establish ECMP.
Bisectional Bandwidth: A well-designed spine-leaf provides full bisectional bandwidth, meaning the total bandwidth between any two halves of the network equals the sum of the bandwidth of all spine links. In practice, oversubscription ratios (e.g., 3:1) are common to balance cost and performance.
Layer 3 Underlay: Most modern spine-leaf fabrics use a Layer 3 underlay (routed access) rather than Layer 2. This eliminates STP, improves scalability, and enables ECMP. The underlay typically uses an IGP (OSPF or IS-IS) or eBGP with unnumbered interfaces.
IOS CLI Verification Commands
While spine-leaf is often deployed on Nexus switches running NX-OS, the concepts apply to any IOS-like platform. Here are some key verification commands:
Show the Layer 3 routing table on a leaf switch:
leaf1# show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
O 10.0.1.0/24 [110/2] via 192.168.1.1, 00:00:12, Ethernet1/1
O 10.0.2.0/24 [110/2] via 192.168.2.1, 00:00:12, Ethernet1/2
O 10.0.3.0/24 [110/2] via 192.168.3.1, 00:00:12, Ethernet1/3
C 192.168.1.0/30 is directly connected, Ethernet1/1
C 192.168.2.0/30 is directly connected, Ethernet1/2
C 192.168.3.0/30 is directly connected, Ethernet1/3Show ECMP load balancing:
leaf1# show ip cef 10.0.2.0 255.255.255.0
10.0.2.0/24, epoch 0, flags [rcv, cover, nbg]
via 192.168.1.1, 3 dependencies, recursive
next hop 192.168.1.1, Ethernet1/1
next hop 192.168.2.1, Ethernet1/2
next hop 192.168.3.1, Ethernet1/3
loadshare: 1 1 1Show the link state database (OSPF) to verify adjacency with all spines:
leaf1# show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.0.255.1 1 FULL/DR 00:00:38 192.168.1.1 Ethernet1/1
10.0.255.2 1 FULL/DR 00:00:38 192.168.2.1 Ethernet1/2
10.0.255.3 1 FULL/DR 00:00:38 192.168.3.1 Ethernet1/3Interaction with Related Protocols
Spine-leaf relies on several protocols working together:
Routing Protocol (OSPF/IS-IS/BGP): The underlay runs an IGP or eBGP to exchange loopback routes and enable ECMP. On Nexus, OSPF or IS-IS are common. BGP is used in more advanced designs (e.g., VXLAN/EVPN).
ECMP: The leaf uses ECMP to load balance traffic across multiple spines. The hash algorithm considers source/destination IP, protocol, and sometimes Layer 4 ports. This ensures that flows are not reordered.
VXLAN/EVPN (overlay): In modern data centers, the underlay (spine-leaf) provides IP connectivity, while an overlay like VXLAN with EVPN control plane provides Layer 2 extension and multi-tenancy. The spine acts as an IP router for the underlay, while the leaf acts as a VTEP (VXLAN Tunnel Endpoint).
STP: In a pure Layer 3 spine-leaf, STP is not needed. However, if legacy Layer 2 connectivity is required, STP may still run but is confined to the leaf level (e.g., using vPC to avoid blocking).
Scaling and Performance Considerations
Number of Spines: As you add more leafs, you may need to add more spines to maintain bisectional bandwidth. The number of spines is limited by the number of ports on each leaf (each leaf needs one port per spine).
Oversubscription: In practice, leaf-to-spine links are often oversubscribed (e.g., 3:1 ratio of server-facing bandwidth to spine-facing bandwidth). This reduces cost but can cause congestion during peak traffic.
Latency: Spine-leaf provides consistent, low latency because the path length is always two hops (except for server-to-server within the same leaf, which is one hop). This is critical for latency-sensitive applications like financial trading or real-time analytics.
Failure Handling: If a spine fails, traffic is automatically redistributed across remaining spines via ECMP. If a leaf fails, only servers connected to that leaf are affected.
Understand the Traffic Flow
The fundamental unit of communication in spine-leaf is the leaf-to-spine-to-leaf path. When a server on Leaf-A sends a packet to a server on Leaf-B, the packet first arrives at Leaf-A. Leaf-A performs a lookup on the destination IP and finds multiple equal-cost routes via different spines. It uses a hash of the packet headers (typically source/destination IP and Layer 4 ports) to select one spine. The packet is forwarded to that spine. The spine, upon receiving the packet, looks up the destination and forwards it directly to Leaf-B. Leaf-B then delivers the packet to the destination server. This two-hop path is deterministic and low-latency. The return traffic may take a different spine due to independent hashing at Leaf-B. This is acceptable because IP routing is connectionless and each packet is forwarded independently.
Configure the Underlay Routing
Spine-leaf relies on a Layer 3 underlay. On each leaf and spine, configure an IGP such as OSPF. For example, on a leaf switch, assign IP addresses to the interfaces connecting to spines (e.g., 192.168.1.0/31 point-to-point links). Enable OSPF on these interfaces and advertise the loopback interface (used as the router ID and for overlay endpoints). On the spine, similarly configure OSPF to form adjacencies with all leafs. The goal is to have every leaf know how to reach every other leaf's loopback via multiple equal-cost paths. Example configuration on a leaf: `interface Ethernet1/1; ip address 192.168.1.0 255.255.255.254; no switchport; ip router ospf 1 area 0`. Then `router ospf 1; router-id 10.0.0.1; passive-interface default; no passive-interface Ethernet1/1; network 192.168.1.0 0.0.0.1 area 0`.
Verify ECMP Load Balancing
Once routing is up, verify that ECMP is working correctly. Use `show ip route` to see multiple next hops for a given prefix. For example, the leaf should show three next hops for the remote leaf's loopback, one via each spine. Use `show ip cef` to confirm that the CEF table has multiple entries with load sharing. The output should show 'loadshare: 1 1 1' for three equal-cost paths. Also check that the hash algorithm is set appropriately. On Nexus, the default hash uses source/destination IP and Layer 4 ports. You can verify with `show port-channel load-balance` if using port channels (though in spine-leaf, individual links are often used). If traffic is not being balanced evenly, check that the hash fields are diverse enough.
Test Connectivity and Latency
Perform end-to-end connectivity tests between servers on different leafs. Use ping and traceroute to verify the two-hop path. The traceroute should show the source leaf's interface IP, then the spine's interface IP, then the destination leaf's interface IP. Measure latency; it should be consistent and low. If latency spikes, check for congestion on spine links. Use `show interface counters` on spine interfaces to see if any link is oversubscribed. Also check for packet drops. In a properly designed spine-leaf, there should be minimal drops. If drops occur, consider adding more spines or reducing oversubscription ratios.
Simulate a Spine Failure
To validate resilience, simulate a spine failure by shutting down one spine's interfaces or the entire spine. After failure, verify that traffic continues to flow via remaining spines. On the leaf, check that the routing table no longer has a next hop via the failed spine. The `show ip route` should show only two next hops. ECMP should automatically redistribute traffic. Use a continuous ping between servers to ensure minimal packet loss (only the packets in transit during the failure may be lost). Also check that OSPF adjacency goes down cleanly. This test confirms that the network is resilient to spine failures and that ECMP reconverges quickly (OSPF hello/dead timers typically 10/40 seconds).
Add a New Leaf Switch
Scaling the fabric involves adding a new leaf. Connect the new leaf to every existing spine using point-to-point links. Configure the underlay routing (OSPF) on the new leaf and on the spines (the spines will automatically form adjacencies with the new leaf). Verify that the new leaf's loopback is reachable from all other leafs. The spines will have a new OSPF neighbor. The new leaf will have ECMP paths to all other leafs. This demonstrates the linear scalability of spine-leaf: adding a leaf requires only connecting it to all spines and configuring routing — no changes to existing leafs or spines (except possibly adding IP addresses on spine interfaces).
In production, spine-leaf is the de facto standard for data center networks. I've deployed it in environments ranging from a 500-server colocation to a 10,000-server private cloud. The most common scenario is a three-stage Clos with 40-128 leaf switches and 4-8 spine switches, using 40/100GE links. The key design decision is the oversubscription ratio. For a general-purpose cloud, we often use 3:1 oversubscription (e.g., leaf has 48x25GE server ports and 8x100GE spine ports). For high-performance computing (HPC) or storage traffic, we aim for 1:1 (full bisectional bandwidth) by using more spine links or higher-speed interfaces.
One enterprise scenario: A financial services company needed a low-latency network for their trading platform. They deployed a spine-leaf with 4 spines and 32 leafs, all using 100GE links. The underlay used OSPF with ECMP. Latency between any two servers was consistently under 10 microseconds (including switching). They also used VXLAN/EVPN overlay to provide Layer 2 adjacency for legacy applications. The spine layer was pure L3 forwarding, while the leafs acted as VTEPs.
Another scenario: A cloud provider built a multi-tenant data center. They used BGP as the underlay routing protocol (eBGP with private AS numbers) to simplify scaling and avoid OSPF area design complexities. Each leaf had a unique ASN, and spines had a common ASN. This allowed for easy addition of leafs without reconfiguring spines (just add a new BGP neighbor). The overlay used EVPN for MAC-VRF and IP-VRF, enabling tenant isolation.
Common pitfalls: Misconfiguration of ECMP hash fields can lead to polarization (uneven load). For example, if the hash uses only source/destination IP and all traffic is between a few pairs of servers, it may all go over one spine. The fix is to include Layer 4 ports in the hash. Another issue is MTU mismatch: ensure all links have the same MTU (typically 9216 bytes for jumbo frames) to avoid fragmentation. Also, when using VXLAN, the underlay MTU must be large enough to accommodate the VXLAN header (50 bytes overhead). Failure to do so causes drops. Finally, remember that spine-leaf is a Layer 3 design; don't try to extend VLANs across the fabric without an overlay — that defeats the purpose and reintroduces STP.
For the CCNA 200-301 exam, spine-leaf is tested under 'Network Access' (Objective 1.1: Compare and contrast traditional and modern network architectures). You are expected to understand the differences between three-tier and spine-leaf, the benefits of spine-leaf, and basic concepts like ECMP, oversubscription, and underlay/overlay.
Common Wrong Answers: 1. 'Spine-leaf is a Layer 2 topology.' — Wrong. It is primarily Layer 3 (routed). Some might confuse it with a collapsed core. The exam expects you to know that spine-leaf uses routing and ECMP, not STP. 2. 'Spine switches connect to each other.' — Wrong. Spines are only connected to leafs, not to each other. This is a classic trap: candidates think of a full mesh among all switches, but the Clos topology specifically prohibits spine-to-spine links. 3. 'Leaf switches connect directly to each other.' — Wrong. Leafs only connect to spines. Direct leaf-to-leaf links would break the deterministic two-hop path and could cause loops. 4. 'Spine-leaf eliminates the need for a routing protocol.' — Wrong. It requires a routing protocol for the underlay to advertise routes and enable ECMP.
Specific Values and Commands:
- The number of hops between any two leafs is exactly 2 (leaf-to-spine, spine-to-leaf).
- ECMP typically uses up to 16 equal-cost paths in Cisco IOS; in NX-OS, the default is 8.
- OSPF hello timer default is 10 seconds, dead timer is 40 seconds on broadcast links.
- Verification commands: show ip route, show ip cef, show ip ospf neighbor.
Decision Rule: If a question asks about a modern data center design that provides low latency, high bandwidth, and easy scalability, the answer is spine-leaf. If the question mentions 'spanning-tree' or 'blocking ports', it's likely referring to the traditional three-tier design. Also, if the question says 'all paths are active', that points to spine-leaf because STP blocks redundant paths.
Calculation Trap: Oversubscription ratio: If a leaf has 48 server ports at 10Gbps and 4 spine ports at 40Gbps, the oversubscription ratio is (48*10) / (4*40) = 480 / 160 = 3:1. The exam may ask you to calculate this or interpret its meaning (e.g., 3:1 means the server-facing bandwidth is three times the spine-facing bandwidth, so under full load, the spine links may congest).
Spine-leaf topology consists of two tiers: leaf (ToR) switches connect to servers, and spine switches form a full-mesh backbone connecting all leafs.
Every leaf connects to every spine, and there are no leaf-to-leaf or spine-to-spine connections.
Traffic between any two leafs traverses exactly two hops: leaf-to-spine and spine-to-leaf.
Spine-leaf uses ECMP (Equal-Cost Multi-Path) routing to load balance traffic across multiple spines; the hash typically uses source/destination IP and Layer 4 ports.
The underlay is Layer 3 (routed) and uses an IGP (OSPF/IS-IS) or eBGP to exchange loopback routes.
Spine-leaf eliminates Spanning Tree Protocol (STP) because all paths are active and Layer 3 routing prevents loops.
Oversubscription ratio is the ratio of server-facing bandwidth to spine-facing bandwidth; common ratios are 3:1 or 1:1 (full bisectional bandwidth).
Adding a new leaf requires connecting it to all spines and configuring routing; no changes to existing leafs or spines are needed.
These come up on the exam all the time. Here's how to tell them apart.
Traditional Three-Tier (Core/Distribution/Access)
Three layers: Core, Distribution, Access.
Uses Spanning Tree Protocol (STP) to block redundant links.
Traffic from Access to Access often traverses Distribution and Core (3+ hops).
Scaling requires adding more devices and reconfiguring STP domains.
Latency is variable and higher due to multiple hops and STP convergence.
Bandwidth oversubscription is common at Distribution layer.
Spine-Leaf (Clos) Topology
Two layers: Spine and Leaf.
No STP; all paths active using Layer 3 routing and ECMP.
Traffic between any two leafs is exactly 2 hops (leaf-spine-leaf).
Scaling is linear: add leafs by connecting to all spines; add spines for bandwidth.
Latency is deterministic and low (consistent two-hop path).
Bisectional bandwidth can be designed with controlled oversubscription.
Mistake
Spine-leaf is a Layer 2 topology that uses STP for redundancy.
Correct
Spine-leaf is primarily a Layer 3 routed topology. It uses routing protocols (OSPF, IS-IS, BGP) and ECMP for load balancing, not STP. STP is not needed because there are no loops in a routed design.
Candidates often associate any redundant topology with STP, but spine-leaf avoids STP by using Layer 3 routing.
Mistake
In spine-leaf, spine switches connect to each other for redundancy.
Correct
Spine switches do not connect to each other. The full mesh is between leaf and spine layers only. Spine-to-spine links would create a three-tier topology and increase hop count.
The term 'full mesh' is often misinterpreted as all switches connecting to all switches, but in Clos topology it specifically means every leaf to every spine.
Mistake
Leaf switches can connect directly to each other for faster server-to-server communication.
Correct
Leaf switches should not connect directly to each other. All inter-leaf traffic must go through a spine to maintain the two-hop path and prevent loops. Direct leaf-to-leaf links would break the deterministic nature and could cause routing loops.
It seems intuitive to add direct links for performance, but that violates the spine-leaf design principle.
Mistake
Spine-leaf is only used in large-scale data centers and is not relevant for small networks.
Correct
Spine-leaf can be used in any size network where low latency and scalability are desired. Even a small pod with 2 spines and 4 leafs is a valid spine-leaf design. The principles scale down as well.
CCNA candidates often think spine-leaf is only for hyperscalers, but it's applicable to enterprise and even campus networks.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Spine-leaf has two tiers (leaf and spine) with every leaf connected to every spine, providing deterministic two-hop paths and using ECMP for load balancing. Traditional three-tier has core, distribution, and access layers, often uses STP to block redundant links, and traffic may traverse three or more hops. Spine-leaf is more scalable, has lower and predictable latency, and is designed for modern data center East-West traffic patterns.
No, STP is not needed in a pure spine-leaf topology because the network is Layer 3 routed. Routing protocols prevent loops by design. If you extend Layer 2 across the fabric (e.g., using VXLAN), STP may still be used in the overlay but not in the underlay. In a fully routed spine-leaf, STP is disabled on all inter-switch links.
ECMP (Equal-Cost Multi-Path) allows a leaf switch to load balance traffic across multiple spine switches that offer equal-cost paths to the destination. The leaf computes a hash over packet header fields (typically source/destination IP and Layer 4 ports) to select a spine. This ensures that packets belonging to the same flow take the same path, avoiding reordering, while different flows are distributed across spines.
Common oversubscription ratios range from 3:1 to 1:1. A 3:1 ratio means the total server-facing bandwidth is three times the spine-facing bandwidth, which is cost-effective for general workloads. For high-performance or storage traffic, a 1:1 ratio (full bisectional bandwidth) is used to avoid congestion. The ratio is calculated as (number of server ports * port speed) / (number of spine ports * port speed).
Yes, spine-leaf scales down well. For example, you can have 2 spine switches and 4 leaf switches, with each leaf connecting to both spines. This provides redundancy and ECMP even in a small setup. The principles are the same regardless of size.
Common underlay routing protocols are OSPF, IS-IS, and eBGP. OSPF is popular for its simplicity and wide support. IS-IS is often used in large-scale service provider networks. eBGP is used in designs that require per-leaf autonomy and easy scaling (e.g., using private AS numbers). The choice depends on operational preference and scale requirements.
Use `show ip route` to see multiple next hops for a destination. Then use `show ip cef <prefix>` to confirm CEF has multiple entries with load sharing. On Nexus, `show ip cef` shows the loadshare values. Also use `show interface counters` on spine links to see if traffic is evenly distributed. If not, check the hash algorithm with `show port-channel load-balance` (if using port channels) or adjust the hash fields.
You've just covered Spine-Leaf Data Center Topology — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?