1. Introduction


Cloud computing, big data, and AI computing services have experienced explosive growth in recent years, driving ever-increasing demands for bandwidth throughput, elastic scalability, and low-latency interaction in data center networks. The traditional three-layer network architecture has become inadequate for large-scale distributed traffic scenarios. The Leaf-Spine architecture, derived from the Clos network model, has emerged as the core networking solution for modern data centers due to its flattened topology design. This article provides a detailed introduction to this network architecture.

2. Fundamentals of Leaf-Spine Architecture


2.1 What is Leaf-Spine Architecture?


The Leaf-Spine architecture is a flattened two-layer network topology composed of Leaf access switches and Spine core switches, designed to meet the high-throughput and low-latency requirements of data centers.

Leaf-Spine topology with Spine switches above multiple Leaf switches and server groups connected below the Leaf layer.

Leaf switches directly connect to terminal devices such as servers and storage systems, serving as access and traffic aggregation points. Their port count and speed directly determine the architecture’s port density. Spine switches, on the other hand, do not connect to terminals but instead interconnect all Leaf switches to facilitate cross-Leaf traffic forwarding.

This architecture eliminates the traditional Layer 3 aggregation layer design, adopting a full-mesh interconnection between Leaf and Spine switches to remove traffic forwarding bottlenecks while simplifying network configuration and maintenance. In practical deployments, port density planning is a critical factor in Leaf switch selection, directly impacting terminal access scale and service capacity.

2.2 CLOS Network Model

The CLOS network model, proposed by Bell Labs, is a non-blocking multi-stage interconnection architecture and serves as the theoretical foundation for Leaf-Spine architecture. It consists of input, middle, and output layers, with nodes in each layer fully interconnected. By increasing the number of middle-layer nodes, the model achieves linear scalability in network capacity, fundamentally resolving the bandwidth bottlenecks inherent in traditional architectures.

Three-stage Clos network model with input, middle, and output node groups connected through multiple crossing links.

The Leaf-Spine architecture is a simplified two-layer engineering implementation of the CLOS model, where Leaf switches correspond to the input/output layers and Spine switches represent the middle layer. Compared to the theoretical CLOS model, Leaf-Spine emphasizes oversubscription ratio control and efficient port resource utilization to accommodate asymmetric traffic patterns in data centers. The non-blocking nature of the CLOS network provides the core theoretical support for Leaf-Spine’s elastic scalability, enabling it to meet the dynamic expansion demands of data center services.

2.3 Core Advantages of Leaf-Spine Architecture

The core advantages of Leaf-Spine architecture stem from its flattened topology and CLOS model-enabled technology. Its primary advantage lies in low latency and high bandwidth. The full-mesh design ensures traffic between endpoints traverses at most two hops (Leaf→Spine→Leaf), drastically reducing transmission delays. Meanwhile, flexible bandwidth allocation between Leaf and Spine switches avoids the aggregation-layer bottlenecks of traditional architectures.

Second is exceptional scalability: Adding new Leaf switches only requires establishing links to all Spine switches without modifying existing topology. Port density upgrades directly expand terminal access capacity.

Finally, it offers simplified operations and fault isolation. The flattened structure reduces network hierarchy, easing configuration and troubleshooting. Failures of individual Leaf/Spine devices only affect localized endpoints without causing network-wide outages. Additionally, strategic oversubscription ratio planning balances resource utilization and performance, adapting to diverse data center requirements.

3. Common Data Center Network Architectures

3.1 Fat-Tree Structure

Fat-Tree is a multi-layer scalable architecture based on the Clos model, typically employing three or four tiers (access, aggregation, and core layers, with optional intermediate layers for large deployments). Its core feature is “tiered bandwidth scaling” – link bandwidth grows exponentially from access to core layers to ensure non-blocking transmission.

Fat-Tree k=4 topology showing core, aggregation, and access switch layers grouped into pods with servers at the bottom.

Port density on access layer switches directly determines terminal access scale, while link configurations in the aggregation and core layers impact overall oversubscription ratios. In large-scale data center scenarios, Fat-Tree achieves elastic scalability by adding layers and nodes. However, its multi-tier design results in higher topological complexity compared to Leaf-Spine architectures. Compared to flat Layer 2 solutions, Fat-Tree better suits hyper-scale heterogeneous data centers with complex traffic patterns.

3.2 Comparison of Advantages and Disadvantages

The fundamental distinction between Leaf-Spine and Fat-Tree architectures lies in their topological hierarchy.

Leaf-Spine excels in:

  • Ultra-low latency: Fixed two-hop forwarding (Leaf→Spine→Leaf) minimizes transmission delays.
  • Operational simplicity: Adding Leaf nodes only requires full-mesh connections to Spine layer, enabling seamless scaling without service disruption.
  • Cost efficiency: Lower hardware expenditure and simplified cabling suit mid/small-scale data centers and cloud-native environments.

Limitation: Restricted oversubscription adjustment may cause bandwidth bottlenecks under extreme traffic patterns.

