Rail-optimized network topology for AI fabrics
A rail-optimized network aligns every GPU NIC to a dedicated network plane, so the collective traffic that dominates distributed training stays local instead of climbing the spine. This page explains what rail-optimized means, how it differs from rail-only and top-of-rack layouts, how far it scales on Broadcom Tomahawk 5, and how OcNOS-DC builds it on validated open hardware.
What rail-optimized means, and how it differs from rail-only
Modern GPU servers ship with 8 NICs. A rail is one NIC position taken from every server: NIC-1 from every server forms rail-1, and so on to rail-8. Rail-optimized homes each rail to its own dedicated leaf, so every server has one link into each of the 8 rail leaves. The payoff is locality: xCCL libraries schedule the dominant AllReduce inside a single rail, and because that rail is one leaf, the traffic never leaves the leaf. Only the smaller cross-rail remainder reaches the spine.
- Rail-only keeps the rail-aligned leaves but drops the spine tier, so cross-rail traffic leans on the in-server GPU scale-up domain rather than a network path. Cheaper for a handful of racks, but with no fabric route for cross-rail flows once the cluster outgrows one scale-up domain.
- Rail-optimized adds a 1:1 non-blocking spine above the rail leaves, giving cross-rail flows a real network path. It is the standard single-pod scalable unit; rail-only is the entry point below it.
Why rail-optimized matters
Distributed training is dominated by collectives such as AllReduce for gradient synchronization, run through xCCL libraries (NCCL, RCCL, oneCCL). Rail alignment puts same-rank GPUs on a shared leaf, so those collectives complete with the lowest hop count and no spine transit for the common case. That holds down tail latency, and tail latency sets the pace of a synchronous step: it finishes only when the slowest GPU finishes its exchange.
Collective locality
xCCL schedules the dominant AllReduce inside one rail. Because a rail is one leaf, that traffic stays on the leaf and never contends for spine capacity.
Lowest hop count
Same-rank GPUs share a leaf, so gradient-sync exchanges complete in the fewest hops. The spine carries only the cross-rail remainder.
Lower tail latency
A synchronous step ends when the slowest exchange ends. Keeping the hot collective off the spine trims the long tail that stalls the whole job.
Even path use
For the cross-rail traffic that does reach the spine, Dynamic Load Balancing spreads elephant flows so no single uplink becomes the hot spot.
How far a rail-optimized fabric scales
Scale is set by the switch radix and by how each 800G port maps to GPUs. On radix-64 Broadcom Tomahawk 5 (51.2 Tbps, 64×800G), the designs run from a 2-tier leaf-spine up to a 3-stage Clos, shown below. Because most collective traffic stays rail-local, the super-spine plane is sized only to the cross-pod ratio you actually need. For context, Meta has publicly described a 24,000-GPU Ethernet-based AI training cluster, which shows Ethernet fabrics operating well beyond a single pod.
2-tier, 1:1 non-blocking
Rail-optimized leaf-spine at one 800G fabric port per GPU. The standard single-pod scalable unit.
2-tier with 800G breakout
Same 2-tier design with 800G ports broken out to multiple GPU NICs for higher GPU density per switch.
Clos a 3 stadi
Add a super-spine tier above rail-optimized pods. Each pod stays 1:1 non-blocking; the super-spine sets the cross-pod ratio.
Fat-tree limit
The theoretical ceiling of the 3-stage fat-tree on this radix. Cross-pod ratio is dialed to the workload.
State dimensionando il vostro cluster? The AI Fabric Design Suite sizes a non-blocking two-tier leaf-spine pod at one fabric NIC per GPU and flags when you cross into three-tier scale. For the full topology picture, see the Topologie AI fabric reference.
The rail-optimized fabric, laid out
Each GPU server carries 8 NICs, one per rail, and each rail is its own dedicated leaf, so all 8 NICs on a server land on different leaves. AllReduce across rail-N stays inside leaf-N and never touches the spine; a 1:1 non-blocking spine carries only the cross-rail remainder. The diagram is schematic: it draws a reduced server and spine count to keep the rail alignment readable.

