Why 400G and 800G Optics Matter for SONiC Fabrics Now
Data center fabrics built on SONiC (Software for Open Networking in the Cloud) are accelerating past 100G. Two forces drive the shift to 400G and 800G uplinks: AI/ML training clusters that demand low-latency, high-bandwidth east-west traffic, and cloud-scale spine-leaf architectures where 100G leaf-to-spine links become the bottleneck.
SONiC is an open-source network operating system based on Linux that runs on switches from multiple vendors and ASICs. It offers a full suite of network functionality, including BGP and RDMA, and has been production-hardened in the data centers of some of the largest cloud service providers. For buyers evaluating optics, SONiC’s multi-vendor support means transceiver compatibility is not locked to a single switch OEM. This is a fundamental difference from proprietary NOS environments where optics procurement is tightly coupled to vendor-approved part numbers and pricing structures.
For Australian enterprises and service providers planning AI infrastructure or data center refresh, the optics layer is where fabric performance, cost, and operational risk converge. Choosing the wrong form factor or reach type does not just waste budget — it can strand fibre investments or force a forklift upgrade when traffic scales.
400G vs 800G: Where Each Speed Fits in the Fabric
The current SONiC switching ecosystem spans multiple generations of silicon and port speeds. Understanding where 400G and 800G sit in the fabric hierarchy helps buyers match optics to the right tier.
400G (400 GbE) is the current mainstream spine-leaf interconnect for enterprise and mid-scale data centers. It typically uses QSFP-DD form factor transceivers. Spine switches aggregate 400G links from multiple leaf switches, and leaf switches connect to servers at 25G or 100G access ports. For SONiC fabrics, 400G offers broad ASIC and transceiver availability, a mature supply chain, and competitive pricing.
800G (800 GbE) is the emerging high-performance tier, targeting AI training backends, GPU clusters, and hyperscale leaf tiers. It uses the OSFP form factor, which is physically larger than QSFP-DD to accommodate higher power dissipation. Some next-generation switches also introduce co-packaged optics, where the optical engine sits on the switch silicon substrate rather than in a pluggable module.
The table below summarizes the key differences:
| Attribute | 400G | 800G |
|---|---|---|
| Dominant form factor | QSFP-DD | OSFP |
| Typical use case | Spine-leaf uplinks, aggregation | AI backend fabric, GPU interconnect, high-density spine |
| Transceiver maturity | Mature, broad availability | Emerging, limited supplier base |
| Power per port | 8-12W typical | 14-20W typical |
| SONiC support breadth | Wide multi-vendor support | Growing, check ASIC and platform compatibility |
| Price per port (indicative) | Lower, economies of scale | Higher, fewer suppliers |
For many data center operators, a staged approach makes sense: deploy 400G today for spine-leaf and aggregation, and introduce 800G at the AI backend tier where GPU-to-GPU bandwidth is the primary constraint.
Transceiver Form Factors: QSFP-DD, OSFP, and Co-Packaged Optics
Form factor selection is the first physical decision buyers face. It determines not just the transceiver you buy, but the switch platforms, cable plant, and future upgrade path.
QSFP-DD (Quad Small Form Factor Pluggable Double Density) is the workhorse for 400G. It is backward-compatible with QSFP28 and QSFP56 modules in many platforms, allowing incremental upgrades from 100G to 400G without replacing all cabling infrastructure. QSFP-DD supports up to 400G in a compact, hot-pluggable module. Power dissipation is generally in the 8-12W range, making it compatible with standard switch faceplate cooling.
OSFP (Octal Small Form Factor Pluggable) is designed for 800G and above. It is slightly larger than QSFP-DD and supports higher power envelopes of up to 20W or more. OSFP modules can also operate at 400G in some configurations, but the primary target is 800G. OSFP includes an integrated heat sink, which is necessary for the thermal demands of 800G signaling.
Co-Packaged Optics (CPO) represent a longer-term shift where optical engines are integrated onto the switch ASIC package. This eliminates the pluggable module boundary entirely. For example, some next-generation platforms use co-packaged optical connectors that deliver significantly higher port density and improved power efficiency compared to pluggable optics. CPO is still early-stage for most buyers and primarily relevant for hyperscale AI fabric deployments planning beyond 800G. For enterprise SONiC fabric buyers in Australia today, QSFP-DD and OSFP are the practical choices.
Reach Types: Matching the Transceiver to Your Fibre Plant
Within each form factor, transceivers are classified by reach. Choosing the wrong reach type means either paying too much for short links or failing to light up long runs.
| Reach Code | Typical Distance | Fibre Type | Common Use Case |
|---|---|---|---|
| SR4 / SR8 | Up to 100m | Multimode (OM3/OM4) | In-rack, adjacent rack, same row |
| DR4 / DR8 | Up to 500m | Single-mode (OS2) | Building-level, cross-facility |
| FR4 | Up to 2km | Single-mode (OS2) | Campus interconnect, metro-adjacent |
| LR4 | Up to 10km | Single-mode (OS2) | Inter-building, metro |
| ER4 | Up to 40km | Single-mode (OS2) | Long-haul metro, DCI |
For SONiC spine-leaf fabrics, the most common optics are:
- SR4/SR8 (multimode) for in-rack leaf-to-server and adjacent-rack leaf-to-spine links where runs are under 100m. Multimode fibre is cheaper to terminate and more forgiving of connector quality.
- DR4/DR8 (single-mode, 500m) for spine-to-spine and leaf-to-spine links across the data hall. This is the sweet spot for most mid-to-large data centers.
- FR4 (single-mode, 2km) when the fabric extends beyond a single building or across a campus.
A common mistake is deploying single-mode transceivers everywhere because it seems more future-proof. In practice, multimode SR optics for short-reach, high-density connections deliver a lower total cost of ownership because multimode patch panels and patch cords are significantly cheaper.
AI Fabric Requirements: Why Optics Choice Affects RoCE Performance
AI and ML training workloads are uniquely sensitive to network latency and congestion. When GPU nodes communicate over RoCE v2 (RDMA over Converged Ethernet), the optical transceiver layer is not just a passive pipe — it directly affects tail latency, link flaps, and congestion behavior.
Key optics-related considerations for AI fabrics:
-
Consistent transceiver quality: Mixed-vendor transceiver ecosystems can introduce subtle timing differences. For RoCE v2 flows, inconsistent transceiver behavior can contribute to microbursts and tail latency spikes. Standardising on a tested transceiver family across the AI fabric reduces this risk.
-
Power and thermal management: 800G OSFP modules draw more power than 400G QSFP-DD. In dense AI leaf switches with 64 or more ports, aggregate transceiver power can exceed 1kW. Verify that the switch platform’s cooling design supports the chosen optics at full port density.
-
Forward Error Correction (FEC): Both 400G and 800G links use FEC (typically RS-544 for 400G). FEC adds latency in the range of 100-200 nanoseconds. For latency-sensitive AI fabric paths, understand that transceiver choice constrains your FEC mode options.
-
Breakout configurations: Many AI leaf switches use 800G ports broken out to 2x 400G or 4x 200G for connecting to GPU server NICs. The transceiver must support the specific breakout mode the switch ASIC and SONiC software expect.
For SONiC-based AI fabrics, aligning optics choice with the RoCE v2 and DCBX configuration ensures that the physical layer does not become the hidden bottleneck in GPU cluster performance.
SONiC Transceiver Compatibility: What to Verify Before You Buy
SONiC’s multi-vendor architecture is a major buyer advantage, but it does not mean every transceiver works on every platform. Before committing to an optics purchase, verify the following:
1. Switch platform transceiver support list: Each switch OEM that ships SONiC-compatible hardware maintains a tested transceiver list. This is typically documented in the platform’s hardware compatibility matrix. Purchasing outside this list does not necessarily mean the optics will not work, but it means you are in unsupported territory if issues arise.
2. SONiC firmware and optics firmware alignment: Transceiver modules contain their own firmware for DOM (digital optical monitoring), temperature reporting, and power management. Ensure that the SONiC version on your switch supports the optics firmware revision. Mismatches can cause false alarms, missing telemetry, or link instability.
3. Third-party vs OEM transceivers: The SONiC ecosystem supports third-party transceivers more broadly than proprietary NOS environments, since SONiC does not enforce vendor lock-in at the optics level by default. However, not all third-party modules are equal. Verify that the transceiver vendor provides DOM data in the format SONiC expects and that the module’s power class is within the switch port’s specification.
4. DOM and telemetry integration: SONiC’s containerized architecture exposes transceiver DOM data (temperature, voltage, TX/RX power) through standard Linux interfaces and NETCONF/YANG models. For operational teams using telemetry pipelines, confirm that the chosen optics report all expected DOM parameters consistently.
This verification step is where open networking buyers have a structural advantage: because SONiC decouples hardware from software, you can test optics across multiple switch platforms without re-licensing or re-architecting the NOS.
Related xSONiC Resources
Sources Reviewed
- Switch to new Outlook for Windows - Microsoft Support: https://support.microsoft.com/en-us/office/switch-to-new-outlook-for-windows-f5fb9e26-af7c-4976-9274-61c6428344e7
- Supports: input source for finding, recommendation, claim, and evidence review.
- SONiC Foundation: https://sonicfoundation.dev/
- Supports: input source for finding, recommendation, claim, and evidence review.
- SONiC GitHub: https://github.com/sonic-net/SONiC
- Supports: input source for finding, recommendation, claim, and evidence review.
- Azure SONiC Documentation: https://azure.github.io/SONiC
- Supports: input source for finding, recommendation, claim, and evidence review.
- Open Compute Networking: https://www.opencompute.org/projects/networking
- Supports: input source for finding, recommendation, claim, and evidence review.
- Broadcom Ethernet Switching: https://www.broadcom.com/products/ethernet-connectivity/switching
- Supports: input source for finding, recommendation, claim, and evidence review.
- Marvell Switching: https://www.marvell.com/products/switching.html
- Supports: input source for finding, recommendation, claim, and evidence review.
- NVIDIA Ethernet Switching: https://www.nvidia.com/en-us/networking/ethernet-switching
- Supports: input source for finding, recommendation, claim, and evidence review.