Fat-Tree specializes in:

  • Bandwidth elasticity: Multi-tier bandwidth scaling achieves near-zero oversubscription or non-blocking transmission for hyperscale core services.
  • Traffic adaptability: Multi-path forwarding supports dynamic load balancing and QoS policies.

Drawbacks: Complex topology, high hardware costs, and significant configuration coordination challenges between tiers, requiring substantially more operational resources than the Leaf-Spine architecture.

3.3 Differences in Network Traffic Management

The flat topology of Leaf-Spine architecture enables simpler and more efficient traffic management. Traffic forwarding paths between endpoints are fixed at two hops, eliminating complex routing calculations and path optimization strategies. The oversubscription ratio serves as the core traffic control parameter. By matching link bandwidths between Leaf and Spine layers, the convergence ratio from the access layer to the core layer can be precisely controlled to prevent congestion. This architecture favors static traffic scheduling, making it suitable for symmetric traffic scenarios like virtual machine migration and distributed storage.

The multi-tier topology of the Fat-Tree structure requires dynamic adaptability in traffic management. Multiple forwarding paths provide redundant options for traffic scheduling, enabling real-time path optimization and load balancing based on traffic load. It also supports differentiated Quality of Service (QoS) policy deployment. However, its traffic management relies on complex routing protocols and monitoring systems, necessitating real-time monitoring of link utilization across all layers. Failure to do so may lead to localized congestion due to bandwidth mismatches between layers. This architecture is better suited for asymmetric, highly fluctuating mixed traffic scenarios.

4. Frequently Asked Questions (FAQ)


Q1: How to choose between Leaf-Spine and Fat-Tree for data center networking?


A: The selection depends on scale, traffic patterns, and cost considerations.
For small-to-medium data centers, cloud-native services, or scenarios prioritizing low operational costs, Leaf-Spine architecture is preferred. Its flat topology enables low-latency forwarding and rapid scalability.

For hyperscale environments, complex traffic patterns, or mission-critical services demanding non-blocking transmission, the Fat-Tree structure is suitable. It satisfies high throughput requirements through multi-tier bandwidth scaling, though it incurs higher hardware and operational costs.


Q2: What’s the relationship between Leaf-Spine and the Clos network model?


A: The Clos network model serves as the theoretical foundation for the Leaf-Spine architecture. The former is a three-tier non-blocking interconnection model, while the latter is a simplified engineering implementation of the former at the second layer.

The Clos model emphasizes mathematical verification of non-blocking properties, whereas the Leaf-Spine architecture prioritizes engineering implementation. By adjusting parameters such as oversubscription ratios and port density, it strikes a balance between theoretical performance and practical cost.

1. Introduction

In modern data center architectures, the deployment model of rack-level network switches directly determines system performance, operational efficiency, and scalability. Top-of-Rack (ToR) and End-of-Row (EoR) switches are two mainstream deployment solutions. ToR switches are installed directly adjacent to server racks, minimizing the connection distance between servers and switches. In contrast, EoR switches are centrally deployed at the end of cabinet rows, achieving network aggregation through unified uplinks. This article provides an in-depth comparison of ToR and EoR switches, focusing on their core differences, performance metrics, and cabling logic.

2. Core Analysis of ToR and EoR Switch Deployment Architectures

2.1 ToR Switch Deployment Architecture

A Top-of-Rack (ToR) switch is designed with the rack as an independent network unit, where the access-layer switch is deployed at the top or end of a server rack. In this architecture, each server within the rack connects to the local ToR switch via short-distance copper or fiber cables. The ToR switch then links to the data center’s aggregation or core network through uplink ports.

Each rack has its own ToR switch, with server connections routed upward inside the rack before uplink aggregation.

The core design principle of the ToR architecture is to minimize the link distance between servers and switches, reducing signal attenuation and transmission latency while enabling rack-level network isolation and independent management. This deployment model suits high-density server cluster scenarios, significantly improving intra-rack data exchange efficiency. Additionally, it allows for on-demand network expansion for individual racks without disrupting the overall data center network layout.

2.2 EoR Switch Deployment Architecture

The End-of-Row (EoR) switch deployment architecture follows a centralized network access principle, where high-performance access switches are clustered at one end of a server cabinet row. In this model, all servers within the same row connect to the EoR switch via longer horizontal cabling, which then aggregates traffic through uplinks to the core network.

Multiple racks connect through longer horizontal cables to an End-of-Row switch positioned at the end of the cabinet row.

The key advantage of the EoR architecture lies in simplified network management, as centralized deployment reduces the number of access switches, lowering both procurement costs and data center space requirements. Its cabling logic adopts standardized horizontal cable management, facilitating easier planning and maintenance by operations teams. This makes EoR ideal for moderate-density server environments that prioritize architectural simplicity and centralized control.

2.3 Core Differences Between ToR and EoR Architectures

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
Deployment ModelDistributed – Dedicated switch per rackCentralized – Shared switch per cabinet row
Connection LogicDirect server-to-switch connections (short links, low latency)Multi-rack aggregation (longer cabling, transmission loss)
Management ApproachRack-level autonomy (flexible upgrades)Centralized control (uniform policy enforcement)
ScalabilityPer-rack expansion capabilityRow-level scaling limitations
Cost StructureHigher switch count but reduced cabling costsLower switch count but increased cabling expenses
Typical Use CasesHigh-performance computing, AI/ML workloadsEnterprise data centers, storage networks

