Leaf-Spine Data Center Cabling Architecture
Leaf-spine networks create many predictable east-west links, but physical design still depends on switch port form factors, optics, lane breakout, media, distance, redundancy and rack layout. TekRoute builds a lane-level cabling and patching plan before trunks and cassettes are ordered.
Treat components, installation and evidence as one system
Choose a supported architecture from application, capacity, environment, pathway, lifecycle and acceptance requirements—not a single part number.
Fabric, optics and rack inputs
Inventory switch models, line cards, port groups, optics, speeds, breakouts and oversubscription. Map every leaf-to-spine relationship and separate production, storage, edge and out-of-band networks.
Measure rack positions and cable paths and decide direct versus structured connectivity from scale, change frequency and operational preference. Include patch panels and mated pairs in the optical loss budget.
Growth in a fabric can arrive as a whole rack or leaf pair rather than a single port, so agree how many racks and uplinks the cabling has to absorb before anyone counts trunks. The materials list carries cassettes, jumpers, blanks, cleaning supplies and spare trunk lengths beside the optics, and those small lines hold up a turn-up.
- Leaf/spine/edge port map
- Optics and lane count
- Direct/structured choice
- Loss and growth target
Fiber trunks, patching, polarity and diversity
Choose OS2 or multimode from the supported optics, reach and lifecycle. Define base-8, base-12 or other trunk grouping from lane utilization and migration. Specify trunk gender, keying, polarity, length, pulling eye, cassette or adapter and jumper mapping.
Design A/B paths, diverse trays or managers and serviceable slack. Prevent one congested manager or shared enclosure from becoming a common failure point. Reserve practical patch and cleaning access at the intended density.
Density is where these designs fail quietly, so set a working fill below the manager’s rated capacity and route slack where it will not press against the rear of a switch. Anything offered as an equivalent part should be validated against the test limits the link has to meet, not accepted on the part number alone.
- Fiber/trunk architecture
- Polarity and breakout
- A/B physical diversity
- Rack density/service access
| Decision | Input | Output |
|---|---|---|
| Topology | Switch roles and port groups | Link schedule |
| Media | Optics, reach and lanes | Fiber/trunk selection |
| Patching | Density and change model | Panel/port map |
| Resilience | Fabric and power planes | A/B pathways |
Installation, cleaning and acceptance
Protect, inspect and clean every connector before mating. Control pulling tension, bend radius and trunk fanouts. Label at switch, panel and trunk ends using identifiers that encode fabric role without depending only on color.
Test loss, length and polarity at the required wavelengths and preserve native results. Validate lane breakouts and switch link state, errors and optical telemetry. Compare measured loss with both cabling limits and the optic budget.
Agree the wavelengths, direction and reference method before the first tester is set up, and keep the instrument’s own result files rather than a printed summary, since a later dispute gets settled from the saved measurement. A link that passes cabling limits while sitting close to the optic budget needs a name against it and a decision.
- Inspect/clean every endface
- Bend/pull/fanout control
- OLTS loss/length/polarity
- Switch optics and errors
Port records, capacity and migration control
Deliver rack elevations, switch-port-to-panel-to-port maps, trunk and module inventory, polarity, loss budgets, native tests, A/B routes and spare capacity. Reconcile records with network automation or DCIM where used.
Before migration, review new optic lane counts, connector, reach, polarity and loss. Stage harnesses and patch changes and preserve rollback maps. Retire stranded assemblies deliberately rather than leaving undocumented adapters.
Records are the migration tool here, so port maps, polarity, measured loss and spare trunk positions have to match what is physically in the racks on the day of handover. Where the client runs DCIM or automation, load the same identifiers there instead of keeping a second spreadsheet that drifts after the first change window.
- Lane-level as-built
- Native test files
- Spare capacity map
- Migration and rollback map
How we plan and deliver the work
The final design depends on site conditions, existing systems, client policies and the selected manufacturer or platform.
Count links
Total the leaf-to-spine links per rack from switch port counts, oversubscription targets and planned fabric growth.
Fix polarity
Set the polarity method, breakout plan and lane map so cassettes and trunks match the optics ordered.
Pull trunks
Install trunks and cassettes along the assigned pathways, dressing rows so uplinks stay serviceable during future adds.
Clean and certify
Inspect and clean every end face, measure loss on each lane, and match results to the fabric map.
Information to gather before design
Leaf-spine cabling scales badly when the lane map, optic type and rack layout are decided after the trunks are ordered.
- Leaf and spine port counts per rack
- Optic types and breakout requirements
- Distance from each leaf to spine
- Polarity method already used on site
- Growth racks planned for the fabric
Frequently asked questions
These are common planning questions. A site-specific answer should be confirmed during discovery and design.
Does leaf-spine require direct switch-to-switch cables?
No. Direct, interconnect and cross-connect designs are possible; choose from scale, loss and operations.
Is base-8 always required for parallel optics?
No. Match trunk grouping and migration to actual lane counts and existing infrastructure.
Why keep lane-level maps?
Breakout optics and parallel links can fail or migrate one lane at a time.
What should be tested besides fiber loss?
Polarity, length, breakout mapping, link state, errors and optical telemetry.
Manufacturer software, firmware and technical files remain on the manufacturer’s official website. We do not mirror firmware files locally.
Build a Lane-Level Plan for Your Fabric
Optics decide the trunk and cassette order, so the switch models, port counts, rack layout and planned link distances need to be on the table before anything ships. Those inputs turn into a lane map and a patching plan.