Leaf-spine fabrics are often described as inherently resilient because every leaf can connect to multiple spines and ECMP can use parallel paths. That is a good starting property, not a complete high-availability design. The active 350-601 DCCOR v1.1 blueprint still emphasizes data-center routing, switching, VXLAN EVPN, first-hop behavior, software lifecycle, and monitoring—all of which determine whether a leaf-spine fabric actually survives the failures the business cares about.
The advantages of spine-and-leaf topology come from predictable path count and scale. East-west traffic usually crosses a leaf, a spine, and another leaf, while additional spine capacity can increase bisection bandwidth without redesigning every rack.
Availability depends on more than topology: underlay convergence, host attachment, gateway design, border redundancy, control-plane state, capacity headroom, software maintenance, power domains, and upstream services can all turn a redundant fabric into one shared failure domain. A design review should remove one dependency at a time and see whether the service—not just the route table—survives.
Define the failure objective first
Decide whether the design must survive one link, one leaf, one spine, one power feed, one rack, one border device, or an entire site.
Different objectives require different redundancy. A dual-homed server can survive a leaf failure; a single-homed appliance cannot. Two spines can survive one spine failure only if surviving links and devices have enough capacity.
Translate availability into user-visible service goals. ‘No single point of failure’ is too vague if a leaf failure still causes a 90-second application outage.
Failure objectives should also consider planned degradation. During a spine failure the application may remain available with higher latency, or a rack may lose one of two uplinks and operate near capacity. Define which degraded states are acceptable and for how long. This helps operators decide whether a partial failure is an emergency, a repair-within-hours event, or normal maintenance condition. Availability is easier to operate when the expected degraded mode is documented instead of treated as binary up/down.
ECMP works when the underlay converges cleanly
Routing protocols advertise multiple equal-cost paths and remove failed next hops when links or nodes disappear.
Convergence depends on failure detection, routing timers or BFD where used, control-plane CPU, route scale, and the stability of the remaining topology.
Test loss and flap behavior. One clean cable pull can look excellent while a marginal optic flapping repeatedly creates route churn and application instability.
Failure detection should avoid coupling every transient to a topology change. Fast BFD or aggressive routing timers can reduce outage duration and can turn brief optical or CPU disturbances into repeated convergence. Test stability under real hardware and software versions before applying the fastest possible timers. The goal is predictable application recovery, not the smallest protocol timer. One extra second of stable detection can be preferable to a network that oscillates under marginal conditions.
Host attachment is often the weakest link
Servers can connect through two leafs using vPC/MLAG, EVPN multihoming, host bonding, or other redundancy patterns depending on platform.
A single host NIC, one cable, one ToR, or a misconfigured LACP bundle can invalidate the fabric’s redundancy for that workload.
The practical role of top-of-rack switching matters because the rack edge is where highly redundant fabric design meets real server cabling and host configuration.
Host-side redundancy should be validated after operating-system or hypervisor updates. Driver changes, bonding/LACP settings, and virtual-switch upgrades can alter how links fail over even though the leaf configuration is unchanged. Include representative host configurations in network game days. Network teams often test from switch to switch and miss that the application still depends on a host bond whose active/standby behavior no longer matches the fabric design.
Surviving capacity must absorb the failure
During normal operation traffic may be balanced across two leaf uplinks, several spines, or multiple border paths.
After failure, the same demand shifts onto fewer resources. A link running at 60 percent in steady state can become overloaded when its peer fails.
Capacity planning should model degraded states. High availability that keeps links up but drives them into persistent loss or queueing does not meet the application objective.
Headroom should account for maintenance overlap. A fabric may survive one unplanned failure and not survive a second path being intentionally drained for work at the same time. Maintenance tooling should understand current redundancy and block or escalate changes that would remove the last safe path. Capacity planning and change management are therefore coupled: the system is only as redundant as the paths actually available during the maintenance window.
Control-plane redundancy should avoid hidden shared dependencies
Route reflectors, fabric controllers, DNS, NTP, authentication, telemetry collectors, and automation platforms may be shared by the forwarding fabric.
Forwarding can continue during some control-plane outages and operations can become blind or unable to change the network.
Decide which control services must be redundant, which can be temporarily unavailable, and how operators retain safe access during their outage.
Controllers and route reflectors also need recovery state. It is not enough to deploy redundant instances; operators need to know which data or configuration is synchronized, how a new node rejoins, and whether a split-brain or stale-state scenario is possible. Test control-plane recovery while forwarding continues. The business may not notice the first controller loss, making monitoring and repair of the degraded control plane especially important before the next fault.
Border and service insertion require separate HA design
Traffic leaving the fabric can depend on border leafs, firewalls, load balancers, DCI, WAN routers, or internet edges.
The leaf-spine core can be perfectly healthy while one shared border pair or stateful appliance becomes the application bottleneck.
Test route failover and stateful-session behavior together. A new path that reaches the firewall but loses session state can still interrupt users.
Stateful service insertion should test asymmetric paths caused by ECMP. Firewalls and load balancers may require session symmetry or synchronized state across peers. A routing change can send one direction through a different instance even while every route remains valid. Architecture should either preserve symmetry where required or use service designs that tolerate multipath. Application failure during network convergence is often an interaction between routing and stateful services rather than one defective component.
Maintenance is part of availability
Software upgrades, hardware replacement, optics work, and configuration change should be possible without violating the availability target.
Before maintenance, verify that the redundant path is currently healthy. A planned spine reboot becomes an outage when another spine link is already degraded.
The broader distinction between high availability and fault tolerance is useful: maintenance readiness is evidence that redundancy works operationally, not merely that duplicate boxes exist.
Maintenance readiness can be measured by how often teams postpone upgrades because redundancy is already degraded. Frequent postponement indicates a design or repair-process problem, not merely bad scheduling. Track how long the fabric spends without full redundancy and how quickly failed optics, links, or nodes are restored. High availability includes the organizational ability to repair the first fault before a second one occurs.
Telemetry should expose the degraded state
Monitor link utilization/errors, routing adjacencies, ECMP next-hop counts, host attachment, vPC/multihoming state, route counts, fabric faults, and application latency.
Create alerts for loss of redundancy even when traffic still passes. A system operating on its last path should be treated as degraded before the second failure occurs.
Fault-tolerance thinking from networked-system resilience is strongest when the first failure becomes visible and repair begins before another independent failure arrives.
Alerting should distinguish loss of redundancy from complete outage. A spine or uplink failure can be invisible to users because ECMP reroutes correctly; that is precisely when operators need an alert. Waiting for application impact throws away the safety margin redundancy was meant to provide. Dashboards should show path count, surviving capacity, peer state, and maintenance context so responders know whether the fabric is healthy, degraded, or actively failing.
A useful game day follows the service
Pick one critical application and fail a leaf uplink, a spine, a server-facing leaf, and a border path in controlled tests.
Measure packet loss, session recovery, route convergence, endpoint mobility, latency, surviving capacity, and operator detection.
The CCNP Data Center certification design standard is that high availability must be demonstrated across topology, hosts, routing, borders, capacity, operations, and monitoring. A leaf-spine diagram is resilient only when the application survives the failures the diagram claims to contain.
Game days should be repeated after meaningful architecture changes. Adding a new border, changing routing timers, introducing EVPN multihoming, or moving an application into a new rack can invalidate the last test. Keep scenarios small enough to run routinely and record measured recovery. Resilience is not a certification obtained once; it is evidence that the current fabric and current workloads still survive the current failure assumptions.
Physical diversity should be verified beyond device count. Two leafs mounted in the same rack with the same PDU, two spines sharing one line card or power domain, or redundant fiber in the same conduit can fail together. Map the failure domains the business expects to survive—power, rack, chassis, line card, optics, cabling, room, and upstream provider—and confirm that redundant paths do not converge on the same hidden dependency.
Application health checks should be integrated with network game days. A fabric can reconverge within a second while a database cluster, load balancer, or storage session requires longer to recover. Measure transaction success, queue depth, connection reset, and user-facing latency in addition to routing protocol timers. The network’s recovery objective should be the time until the service becomes usable, not the time until the final route is installed.