3. Key Comparisons Between ToR and EoR Deployment Architectures

3.1 Core Performance

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
PerformanceFeatures short direct links between servers and switches, minimizing latency and signal attenuation.Easily matches the bandwidth demands of high-density server clusters, making it ideal for low-latency HPC applications. Uses a centralized aggregation model, where a single switch handles traffic from multiple racks, potentially causing bandwidth bottlenecks under high concurrency.However, its simplified forwarding paths reduce network complexity. 

3.2 Deployment Efficiency

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
EfficiencySupports rack-level independence—adding a new rack only requires configuring its local ToR switch without altering the overall network topology.Fast deployment cycles and high flexibility.Requires pre-planned horizontal cabling and switch configuration across an entire row, leading to higher initial setup effort.Best suited for batch-deployment data center scenarios.

3.3 Rack Cabling Efficiency

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
Cabling EfficiencyUses short intra-rack cabling (1–3m), reducing cable clutter and eliminating the need for horizontal cable trays.Cleaner cable management with minimal interference.Relies on long horizontal cabling, where all server cables converge at the row’s end.Higher cable density, demanding precise tray capacity and routing planning.

3.4 Operational Complexity

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
Operational ComplexityEnables rack-level fault isolation—issues in one rack do not affect others, simplifying troubleshooting.A single switch failure can disrupt an entire row, requiring complex multi-rack cable tracing and increasing maintenance costs.

3.5 Deployment Costs

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
Deployment CostsHigher switch procurement costs (one per rack) but saves on cabling and tray expenses due to short links.Lower switch costs (fewer devices) but higher cabling/tray investments for long horizontal runs.

3.6 Scalability Adaptability

Comparison DimensionToR (Top-of-Rack) ArchitectureEoR (End-of-Row) Architecture
Scalability AdaptabilityHighly flexible expansion—adding servers/racks only requires upgrading the local ToR switch, without impacting other racks.Ideal for fast-evolving business needs.Limited by the central switch’s port density—scaling up often requires replacing the entire EoR switch, leading to longer lead times and cost volatility.

4. Switch Selection in Data Center Scenarios

4.1 Deployment Strategies for Different Business Scenarios

The selection between ToR (Top-of-Rack) and EoR (End-of-Row) architectures is primarily driven by specific workload requirements.

For low-latency demanding scenarios such as High-Performance Computing (HPC) and AI training clusters, the ToR architecture is the clear choice here due to its ultra-low latency characteristics. The direct server-to-switch connections minimize signal propagation delays, which is critical for tightly-coupled parallel computations. The rack-level isolation also allows for independent scaling of compute resources without disrupting the entire cluster.

For enterprise-level integrated data centers, the EoR’s centralized management model proves more effective for conventional business applications. The reduced number of access switches simplifies network operations while maintaining sufficient performance for most enterprise workloads. The standardized cabling approach also facilitates easier maintenance in environments where IT staff may have limited networking expertise.

For Edge Computing Deployments, the compact nature of ToR makes it ideal for space-constrained edge locations. Each rack operates as a self-contained unit, reducing dependencies on centralized network resources that may be unavailable in remote deployments.

4.2 Comparison of ToR and EoR Switch Deployment Scenarios

The core suitability of ToR architecture lies in high-density, highly dynamic data center environments, such as compute node zones in hyperscale cloud data centers or high-frequency trading rooms in the financial sector. These scenarios are sensitive to network latency and require frequent rack-level server expansion or reduction. ToR’s independent management capability mitigates impact on the overall network.

The EoR architecture is better suited for medium-sized data centers with organized server layouts and stable business requirements, such as non-core service rooms in government agencies or universities. These scenarios prioritize equipment cost control and operational efficiency. EoR’s centralized deployment reduces the number of access layer switches, lowering equipment procurement costs and minimizing space requirements in the equipment room. Furthermore, for scenarios prioritizing network architecture flattening and facilitating global traffic monitoring, EoR’s aggregated link design offers distinct advantages.

5. Frequently Asked Questions (FAQ)


Q: In high-density server cluster scenarios, which architecture—ToR or EoR—offers greater advantages?


A: The ToR architecture is better suited for high-density server clusters. Its rack-level distributed deployment enables short-link direct connections between servers and switches, reducing transmission latency and signal attenuation to meet high-throughput, low-latency business requirements. It also supports independent scaling per rack without impacting the overall network topology, offering significantly greater flexibility than EoR.


Q: How extensive is the impact when a switch fails in ToR and EoR architectures?


A: A ToR switch failure only affects the servers within its rack. Rapid troubleshooting is possible through rack-level isolation, preventing disruption to normal operations in other racks. As the centralized access point for an entire row of servers, an EoR switch failure causes network outages for all servers in the same row. This results in a broader impact scope and significantly increases the complexity of operational troubleshooting.