Table of Contents
Introduction
In the evolution of network device management, switch stacking simplifies management by turning multiple switches into one logical device, making it a popular choice in many networks.
But as demands for reliability, scalability, and modern design grow, stacking shows clear limits.
This article explains what switch stacking is, how stacking works, its advantages and disadvantages, why Asterfusion is moving away from stacking, and alternative solutions — and shows how we address the challenges modern network designs face due to stacking.
Ⅰ. What is Switch Stacking?
Switch stacking is a technology that connects multiple physical switches via dedicated high-speed cables, virtualizing them into a single logical switch. This logical switch features a unified management IP address, a single configuration file, and shared forwarding tables (such as MAC address tables and ARP tables).
To external networks and devices, it appears as just one switch with numerous ports—greatly simplifying the network topology.
Ⅱ. How Does Stacking Work?
Switch stacking operates through three coordinated planes: Management Plane, Control Plane, and Data Plane.
When multiple switches are connected via stacking cables and powered on, the first step is Role Election. This election follows a strict sequence of priority criteria:
Compare user-configured stack priorities:
An administrator-controlled factor where higher values generally take precedence.
Compare operational status:
Switches that previously or currently served as master, or have longer stable uptime, get priority.
Compare hardware models and capabilities:
More advanced platforms with better performance and richer features win out.
Compare software versions:
Switches running more stable, newer, or specific “recommended” versions may have an advantage. However, this factor is often irrelevant since stacked devices typically require consistent software versions.
Compare MAC addresses:
The switch with the smallest MAC address prevails.
Through this sequential comparison, three roles are elected: Master, Standby, and Member.
After role election, the entire stacking system proceeds to the next phase: synchronization and steady-state operation. The following table summarizes the responsibilities of each role during this phase:
| Master | Standby | Member | |
| Configuration Synchronization | All configurations are synchronized to the Standby and Member devices.Subsequent configuration modifications are first submitted to the Master, which then synchronizes them to the Standby and Member devices. | Receive synchronized configurations. | Receive synchronized configurations. |
| Control Plane Synchronization | Run various control protocols. | The Standby device receives and synchronizes all control state information calculated by the Master in real time. | Member devices do not participate in any calculations; they only wait to receive final instructions. |
| Forwarding Plane Synchronization | The Master distributes the Forwarding Information Base (FIB) it has calculated to all member switches. | All members (Master, Standby, Member) have a globally unified and identical MAC table, ARP table, and next-hop information table. | |
| Data Flow Forwarding Behavior | Forward data according to the rules decided by the Master. Local device forwarding: If the source and destination addresses are on the same device, the device forwards the data by itself. Cross-device forwarding: If Server A is connected to SW1 and needs to access Server B connected to SW2, the data packets need to be forwarded through the stacking cables.In this process, it doesn’t matter whether the device is the Master, Standby, or Member; forwarding is performed according to the FIB. | ||
| Status Monitoring | After election, the Standby device immediately enters a “hot backup state” and maintains “real-time synchronization + state consistency” with the Master throughout. | Report local status to the Master. | |
| Stable Operation of the Entire Stack | Administrators only need to log in to the stacked devices through the Master’s IP address to view information.The forwarding of traffic within the stack is uniformly scheduled by the Master. | ||
Note: Switch stacking technology is vendor-lock-in. The election rules and algorithm details are vendor-specific. Please consult the official white papers on the vendor’s website if you wish to dive deeper.
III. Stacking Physical Topologies and Connections
There are three ways to connect stacking cables. The comparison diagrams of the three connection methods are shown below:
Daisy-Chain (Not recommended for production): It reduces cabling complexity and port usage but introduces single points of failure, where any intermediate link or node failure causes stack partition and service disruption.
Ring Topology (Recommended deployment method): It enables link redundancy through automatic daisy-chain reconfiguration during cable failures to ensure service continuity, but remains vulnerable to single points of failure requiring precise circular cabling.
Star Topology (Centralized Fabric Topology): Ultra-low latency and segregated data/control planes deliver maximum performance, but require costly hardware redundancy while creating a critical single point of failure that risks total service collapse.
Note: “High-reward, high-risk”—only used in high-end scenarios with extreme performance needs and mitigation for central node risks.
IV. Why more and more manufacturers are abandoning stacking ？
Stacking played an important role in early small- and medium-sized campus and access networks. It not only solved the problem of limited ports on a single switch, but also allowed multiple devices to operate as “one logical unit,” simplifying management while providing a certain degree of redundancy and bandwidth aggregation through stack links. In traditional campus networking scenarios, stacking was almost a standard feature.
However, as network scales continue to grow, especially in large-scale campus environments, the stacking model has gradually revealed its limitations.
- Limited scalability: Most stacks only support 2–8 devices, far from sufficient for interconnecting hundreds or thousands of switches.
- Proprietary protocols/interfaces: Stacking implementations vary across vendors, requiring proprietary ports and cables, which reduces flexibility.
- Control plane bottleneck: Typically based on a master–backup design; if the master fails, the entire stack can be affected.
- Operational complexity: Although presented as “a single device,” upgrades and fault handling often impact the entire stack.
- Poor extensibility: Once business requirements exceed the stacking limit, the network often has to be rebuilt from scratch.
For this reason, an increasing number of vendors are abandoning stacking in favor of more scalable and flexible network architectures or alternative solutions, in order to meet the demands of large-scale campuses for elasticity, reliability, and automated operations.
Stacking vs. Non-Stacking Comparison
| Why Choose Stack ? | Why Not Choose Stack ? | ||
| Feature | Remark | Feature | Remark |
| Simplified Operations | Unified management and cross-stack LAG simplify operations by enabling active-active uplinks without STP blocking. | Single Point of Failure Risk | Most critical flaw |
| Enhanced Reliability | Standby switches take over in 1–3 seconds if the master fails, enabling fast recovery and avoiding STP convergence delays. | Strict Vendor Lock-in | Same-brand/model switches, plus costly dedicated modules/cables, limiting upgrade flexibility and locking users into one vendor. |
| Seamless Scalability | “Pay-as-you-grow” model—start small, expand port density/forwarding capacity linearly by adding stack members. | Scalability Limits | Stack member counts are hard-limited (usually 4–9), failing to meet scale-out needs of cloud data centers or large enterprise networks. |
| Lower TCO（Total Cost of Ownership） | Reduced costs via single software licenses, less cabling/patch panels, and lower management complexity. | Upgrade/Maintenance Hurdles | Firmware upgrades typically need simultaneous updates for all stack switches, requiring full logical unit reboots—causing outages and complicating maintenance scheduling. |
V. Stacking vs. MC-LAG vs. LACP
This is a common source of confusion—these three technologies operate at different levels:
| Feature | Switch Stacking | MC-LAG | LACP |
| Nature | Control plane virtualization (logically a single device) | Independent control planes, coordinated forwarding planes | Link aggregation protocol (data link layer) |
| Redundancy Level | Device-level (control + data planes) | Device-level (data plane) | Link-level |
| Device Requirements | Must be same brand and series | Typically same brand | Cross-device (if MLAG-supported) |
| Configuration & Management | Single logical device (simplest) | Independent per-device configuration (more complex) | Configured on a single device |
| Typical Use Case | Access layer, small-to-medium network cores | High-reliability scenarios needing cross-device link aggregation | Port bundling on a single device |
Detailed Notes:
- Stacking vs. LACP: LACP only bundles multiple ports on a single switch and cannot provide device-level redundancy.
- Stacking vs. MLAG: MLAG enables link aggregation across two devices with independent control planes, avoiding stacking’s “single point of failure” risk and serving as a more advanced redundancy solution.
Ⅵ. Asterfusion Ditches Stacking with MC-LAG + ECMP Spine-Leaf for Future-Ready Networks
As mentioned earlier， In modern network environments, major vendors are progressively shifting away from traditional stacking architectures due to inherent limitations in scalability and operational stability. While stacking offers simplified initial deployment and streamlined day-to-day management, it falls short in delivering robust reliability, flexible scalability, and advanced operational maintainability.
To address these challenges, the industry is widely adopting Multi-Chassis Link Aggregation Group (MC-LAG) as a more resilient and scalable alternative. Standalone MC-LAG provides local Layer 2 redundancy, however, in large-scale networks with hundreds or thousands of access and aggregation switches, relying solely on MC-LAG limits horizontal scalability, increases operational complexity, and cannot support network-wide ECMP or host route synchronization. Therefore, it serves only as a transitional solution. So how does Asterfusion deliver a truly future-proof solution?
For networks pursuing superior reliability and unlimited scalability, both stacking and standalone MC-LAG are merely transitional solutions. The Spine-Leaf architecture stands as the evolutionary direction for modern Enterprise networks.
In our enterprise solution, we recommend a combination of Layer 2 MC-LAG at the access layer and Layer 3 ECMP within the Spine-Leaf architecture in Enterprise. This approach provides seamless device redundancy for servers, unmatched scalability for network traffic, simplified network operations, and future-ready support for evolving enterprise applications.
How Does the CLOS-besed Spine-Leaf Architecture Achieve Redundancy?
- No Single Point of Failure: Composed of multiple Spine and Leaf nodes. Failures of any single device or link are isolated, and traffic is seamlessly forwarded through alternative paths, ensuring zero service interruption.
- For example, if Leaf1 fails in the above diagram, traffic automatically shifts to Leaf2, which continues forwarding to Spine1.
- Multipath Forwarding: Uses ECMP (Equal-Cost Multipath Routing) to perform load balancing across all available Spine-Leaf links simultaneously, maximizing bandwidth utilization and achieving low latency and high throughput.
- True Scale-Out: Capacity and performance can be expanded simply by adding Spine or Leaf devices, completely breaking the scalability barriers of stacking technology.
- For instance, we can easily add Spine3 to expand the network, with the option to add additional Leaf nodes such as Leaf5 or Leaf6, or retain the existing Leaf layer if no extra access capacity is needed. However, a full mesh between all Leaf and Spine nodes must be maintained.
In the Layer 2 network, Asterfusion’s approach is to limit the broadcast domain to the links between Leaf nodes and their downstream devices by using ARP Proxy at the Edge. The principle is that when a Leaf node receives an ARP request from a connected device, it checks its ARP table or routing/MAC table. If the destination MAC address is present, the Leaf node immediately responds with a proxy ARP reply on behalf of the target, thereby eliminating the need for broadcast propagation, preventing broadcast storms, and enabling an all-Layer 3 network fabric.
In the Layer 3 network,
A key approach is to use BGP EVPN as the control plane protocol with VXLAN serving as the data plane protocol. This solves the problem of insufficient VLAN availability and provides the multitenant isolation required to meet modern network demands
Using ARP-To-Host, Leaf nodes learn /32 host routes and advertise them to Spine and other Leaf nodes via BGP EVPN, enabling ECMP. All devices in the network synchronize host information through routing protocols rather than relying on Layer 2 broadcasts.
Employ ECMP mechanisms to balance traffic, maximizing bandwidth utilization between Leaf and Spine links, improving overall network throughput and performance.
Use a unified eBGP to simplify the control plane design, reducing network complexity and operational overhead.
Eliminate the need for complex stacking software by relying on standard Layer 3 routing protocols, avoiding potential vulnerabilities from stacking logic, significantly enhancing system stability.
You can find the differences between the traditional stacking and Asterfusion’s solution:
| Type | Deployment | Configuration | Redundancy | Software Upgrade | Stability |
| Traditional Stack | Interconnected via dedicated stack cables | Create cluster, master-slave election, split detection | Link-level + device-level | Requires stack group reboot; service interruption | Centralized control plane; failures may propagate |
| Asterfusion’s Solution | Layer2 interconnected via MC-LAG; Layer3 uses L3 routing + ECMP | Configure MC-LAG and interconnect interfaces; routing protocol setup | Link-level + device-level | Non-disruptive to services | Independent control plane; high stability |
VII. Conclusion: How to Choose?
Choose Stacking:
Best for small-medium access/branch networks (fast deployment, easy management). But scaling exposes control plane single points of failure and limits, hindering long-term growth.
Consider MC-LAG:
Good for critical devices (servers, firewalls) – offers link redundancy, device-level reliability. Standalone mc-lag works for small, stable setups but not large traffic/multi-path needs.
Embrace Asterfusion:
It blends MC-LAG’s device-level reliability (great for linking critical gear like servers/firewalls) with Spine-Leaf’s ECMP multi-path balancing—fully using inter-switch bandwidth. With non-blocking scalability and high bandwidth, it outperforms stacking and mc-lag: fits current needs, scales for the future, and suits complex demands.
If you would like to learn more about our solution, please find additional cases below:
Asterfusion’s Open Campus Network Solution at Bohai University of Technology
Campus Network Revolution: Asterfusion Powers Global CSP Efficiency!
Asterfusion Next-Generation Campus Networks: Bye, Stacking!
Still unsure ？Contact us for technical and solution consultation.