Componenti OcNOS: BGP-unnumbered L3 underlay, RoCEv2 lossless (PFC + ECN) on every rail leaf, DLB at the spine tier, gNMI/OpenConfig telemetry throughout. Built on HCL-listed Tomahawk 5 hardware: the Edgecore AIS800-64D and UfiSpace S9321-64E (64×800G).
Rail vs ToR: aligning the fabric to GPU ranks
The rail-versus-ToR choice is about what the fabric aligns to. A rail layout aligns each GPU rank to a network plane, so same-rank GPUs across the cluster share a leaf and the collective completes with the lowest hop count. A ToR layout aligns to the server: every NIC in one server lands on its rack switch, which is simpler to cable but forces same-rank GPUs in different racks up to the spine and back. For GPU training fabrics, where AllReduce dominates, rail alignment is the standard; ToR stays a fine choice for storage and general-purpose racks where traffic is not rank-synchronous.
| Property | Rail-optimized | Top-of-rack (ToR) |
|---|---|---|
| Alignment | Each GPU rank aligned to a network plane; NIC-N from every server homes to leaf-N. | Network aligned to the server; every NIC in a server homes to its own rack switch. |
| Collective hop count | Lowest: same-rank peers share a leaf, so intra-rail AllReduce stays on one leaf. | Higher: same-rank peers in different racks sit on different switches, so collectives cross the spine. |
| Spine pressure | Low for the dominant collective; the spine carries only the cross-rail remainder. | Higher: rank-synchronous collective traffic is pushed up to the spine. |
| Cabling | More structured: eight rails fan out from each server to eight rail leaves. | Simpler: a server's links stay within its own rack to one switch. |
| Scelta ottimale | GPU training and inference fabrics where AllReduce dominates. | Storage, CPU, and general-purpose racks where traffic is not rank-synchronous. |
How OcNOS-DC builds a rail-optimized fabric
OcNOS-DC turns HCL-listed Tomahawk 5 switches into a rail-optimized fabric with a routed underlay, a lossless RoCEv2 substrate, adaptive load balancing, and streaming telemetry. It is one system: validated hardware, the OcNOS-DC network operating system, and a single support contract with one TAC and one SLA.
BGP-unnumbered L3
A routed underlay with BGP unnumbered removes per-link address planning and spreads traffic across every rail-to-spine path with ECMP.
RoCEv2 with PFC + ECN
OcNOS-DC provides the lossless Ethernet substrate that RoCEv2 requires: PFC keeps the priority lossless and ECN marks congestion. RoCEv2 itself is the NIC transport riding on that substrate.
Dynamic Load Balancing
DLB spreads elephant flows by real-time path quality instead of a static hash, so cross-rail traffic does not pile onto one uplink. Broadcom has published that DLB lifts fabric utilization from about 55% to 90%+ on Tomahawk 4/5.
gNMI / OpenConfig
Per-path utilization and queue-depth counters stream over gNMI with OpenConfig models, so you tune the fabric with closed-loop data during cluster bring-up.
HCL-listed Tomahawk 5
Runs on validated 64×800G switches: Edgecore AIS800-64D and UfiSpace S9321-64E. Every leaf and spine here is on the OcNOS Hardware Compatibility List.
Ultra Ethernet ready
IP Infusion is a contributing member of the Ultra Ethernet Consortium, and OcNOS-DC tracks the UEC 1.0 fabric profile, so the fabric carries forward as UEC-capable NICs ship. Alignment with the profile is not a certification claim.
Rail-optimized network FAQ
What is a rail-optimized network?
What is the difference between rail-optimized and rail-only?
Rail vs ToR: which layout should an AI fabric use?
How many GPUs does a rail-optimized fabric scale to?
Does a rail-optimized network need InfiniBand?
How does OcNOS-DC implement a rail-optimized fabric?
Planning a rail-optimized GPU fabric? We'll do the port-count maths with you.
Book an Architecture Review →Design the whole AI fabric with OcNOS
From the business case to the port-count maths, pick up wherever you are in the build.
Approfondite. Portatelo con voi.
Il datasheet di prodotto e download tecnici e sintetici che vanno oltre questa pagina.
Datasheet OcNOS-DC
Specifica completa di OcNOS-DC: il set di funzionalità EVPN-VXLAN e Ethernet for AI, gli SKU software, le piattaforme hardware supportate e la guida all'ordine della soluzione.
Ottieni il datasheetOcNOS 800G Lossless AI Fabric
Fabric RoCEv2 non bloccante su spine Broadcom Tomahawk 4/5: tier di SKU, piattaforme validate e architettura di deployment.
Scarica il briefEVPN-VXLAN data center fabric
Fabric di data center leaf-spine carrier-grade: IRB simmetrico, route Type-2/Type-5 e gateway anycast distribuito.
Scarica il briefDatasheet OcNOS-DC
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
OcNOS 800G Lossless AI Fabric
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.
EVPN-VXLAN data center fabric
Modulo rapido. Il suo PDF si apre in una nuova scheda subito dopo l'invio.
✓ Apertura del suo PDF in una nuova scheda…
Se non si è aperto, utilizzi il link qui sotto.