Global Data Center Deployment Checklist for SONiC Fabrics

data centerSONiCdeployment checklistglobal export

In brief

A global data center deployment checklist for SONiC fabrics covering topology, optics, telemetry, rollback, acceptance evidence, handover, and export screening.

Key takeaways

A global data center deployment checklist for SONiC fabrics covering topology, optics, telemetry, rollback, acceptance evidence, handover, and export screening.

A global SONiC fabric deployment should be released through a checklist that covers topology, ports, optics, NOS version, telemetry, rollback, acceptance evidence, handover, and export screening. The first review should name spine and leaf count, port speeds such as 100G/400G/800G, optics reach, management interface, gNMI or SNMP telemetry, config source of truth, 1 representative traffic check, 1 rollback check, destination, end user, and end use.

If the checklist cannot be filled in, the project is not ready for volume order. It may still be ready for architecture review, but not for procurement closure.

Start with the deployment boundary

Define what the fabric must do. A data center leaf-spine fabric for general workloads, an AI Ethernet fabric, a storage network, and a packet visibility layer all use switches, optics, telemetry, and automation, but they fail in different ways. The deployment boundary should name workloads, port roles, oversubscription, failure tolerance, operational owner, and acceptance method.

For global buyers, include the commercial and compliance boundary at the same time. Destination country, end user, end use, delivery terms, documentation language, and support model should be visible before order release. xSONiC’s Australian-made deployment positioning is strongest when this complete scope is documented: qualified global components, Australian architecture review, validation planning, documentation, and commercial accountability.

Do not treat export wording as a footer. It belongs in the same checklist as topology and acceptance because it can affect whether the deployment is supplied and how it is documented.

Engineering Review Matrix

Deployment field	What to define	Evidence to request	Cutover risk if skipped
Topology	Spine count, leaf count, host ports, uplinks, routing, and oversubscription	Topology diagram and port matrix	Fabric is underbuilt or cabled incorrectly
Optics and cabling	Form factor, reach, connector, fibre, breakout, and spare strategy	Optics matrix and link-up evidence	Links fail during installation or replacement
NOS and features	SONiC or NOS version, BGP, EVPN, RoCE, telemetry, automation	Version record and feature assumptions	Buyer expects unsupported behavior
Telemetry	Interface counters, queues, drops, optics DOM, alerts, and collector	Telemetry sample and alert test	Operations cannot see failure or congestion
Rollback	Config backup, image recovery, console access, and validation after rollback	Rollback drill and exception log	Failed change has no tested recovery path
Acceptance	Traffic sanity, link stability, management, monitoring, and handover	FAT/SAT checklist and signoff record	Cutover happens with no release gate
Export review	Destination, end user, end use, and technical scope	Export screening note before order release	Compliance issues appear after purchase

This matrix should be owned jointly by engineering and procurement. It is technical enough to catch real gaps and simple enough for non-network stakeholders to follow.

Deployment sequence

First, lock the topology and port matrix. Every switch port should have a role: host, uplink, management, peer, spare, or tool. Every optic should map to a port and a cable path. If a breakout is expected, record it explicitly.

Second, lock the software assumption. Name the SONiC or NOS version, hardware SKU, features in scope, features excluded, and any image dependencies. If the deployment uses EVPN-VXLAN, RoCE v2, telemetry, warm reboot, MC-LAG, or packet broker functions, those features should appear in the acceptance plan.

Third, validate observability. A deployment that cannot be monitored is not ready. Confirm management access, telemetry streams, interface counters, queue counters where relevant, optics DOM, logs, and alert path. Save at least one telemetry sample before shipment or before production cutover.

Fourth, test rollback. Push a known-good configuration, apply a controlled change, roll back, and confirm the fabric returns to the accepted state. Record the command path, source-of-truth, time, and result. This is a small lab exercise that prevents a large production argument.

