A useful data center interview question is: What is a spine-leaf topology, and why use it instead of a traditional switching hierarchy? Start with the wiring and a packet path, not a list of protocols.
Short answer: spine-leaf is a two-tier fabric in which every leaf connects to every spine; endpoints connect at the leaves, while spines provide transit between them.[2]
Leaf, spine and Clos: what do the names mean?
A leaf provides endpoint access, a spine interconnects leaves, and a border leaf connects the fabric to external networks or services.[2]
The common two-tier arrangement is a folded three-stage Clos: a cross-leaf packet traverses an ingress leaf, a spine and an egress leaf, even though there are only two physical switch tiers.[1]
In the basic folded Clos, traffic crosses tiers rather than using a same-tier transit mesh.[1]
Use this fictional adjacency list to draw a small example:
Leaf-A: Spine-1, Spine-2, Server-A
Leaf-B: Spine-1, Spine-2, Server-B
Leaf-C: Spine-1, Spine-2, Server-C
Drawing exercise: put the spines above the leaves, then connect every leaf to both spines. Do not draw only one uplink per leaf. That would not represent the stated topology.
Packet flow: how does traffic cross the fabric?
Assume plain IP routing, installed destination routes and no service-chain detour. The following is an illustrative walkthrough, not a captured lab result:
- Server-A sends traffic toward Server-B through Leaf-A.
- Leaf-A chooses an eligible spine next hop.
- That spine forwards toward Leaf-B.
- Leaf-B delivers the packet to Server-B.
Selected path: Server-A -> Leaf-A -> Spine-1 -> Leaf-B -> Server-B
Alternate path: Server-A -> Leaf-A -> Spine-2 -> Leaf-B -> Server-B
ECMP supplies multiple equal-cost forwarding choices, but typical flow-based hashing does not split one flow evenly across all uplinks.[1]
For the interview, distinguish two questions: “How many alternate paths exist?” and “Which path does this particular flow use?” Do not use a single transfer as your entire capacity test.
Is spine-leaf the same as EVPN or VXLAN?
No: topology, routing and overlay services are different decisions. NVIDIA describes EVPN as BGP extensions carrying endpoint reachability and VXLAN as a transport over which EVPN-based services can operate.[2]
In NVIDIA's documented two-tier fabric, leaf VTEPs encapsulate and decapsulate VXLAN traffic, and spines transport the outer IP packets.[4]
Therefore, do not assume a spine must terminate VXLAN just because it forwards VXLAN packets.[4]
Oversubscription: a worked interview example
The topology name alone does not promise a nonblocking network; available uplink capacity and ECMP behavior matter.[1]
For this fictional sizing exercise, define oversubscription as total server-facing line rate divided by total usable uplink line rate, counting each direction consistently. Assume:
- 24 server ports at 25 Gb/s: 600 Gb/s aggregate.
- Four 100 Gb/s uplinks, one per spine: 400 Gb/s aggregate.
- Normal ratio: 600 / 400 = 1.5:1.
- After losing one spine uplink: 600 / 300 = 2:1.
These are calculated port-rate ratios, not measured application throughput. For this exercise, also assume every uplink is eligible and the switch itself is not the bottleneck. Ask whether the required workload must still fit after the failure, rather than approving the design from the healthy-state ratio alone.
Troubleshooting checklist: prove the path before blaming the overlay
Use the following as a proposed test plan, not vendor-specific command syntax:
| Check | Evidence to collect |
|---|---|
| Physical adjacency | Compare discovered neighbors against the intended leaf-to-spine cabling matrix. |
| Routing | Inspect the exact destination route and its installed next hops, not just neighbor-session status. |
| Traffic distribution | Compare counters across uplinks using multiple independent test flows. |
| Failed path | In an isolated lab or approved window, remove one uplink and record loss, recovery time and remaining capacity. |
| Overlay dependency | If using VXLAN, test remote VTEP reachability before inspecting tenant-specific forwarding. |
| Capacity | Record utilization and queue drops during the workload, including the failure test. |
In the example above, losing one spine leaves three uplinks: the design must satisfy both reachability and capacity requirements after the failure.
My suggested acceptance record has four fields: expected next-hop count, observed next-hop count, measured interruption and workload performance after failure. Keep the actual device outputs beside those fields; do not replace measurements with “redundancy works.”
Common interview pitfalls
- Two tiers versus three stages: describe which objects you are counting.[1]
- More leaves versus more bandwidth: adding leaves supplies attachment capacity; adding spine paths can increase inter-leaf capacity, subject to available ports.[2]
- Equal cost versus equal utilization: hashing can produce uneven traffic distribution.[1]
- Topology versus services: explain the physical fabric before discussing overlay tenant segmentation.[2]
A concise interview answer
“Spine-leaf connects endpoint-facing leaves through a shared spine tier, with every leaf linked to every spine.”[2]
“For traffic between different leaves, the normal path is leaf, spine, leaf; ECMP provides alternate equal-cost paths.”[1]
“I would check the uplink capacity after a spine failure, not just reachability.”
“I would also distinguish the underlay routing from any VXLAN overlay.”[4]
Related reading
- VXLAN and Overlay Networks Explained for Interviews
- BGP Unnumbered Leaf-Spine Underlay: Practical Fabric Guide
- AI-Ready Leaf-Spine Network: Small GPU Cluster Design
Preparing for a network engineering interview? Draw the example without notes, explain the selected path, then recalculate capacity after one failure. Practice stating your assumptions before giving the answer.
Post a Comment