---
title: "SONiC Switch Installation: Separate Hardware, Software and Physical Handoff"
description: "Leviathan Systems — Technical content Published 2026-10-15; updated 2026-10-20."
canonical: "https://www.leviathansystems.co/articles/sonic-switch-physical-installation-records"
last-updated: "2026-10-20"
---

# SONiC Switch Installation: Separate Hardware, Software and Physical Handoff

Leviathan Systems — Technical content
Published 2026-10-15; updated 2026-10-20.

An ONIE-capable switch and a switch running the requested SONiC build are different deliverables. ONIE provides an environment for a network operating system (NOS) installer; its identity does not establish an installed or active SONiC build. A buyer needs the exact physical platform, actual operating build and support owner alongside the mounting and connection records. The word SONiC alone does not specify a chassis, port arrangement, supported optic or service agreement.

## Distinguish the project from the purchased system

The SONiC Foundation describes a Linux-based network operating system running across switches from multiple vendors and ASICs. That ecosystem makes the exact platform and software source important inventory fields. A project name cannot substitute for the manufacturer model, ordered configuration or installed image.

ONIE, the Open Network Install Environment, is itself a small operating system for bare-metal switches. Its published design overview describes finding and running a NOS supplier's installer, which provisions the switch for that NOS. In the overview's subsequent-boot model, the installed NOS starts directly, bypassing the ONIE kernel and discovery/execution application. The installation environment and the operating NOS therefore have different roles.

SONiC's source-repository overview also identifies a platform-specific SAI library beneath its common Switch Abstraction Interface. A common interface still needs the applicable hardware implementation. The purchasing implication is that an ONIE-capable chassis or a SONiC project label cannot establish support for a particular hardware/build combination.

Ask who supplies and supports the actual combination. A customer may use a vendor distribution or another approved build; do not infer which from the chassis logo or assume a public compatibility listing creates a support contract. The authorized network owner must establish the applicable support and release evidence.