Fifth, prepare the handover. The receiving team should get topology, port matrix, optics matrix, image version, configuration assumptions, validation report, exceptions, support contacts, and change-control notes.

Acceptance evidence for global deployments

Acceptance evidence should be readable by someone who did not attend the build call. It should include what was tested, under what condition, with which software version, on which port profile, and with which result. If there was an exception, the record should say whether it was accepted, fixed, deferred, or excluded.

For AI fabric projects, add RoCE, PFC, ECN, DCBX, queue, and traffic evidence where applicable. For storage networks, add loss, latency, path, and failure behavior. For campus or aggregation projects, add PoE, LAG, VLAN, uplink, and AP behavior where relevant.

For export projects, do not write that every destination is available. Write that international supply is subject to destination, end-user, end-use, technical scope, sanctions, and export control screening.

Quote-stage validation note

The quote should read like the first version of the deployment runbook. It should identify who owns topology, cabling, optics, switch configuration, telemetry, rollback, and support escalation. It should say what will be validated before shipment, what must be checked on site, and what remains outside scope. This level of clarity prevents the buyer from treating the bill of materials as a deployment plan.

For a 400G or 800G SONiC fabric, ask for a short pre-production record with switch model, HWSKU, image version, port matrix, optics matrix, management access, telemetry sample, representative traffic result, and rollback result. For a fabric that uses EVPN, RoCE, or packet visibility functions, add the feature-specific evidence rather than assuming the base switch validation covers it. A data center deployment can pass a link-up test and still fail the workload if queue policy, route convergence, or telemetry is not checked.

For export, the quote should state the destination, end user, end use, documentation language, and delivery terms used for review. That does not replace compliance review, but it gives procurement and engineering one shared record before order release.

Procurement record template

Create a deployment baseline file before purchase. It should include site, destination, end user, end use, topology, rack plan, switch model, port matrix, optics matrix, NOS version, management plan, telemetry collector, automation source, rollback owner, acceptance owner, support owner, and handover package. Each field should have a status: confirmed, pending, excluded, or blocked. The blocked status is useful because it stops unresolved design items from disappearing inside the quote.

The baseline file should survive into operations. After deployment, it becomes the reference for replacements, audits, incident response, and change planning. If a future link fails, the team can see the intended optic, port role, software version, and telemetry path. If a future phase adds capacity, procurement can see what was validated in phase 1 and what needs a new acceptance record. That continuity is the difference between a deployment checklist and a one-time purchasing document.

Sources Reviewed

SONiC project documentation for SONiC architecture and open networking context.
Open Compute Project SONiC community for SONiC testing context.
IEEE P802.3dj task force for high-speed Ethernet planning context.
OpenConfig gNMI specification for telemetry and configuration interface context.
ABF export requirements for export workflow context.
DFAT sanctions compliance toolkit for sanctions screening context.

These sources keep the deployment checklist grounded in technical and export references. The final checklist still needs to be adapted to the buyer environment.

Engineering FAQ

What is the minimum deployment checklist for a SONiC fabric?

Include topology, port matrix, optics matrix, NOS version, management access, telemetry, rollback, acceptance method, support owner, destination, end use, and handover records.

Why should rollback be tested before production?

Because configuration or image changes can fail under pressure. A tested rollback path proves the team can return to a known-good state without inventing recovery steps during an outage.

What evidence should be included in handover?

Include topology, port and optics matrices, image version, configuration assumptions, telemetry sample, validation report, exception log, support contacts, and change-control notes.

How does Australian-made positioning apply to global deployments?

For eligible projects, it describes Australian architecture review, validation planning, documentation, and commercial accountability for the finished deployment package using qualified global components.

Quote-stage handoff

Send topology, port matrix, optics plan, software assumptions, telemetry, rollback requirements, destination, and acceptance criteria. xSONiC can then validate the deployment package before the order is released.

Product fit

Where xSONiC fits

xSONiC can help validate the switch, optics, software image, telemetry, and support assumptions against the actual deployment before a production order is released.