References: [S1](https://sonicfoundation.dev/about/), [O1](https://opencomputeproject.github.io/onie/design-spec/overview.html), [S2](https://raw.githubusercontent.com/sonic-net/SONiC/master/sourcecode.md)

## Create a switch record with distinct identities

The register below connects the physical asset to the customer's authorized inventory and network records. If those records include an ONIE version, keep it as an installation-environment identity, separate from the operating-NOS field. Record the requested SONiC distribution/build and the returned evidence of the build in use against the same asset; an environment-only return leaves that NOS evidence outstanding.

Have the named network owner explain the observation's time and meaning. A version named in an offer is a requested output; a supplied image file is an artifact; an observation of the operating build addresses the switch's reported state. Keep confidential software/access information in the agreed system of record.

Illustrative SONiC switch handoff register
| Identity | Record field | Why it remains separate | Source |
| --- | --- | --- | --- |
| Physical asset | Customer asset ID, manufacturer model and permitted serial reference | Locates the installed device | Planning analysis |
| Hardware applicability | Exact platform/revision and approved OEM instructions | Avoids treating all SONiC-capable hardware alike | Planning analysis |
| Operating NOS | Customer-confirmed distribution, running image/build and observation reference | Identifies what the network owner actually operates | Planning analysis |
| Support | Named support owner and actual entitlement/reference where applicable | Avoids inferring service from the project name | Planning analysis |
| Port plan | Physical cage/port plus approved logical mode and endpoint schedule | Distinguishes installed interfaces from configuration | Planning analysis |
| Completion evidence | Mounting/cabling records and separate software acceptance reference | Keeps physical completion from becoming a configuration sign-off | Planning analysis |
Original illustrative planning record. These fields are not a customer record, engineering design or acceptance standard.

## Reconcile optics and port modes with the supported combination

Obtain the approved module/assembly schedule and the platform/software support reference. Physical port density and connector shape alone cannot settle a module, speed or breakout decision. Keep configured logical interface names separate from the physical cage labels that a field installer can observe.

If the delivered switch model or software record differs from the approved plan, raise the discrepancy with its owner. Do not install another image, change port modes or substitute an optic to make a physical schedule appear consistent. Those are separately authorized technical decisions, not inventory cleanup.

## Scope the physical task without assuming software ownership

A physical work package can define customer-furnished mounting accessories, approved rack position, cable routes, endpoint identifiers and agreed observations. Confirm the exact OEM/site requirements and assigned resources for that work. A software choice does not remove rack, access or handling prerequisites.

Compare the output being bought. An equipment supplier may offer a bare-metal switch with an installation environment; a physical installer may be appointed only to mount and cable that equipment. If the required delivery includes a supported SONiC package or the requested build operating on each asset, name the party responsible for that software deliverable, its hardware and release applicability, installation responsibility and returned operating-build evidence.

Configuration, image management, routing, security controls and service validation remain with the named network/software owners unless their actual separate scope establishes otherwise. Leviathan's standard rack installation covers the agreed physical work and records; OS imaging and software commissioning are outside its standard inclusions. This article explains delivery evidence and supplies no equipment-change procedure or work authorization.

References: [L5](https://www.leviathansystems.co/services/rack-and-stack)

## Read four environment records without counting four SONiC deployments

Consider a fictional offer for four physical switches, A through D, with the requested operating build called SONiC-B. That label is invented; it names no real release or supported platform. Stipulate that all four arrive with records identifying their ONIE environments, and that those records contain no operating-NOS observation.

The return contains four environment identities and zero observations of SONiC-B in use. This does not prove that no NOS is installed on any switch. It means the supplied evidence has not answered the requested-build question for any of the four.

Now stipulate a later return containing fresh, asset-specific observations of SONiC-B operating on A and B, with no such observation for C or D. For this example, the appointed network owner confirms what those observations mean. The returned count is two observed requested builds. The two observations establish no configured service, support entitlement or application acceptance, and they do not turn the four hardware deliveries into four complete deployments.

These are invented evidence premises, not a run result or staging sequence. If the purchase ended at hardware delivery and physical mounting, judge that work by its own agreed physical evidence. If it required the operating SONiC build on all four assets, the build evidence for C and D remains outstanding with the appointed software party.

At handoff, provide the installed physical asset/port records, approved changes, open items and separate acceptance references. Operations should be able to locate the hardware and identify who owns a software issue without guessing from a cable label.

## Prepare the inputs for a bounded installation inquiry

Share the exact switch inventory, approved rack and endpoint plans, required material responsibilities, site constraints and expected physical records. Confirm the designated network owner who will receive the connections and assess software behavior.

Leviathan can discuss customer-equipment installation and structured cabling within the agreed scope. Use the related rack-and-stack service and project inquiry for the physical work, with the appointed NOS supplier and receiving network owner named separately. Material supply and specialist trades are not inferred from installing an identified switch.

References: [L5](https://www.leviathansystems.co/services/rack-and-stack), [L1](https://www.leviathansystems.co/services/structured-cabling)

## Common planning questions

### Does SONiC identify a specific switch model?

No. It is a network OS. The physical model, configuration, actual software build and support ownership must be recorded separately.

### Does this handoff authorize installing or upgrading the OS?

No. Software and configuration work requires its own authorization, supported procedure and responsible technical owner. The article describes physical and inventory evidence.

## Primary sources

- [S1 — SONiC Foundation: What is SONiC?](https://sonicfoundation.dev/about/). Checked 2026-10-20. Project definition of a Linux-based network OS across multiple hardware vendors and ASICs. Exact SKU/build/support must be verified with the responsible vendor; no support agreement inferred.
- [O1 — ONIE Design Specification: Overview and Subsequent Boots](https://opencomputeproject.github.io/onie/design-spec/overview.html). Checked 2026-10-20. Historical interface documentation with a 2013–2018 copyright: installer-environment and installed-NOS roles. No 2026 specification revision or operating procedure is asserted.
- [S2 — SONiC Source Repositories: sonic-sairedis and platform-specific SAI library](https://raw.githubusercontent.com/sonic-net/SONiC/master/sourcecode.md). Checked 2026-10-20. Undated master document checked on the stated date. Explains common interfaces and a platform-specific SAI library; it is not a release support matrix.
- [L5 — Leviathan rack-and-stack scope](https://www.leviathansystems.co/services/rack-and-stack). Checked 2026-10-20. Customer-furnished equipment installation within agreed task/OEM/site boundaries. Handling, removal and other conditional activities need their actual scoped authorization.
- [L1 — Leviathan structured cabling scope](https://www.leviathansystems.co/services/structured-cabling). Checked 2026-10-20. Approved physical cabling scope; exact customer design, materials, access and verification remain engagement-specific.

## Related Leviathan resources

- [GPU Breakout Cabling: Map the Cage, Logical Port and Cable Leg](/articles/transceiver-breakout-cabling-gpu)
- [Spectrum-X or InfiniBand: Define the Physical Installation SOW](/articles/spectrum-x-vs-infiniband-cabling)
- [Customer-Furnished Materials: An Installation Readiness Checklist](/articles/customer-furnished-materials-installation-checklist)
- [Rack-and-stack installation scope](/services/rack-and-stack)
- [Firmware package delivery, staging and the version in use](/articles/gpu-firmware-staged-versus-active-version)
- [ISSU: forwarding, control and management continuity](/articles/switch-issu-control-plane-forwarding-scope)
- [OSPA draft: proposed switch platform reuse beneath SONiC](/blog/ocp-ospa-switch-platform-layer-draft)
- [Discuss the physical switch installation and handoff](/contact?service=rack-and-stack&from=%2Farticles%2Fsonic-switch-physical-installation-records)

## Define the switch installation inputs

Send the exact hardware inventory, approved physical port plan, rack requirements and receiving network owner.

[Discuss the scope](/contact?service=rack-and-stack&from=/articles/sonic-switch-physical-installation-records)