How a Network Switch Is Made: ASICs, Network OS and Firmware

A network switch is made by pairing a switch ASIC, the chip that forwards packets, with a separate management computer on a high speed circuit board. The factory flashes a boot loader, an install environment, CPLD images and an identity EEPROM, then tests every port with traffic generators. The buyer installs the network operating system.

This post goes one level deeper than our guides to how Ethernet switching works and how a home router is made, and sits next to our walk through of how a rack server is made. It follows a data center or enterprise switch from the silicon to the rack, and at each step asks three questions: which software or firmware got written here, who signed it, and how would you later prove what is running? The facts come from the Open Compute Project's ONIE and SAI documentation, the SONiC project, the P4 Language Consortium, IEEE 802.3 and 802.1, the OIF, IETF RFCs, OpenConfig, NIST and CISA. Where a step depends on a particular manufacturer's process, we say so and suggest what to ask.

Key takeaways

• A switch is two systems in one chassis: a forwarding plane built around the switch ASIC, and a management CPU that runs Linux and the network operating system (NOS).
• The ASIC is a pipeline of parsers, match action tables, TCAM, buffers and schedulers. Merchant silicon means the ASIC is designed and sold by a chip company to many switch makers, rather than built in house by one system vendor. P4 (the P4_16 language, current release v1.2.5 from October 2024) describes programmable pipelines in a target independent way.
• ONIE, the Open Network Install Environment, combines a boot loader with a Linux kernel and BusyBox so a bare switch can find and run a NOS installer. That is what makes the white box or disaggregated model work.
• One switch can carry UEFI or U-Boot, ONIE, several CPLD images, an FPGA image, SSD firmware, a NOS built from hundreds of Linux packages and containers, a licensed ASIC SDK, and firmware in every optic. Different companies write and sign each.
• Secure boot on x86 switches follows the Linux shim model: ONIE documents a shim carrying the hardware vendor's certificate, signed by the UEFI certificate authority, with GRUB and the kernel signed by the hardware vendor. SONiC's secure boot design signs shim, GRUB, the kernel and kernel modules, using a separate signing server for production keys.
• Device identity comes from IEEE 802.1AR (an IDevID installed by the supplier) and, for zero touch bring up, RFC 8572 Secure Zero Touch Provisioning. CMIS 5.3 (September 2024) adds optional module authentication for pluggable optics.
• Inventory every layer on arrival and on a schedule: NOS show commands, fwutil or show platform firmware status, sfputil show fwversion for optics, OpenConfig firmware-version and software-version leaves over gNMI, and the ENTITY-MIB columns entPhysicalFirmwareRev and entPhysicalSoftwareRev over SNMPv3.

What is inside an enterprise or data center switch?

Open the lid of a fixed configuration top of rack switch and you find two quite different computers sharing one sheet metal box. ONIE's own overview puts it plainly: modern network switches have a management subsystem, typically with a serial console, out of band Ethernet and mass storage, and that subsystem "can function independently from the switching ASIC(s)" behind the front panel ports.

The forwarding plane

The switch ASIC. This is the large chip, usually under the biggest heat sink in the middle of the board. It parses every arriving frame, looks up where it goes, applies access lists and quality of service rules, queues it and sends it out of the right port. Everything in the data path happens in hardware, so the ASIC sets the switch's port count, total bandwidth, table sizes and buffer size.

SerDes. Around the edge of the ASIC die sit hundreds of serializer and deserializer lanes. Each lane turns wide parallel data inside the chip into one very fast serial signal on a copper trace and back again. Port speeds are built by grouping lanes. The IEEE 802.3df amendment, approved by the IEEE SA Standards Board on 16 February 2024, defined 400 Gb/s and 800 Gb/s Ethernet, and the follow on P802.3dj task force is working on 200 Gb/s, 400 Gb/s, 800 Gb/s and 1.6 Tb/s. The lane rate the ASIC supports decides which of those the switch can offer and how hard the board designers have to work to keep the signals clean.

PHYs and retimers. On many high speed switches the ASIC's SerDes drive the front panel cages directly. Where the trace is too long or the signal budget too tight, a retimer or gearbox chip sits in between to clean up and re time the signal, or to convert between lane rates. Lower speed copper ports (1G or 10GBASE-T on campus switches) use separate PHY chips that handle the analogue line coding for twisted pair. These chips often have their own firmware.

Cages for optics. The front panel is a row of metal cages for pluggable modules: SFP family for single lanes, QSFP and OSFP families for four and eight lane ports. The modules themselves are small computers: an optical or electrical transceiver plus a microcontroller with a management memory map. For modern high speed modules that map follows the OIF's Common Management Interface Specification (CMIS), whose revision 5.3 was approved on 4 September 2024.

The management plane

Management CPU complex. A separate x86 or Arm system on chip, sometimes on its own daughter card, with DRAM, an SPI flash for the boot firmware, and an SSD or eMMC for the operating system. It runs Linux, the routing protocols, the management APIs and the driver that programs the ASIC over PCI Express. ONIE's design specification has two architecture tracks for this: x86 platforms with UEFI or legacy BIOS plus GRUB, and U-Boot platforms (historically PowerPC and Arm).

Board management logic. Several CPLDs handle power sequencing, resets, LEDs, fan control signals and the low speed buses (I2C) that reach the optics cages. ONIE's firmware update documentation says most platforms have "some number of CPLDs (3 seems typical)". Larger systems add an FPGA, and some carry a separate baseboard management controller.

Identity EEPROM. A small EEPROM, or a sector of NOR flash, holds the system's identity in ONIE's TlvInfo format: product name, part number, serial number, base MAC address, the number of MAC addresses allocated, manufacture date, ONIE version, manufacturer, country code and vendor, finished by a CRC-32.

Power and cooling. Two hot swappable power supplies and a row of fan trays, each usually with its own microcontroller and firmware, reporting through the CPLDs or I2C to the CPU. Fan direction (front to back or back to front) is a stocked option, because the switch must match the hot aisle layout of the rack.

Parts at a glance

How is a switch ASIC designed, and what is merchant silicon?

A switch ASIC is designed like any other large chip: architects decide on the port count, bandwidth, table sizes and buffer, logic designers write the hardware description, verification teams simulate it for months, physical designers lay it out, and a foundry builds it on silicon wafers. Our explainer on how semiconductors are made covers the fab side. What is special about a switch chip is the shape of the logic.

The packet pipeline

Every packet flows through roughly the same stages:

1. Port and MAC logic. SerDes recover bits, the MAC checks frame boundaries and the frame check sequence, and counters update.
2. Parser. A state machine walks the headers (Ethernet, VLAN tags, IPv4 or IPv6, TCP or UDP, tunnel headers) and extracts the fields later stages need.
3. Ingress match action stages. A series of tables, each matching some header fields and applying an action: learn or look up the destination MAC, longest prefix match on the IP route, check an access list, choose a next hop, mark a queue.
4. Traffic manager and buffer. The packet is stored in shared on chip memory, queued per output port and class, and scheduled out according to priorities and weights. Buffer size and how it is shared decide how the switch behaves under bursts.
5. Egress match action stages. Rewrites for the outgoing port: VLAN tags, tunnel encapsulation, egress access lists, mirroring.
6. Deparser and transmit. Headers are reassembled and the frame is serialised onto the output lanes.

Tables, SRAM and TCAM

Exact match tables (MAC addresses, host routes) live in SRAM and are searched with hashing. Tables that need wildcards, ranges or longest prefix matching (access lists, some routing) use TCAM, ternary content addressable memory, where each bit can be 0, 1 or "don't care" and every entry is compared in parallel. TCAM is fast and flexible but uses far more area and power per entry than SRAM, so TCAM size is one of the first numbers network architects check in a datasheet. When an access list or route table outgrows the hardware, the switch either rejects the configuration or falls back to the CPU, which is orders of magnitude slower.

Fixed function versus programmable pipelines

In a fixed function ASIC, the parser and the order and type of tables are set in silicon. The chip supports the protocols its designers chose, and a new header format means a new chip. A programmable pipeline keeps the same broad structure but lets the parser graph and the table layout be defined by software loaded at boot.

P4 is the language most associated with that idea. The P4_16 specification describes P4 as "a language for programming the data plane of network devices". A P4 program defines parsers, match action tables, actions and deparsers; an architecture definition describes what a particular target offers; and a target specific compiler maps the program onto the hardware or rejects it. The specification states that an architecture "may reject a well-typed P4 program and still be conformant", which is a useful reminder that portability stops where the hardware's resources stop. The P4 Language Consortium also publishes the Portable Switch Architecture (PSA, v1.2, December 2022) as a common switch target, and P4Runtime (v1.5.0, February 2026) as the control plane API for loading programs and populating tables.

From a supply chain point of view, a programmable pipeline adds one more artifact to track: the compiled pipeline image or configuration that the NOS loads into the ASIC. It is software, it has a version, and it should be in your inventory.

What merchant silicon means

For most of networking's history, a switch vendor designed the ASIC, the board and the operating system together. Merchant silicon is the alternative: an independent chip company designs switch ASICs and sells them to many system makers, along with a reference board design and a software development kit (SDK). Several board makers can then build switches around the same chip, and the differences between their products move into board quality, thermal design, support and software.

The SDK is the important part for this post. It is the vendor library that knows how to program that ASIC's registers and tables. It is usually distributed under licence rather than as open source, and it ends up linked into whatever NOS runs on the switch. To decouple the NOS from each chip's SDK, the Open Compute Project hosts the Switch Abstraction Interface (SAI), described by OCP as a sub project of its Networking Project. SAI defines a common C API for forwarding elements; the ASIC vendor supplies an implementation of SAI on top of its SDK, and the NOS talks only to SAI.

What is the white box model, and how does ONIE let you install a NOS?

Disaggregation in one paragraph

ONIE's documentation describes the situation it was built to change: before ONIE, Ethernet switches came "with pre-installed, captive operating systems", which locked buyers into one vertical supply chain. A white box (or bare metal, or disaggregated) switch separates the hardware purchase from the software purchase. You buy a switch from a board maker, then install the NOS you chose, the same way you buy a server and install the Linux distribution you chose. ONIE describes itself as now "the de facto install environment across the networking hardware industry".

How ONIE works on first boot

ONIE is a boot loader plus a small Linux and BusyBox system stored on the switch's flash. It uses the management CPU complex only; it never touches the forwarding plane. On the first power on of a new switch, ONIE runs and looks for a NOS installer. The ONIE overview lists the discovery methods: a URL statically configured from the boot loader, local storage such as a USB stick, DHCPv4 and DHCPv6 options, IPv4 and IPv6 link local neighbours, mDNS and DNS-SD, and "PXE-like" TFTP and HTTP waterfalls. HTTP is preferred; TFTP is supported but discouraged.

When ONIE finds an installer, it exports environment variables (the installer URL and system identification) and executes it. The installer writes the NOS to disk, sets up the boot loader to start the NOS, and tells ONIE that a NOS is present. On every later boot the switch goes straight into the NOS and skips ONIE, unless the NOS uses the interface ONIE defines to send the system back to the installation phase.

What the boot loader environment looks like

On x86 switches, ONIE's design describes UEFI firmware (or legacy BIOS) loading GRUB, which presents ONIE and the NOS as boot entries. On U-Boot platforms, U-Boot environment variables point at the NOS image and ONIE. Either way, the boot loader is the hinge between "factory owned" software (firmware and ONIE) and "operator owned" software (the NOS). That hinge matters for security: if anyone can drop into the boot loader from the serial console and change the boot target, the signed NOS does not help much. Lock the boot loader menus and passwords along with everything else.

Useful ONIE commands

From the ONIE prompt (reached from the boot menu or by a NOS request), the CLI reference documents these:

# Who is this switch? Run before any install so you know you are on the right box.
onie-sysinfo -a          # everything: serial, MAC, ONIE version, platform, CPU architecture
onie-sysinfo -s          # serial number only
onie-sysinfo -v          # ONIE version
onie-sysinfo -S          # switch silicon vendor
onie-sysinfo -l          # boot loader type

# Firmware update packages staged for ONIE (x86_64 only, 2015.08 and later)
onie-fwpkg show-pending
onie-fwpkg show-results
onie-fwpkg show-log

Installing a NOS from ONIE replaces whatever operating system is on the switch's disk. Before you run the next block, confirm with onie-sysinfo -s that the serial number matches the switch in your change ticket, confirm you are on the console of that switch and not a neighbour on the same console server, and save any configuration you need from the old NOS.

# WARNING: replaces the installed NOS on this switch. Check the serial first.
onie-sysinfo -s
# Verify the installer's digest against the value your NOS supplier published
# (do this on the HTTP server before staging, or with the image on local media)
sha256sum /path/to/nos-installer.bin
onie-nos-install http://deploy.example.internal/images/nos-installer.bin

How are switch boards manufactured and tested?

A switch board is a printed circuit board like any other, but a demanding one. Our post on how a printed circuit board is made covers lamination, drilling, plating and surface mount assembly. The switch specific work sits on top of that.

Signal integrity

Hundreds of SerDes lanes run from the ASIC to the cages at tens of gigabits per second each. At those rates a board trace behaves like a transmission line, and every via, connector and change in layer adds loss and reflections. Designers choose low loss laminate, control the impedance of each differential pair, back drill via stubs, keep pairs short and matched in length, and model the full channel from SerDes to module before the board is built. The IEEE 802.3 clauses for each port type define electrical specifications for the host to module interface, and the board has to meet them across temperature and manufacturing variation. Where it cannot, a retimer goes on the board.

During validation, engineers measure eye diagrams and bit error rates on every lane with test equipment and loopback modules, and tune the SerDes transmit and receive settings (pre emphasis and equalisation) for each port. Those per port tuning values become data in the platform files that the NOS loads, which is another reason the same NOS needs platform specific packages for each board.

Thermal design

A large switch ASIC dissipates a lot of heat, and so do the optics in the front panel cages, especially long reach coherent modules. Thermal engineers model airflow through the chassis, size heat sinks, choose fan curves and test the box in a chamber at the top of its rated temperature range with every port loaded with the hottest supported optic. The fan control logic, usually in a CPLD or the NOS platform daemon, uses temperature sensors on the ASIC, CPU, optics and board to set fan speed.

Production test

On the factory line, each board goes through checks broadly similar to other complex electronics:

• In circuit and boundary scan test checks for opens, shorts and wrong parts after assembly. JTAG boundary scan reaches pins hidden under ball grid array packages.
• Programming. SPI flash gets the boot firmware and ONIE, CPLDs are programmed (ONIE notes CPLDs are typically upgraded via JTAG signals driven from the CPU complex), and the identity EEPROM gets its TlvInfo record with serial number and MAC range.
• Functional test. The switch boots a diagnostic image, exercises memory, storage and sensors, and passes traffic on every port. ONIE's x86 design includes an optional hardware diagnostics interface for this.
• Traffic test. Traffic generators send line rate traffic of varied frame sizes through every port, checking for loss, errors and correct forwarding, often with loopback modules in the cages.
• Burn in. Units run under load, sometimes at elevated temperature, to catch early life failures.
• Final configuration. Power supplies and fans of the ordered airflow direction are fitted, labels are applied, and the shipping firmware set is checked.

Compliance

Before a model ships, it is tested for electromagnetic emissions and immunity, and for product safety, against the rules of each market it is sold in. These are type tests on the design, not per unit tests. Optics carry their own laser safety classification. None of these tests says anything about the software, which is why the rest of this post exists.

What firmware and software ship on a switch, and who signs each?

This is the heart of the supply chain question. A switch is not one image. It is a stack of separately built, separately updated pieces from different organisations.

Three observations from that table.

First, the people who sign the boot chain are not the people who wrote most of the code in it. A NOS image may carry a Linux kernel, a Debian user space, a routing suite and an ASIC SDK, and one signature covers all of it. A valid signature tells you who built the image, not what is inside.

Second, the board level images (CPLD, FPGA, PSU, fans) are the least visible. They change rarely, they are often not signed in a way the operator can check, and they are often missing from inventories entirely. ONIE's firmware update design explicitly places these updates "in ONIE context" so the hardware vendor can ship one updater regardless of NOS. The flow is: stage the update from the NOS, reboot into ONIE update mode, apply, and reboot back, sometimes with a cold boot when a CPLD needs it.

Third, optics are computers too. CMIS defines a command data block (CDB) interface for firmware download, with commands to run and commit an image, and many modules keep two images so a failed update can fall back. SONiC's command reference shows exactly that view, with "Image A", "Image B", "Running Image" and "Committed Image" for a module. CMIS 5.3 also adds an optional security command group for module authentication, starting with a command to get the module's initial device ID certificate. Ask your module supplier whether they implement it.

How do open source network operating systems work?

What a NOS is made of

Take SONiC, the Software for Open Networking in the Cloud, as the reference example. Its foundation describes it as an open source NOS "based on Linux" that runs on switches from multiple vendors and ASICs, and it is now a Linux Foundation project. Its architecture document describes a design built around three ideas:

• A central Redis database. Applications publish and subscribe to state in Redis databases instead of calling each other directly. The configuration database, the application database and the ASIC database each hold a view of the switch.
• Containers for each function. SONiC's architecture lists separate Docker containers for DHCP relay, platform monitoring (pmon), SNMP, LLDP, BGP, teamd for link aggregation, the database, switch state services (swss) and syncd.
• SAI to reach the hardware. The syncd container holds the process that synchronises the desired network state with the ASIC. In SONiC's own words, syncd "links with the ASIC SDK library provided by the hardware-vendor", calling it through SAI.

The routing protocols run in an open source routing suite in the BGP container. The CLI is written in Python using the Click library. The base operating system is Debian. SONiC's release roadmap records the base OS upgrade to Debian 12 (Bookworm) in the 202405 release cycle, and its build system README now documents both Bookworm and Trixie build environments.

What a NOS pulls in from upstream

A NOS image built this way contains:

• A Linux kernel, plus platform drivers for that board's CPLDs, fans, sensors and optics.
• A Debian base system: libc, OpenSSL, systemd, Python and hundreds of other packages.
• Several container images, each with its own copy of a Debian user space and the specific daemons for that function.
• The routing suite, LLDP daemon, SNMP agent, DHCP relay and teamd, all open source.
• Python libraries for the CLI and management services.
• The ASIC vendor's SAI implementation and SDK, as shared libraries inside the syncd container, usually closed source.
• Platform packages for each supported board, carrying per port SerDes tuning and device drivers.

That makes a NOS image a Linux distribution in its own right, with a much larger dependency tree than most people expect from "the switch software". When a vulnerability appears in OpenSSL, a Python library or the kernel, the question "are our switches affected?" is an SBOM question about the NOS image, not a hardware question.

Where the kernel fits: switchdev

There is a second open model in the Linux kernel itself. The kernel's switchdev documentation describes "an in-kernel driver model for switch devices which offload the forwarding (data) plane from the kernel". Each front panel port appears as an ordinary Linux network interface, and standard tools (bridge, ip route) configure forwarding, which the driver mirrors into the ASIC. Fewer layers of user space glue sit between the operator and the hardware, and the kernel driver for the ASIC goes through the kernel's normal review.

How do secure boot, signed images and supply chain checks work for switches?

Platform firmware resiliency

NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), names network switches alongside desktops, notebooks and servers as traditional x86 platforms in scope. It frames resiliency as three things: protecting firmware from unauthorised change, detecting when it has been changed, and recovering to a known good state. Each is anchored in a root of trust: a Root of Trust for Update, a Root of Trust for Detection and a Root of Trust for Recovery. Use those three words as a checklist when you read a switch datasheet: which images are protected by authenticated update, which are measured or checked at boot, and what happens if the check fails.

The x86 secure boot chain

ONIE's x86 UEFI documentation describes the Linux shim method:

• shimx64.efi contains the hardware vendor's public certificate and is signed by the UEFI certificate authority whose key most x86 firmware trusts by default.
• grubx64.efi and the ONIE kernel are signed with the hardware vendor's private key.
• Building a secure boot ONIE is a four step process: compile shim with the vendor certificate embedded, submit it for signing, submit the shim source for community peer review, and build the ONIE installer around the signed shim. The ONIE news page notes that the 2021.11 release came with a secure boot build and demonstration tutorial.

SONiC's secure boot design (phase 1, June 2022) extends the chain to the NOS: it signs shim, GRUB, the Linux kernel and kernel modules, and verifies them at runtime. It defines two build flows. In development, the build signs with keys supplied at build time. In production, the boot components are sent to a signing server and returned signed, because the private keys should not live on build machines. The design leaves the production signing script to each vendor so that different signing servers can be plugged in.

What a signature does and does not prove

Secure boot checks that each boot stage was signed by a key the previous stage trusts. It does not:

• cover CPLD, FPGA, PSU, fan or optic firmware, which run on their own processors;
• prove that the content of a signed NOS image is free of known vulnerabilities;
• tell you whether the image is the version your change ticket approved;
• help if the platform ships with secure boot disabled, or with development keys enrolled.

So you still need inventory, hashes and policy. CISA's guidance on securing network infrastructure devices recommends buying only from authorised resellers, inspecting devices for tampering on installation, validating serial numbers from multiple sources, downloading updates only from validated sources, and performing "hash verification" against the vendor's published values to detect unauthorised changes to firmware. It also notes that unauthorised software can be loaded after a device is in service, so integrity checks should be regular, not one off.

Device identity and zero touch provisioning

IEEE 802.1AR-2018, Secure Device Identity (approved 14 June 2018, published 2 August 2018), defines an Initial Device Identifier (IDevID) that the supplier installs, cryptographically bound to the device, and Local Device Identifiers (LDevIDs) the operator adds later. In practice an IDevID is a private key held in protected hardware plus a certificate from the manufacturer's CA, created on the factory line.

RFC 8572, Secure Zero Touch Provisioning (SZTP, April 2019), uses that identity to bootstrap a new device safely. The device presents its IDevID to a bootstrap server; the server returns signed "conveyed information" along with an owner certificate and an ownership voucher issued through the manufacturer, so the device can check that the configuration really came from its owner. The RFC's security considerations note the increased reliance on manufacturers that this creates. Even if you do not use SZTP, asking a supplier whether the switch has an IDevID, and who operates the CA behind it, tells you a lot about their factory practices.

A practical acceptance check

1. Buy through authorised channels and record the serial numbers from the order.
2. On arrival, inspect seals and compare chassis labels, the EEPROM serial (onie-sysinfo -s or show platform syseeprom) and the order.
3. Check secure boot state from Linux on x86 platforms (mokutil --sb-state) and record which keys are enrolled.
4. Hash every image you install and compare against the supplier's published digest.
5. Run the inventory in the next section and compare each firmware version with the approved baseline.
6. Store the results as the switch's first inventory record.

How do you inventory switch software and firmware versions, step by step?

Inventory means recording, per switch, every version in the table above. Do it on arrival, after every change window and on a schedule. The commands below come from the SONiC command reference and the ONIE CLI reference; commercial NOS families have equivalents under names like "show version", "show inventory" and "show platform", so map each step to your CLI.

Step 1: identity and NOS version

show version                 # NOS version, Debian release, kernel, build commit and date,
                             # platform string, HwSKU, ASIC, serial, model, hardware revision,
                             # and the list of Docker images with tags and IDs
show platform summary        # platform, HwSKU, ASIC type and count
show platform syseeprom      # the TlvInfo EEPROM: serial, part number, base MAC, dates, ONIE version
sudo sonic-installer list    # current image, image for next boot, and all installed images

show version is worth saving in full. It gives you the kernel version and the exact container image IDs, which is what you need to answer "which switches run the vulnerable library?" later.

Step 2: board firmware

show platform firmware version         # fwutil version
sudo show platform firmware status     # per component: ONIE, SSD, BIOS, CPLD1..n, FPGA, with versions
sudo show platform firmware updates    # what the firmware bundle in the current or next image would change

SONiC's command reference shows a real status output listing ONIE, the SSD, the BIOS and four CPLDs separately, each with its own version string. That is the board level picture most inventories miss.

Step 3: optics

sfputil show fwversion Ethernet0
# Image A Version, Image B Version, Factory Image Version,
# Running Image, Committed Image, Active and Inactive firmware

Loop over every populated port. Record the module vendor, part number and serial from the transceiver EEPROM too, because the same part number can ship with several firmware versions.

Step 4: the same data over gNMI

For a fleet, pull versions through a model driven API instead of scraping CLI text. OpenConfig's openconfig-platform model (version 0.33.0 at the time of writing) defines, for each component, hardware-version, firmware-version ("the version of associated firmware that is running on the component"), software-version, serial-no, part-no and mfg-name. The gNMI specification (v0.10.0, 25 May 2023) requires TLS for the session, says clients and targets must not fall back to unencrypted sessions, and describes mutual certificate authentication. With the open source gnmic client:

gnmic -a switch1.example.internal:<gnmi-port> --tls-ca ca.pem \
      --tls-cert client.pem --tls-key client-key.pem -u inventory \
      get --encoding json_ietf \
      --path "/components/component/state/firmware-version" \
      --path "/components/component/state/software-version" \
      --path "/components/component/state/serial-no" \
      --path "/components/component/state/part-no"

Use a read only account. Our post on NETCONF, RESTCONF and YANG covers the NETCONF equivalent, which returns the same model as XML.

Step 5: SNMP, for older gear

Where gNMI is not available, the ENTITY-MIB (version 4 is RFC 6933, May 2013) has per component columns in entPhysicalTable: entPhysicalHardwareRev (column 8), entPhysicalFirmwareRev (9), entPhysicalSoftwareRev (10), entPhysicalSerialNum (11), entPhysicalMfgName (12) and entPhysicalModelName (13). Use SNMPv3 with authentication and privacy, never community strings:

# entPhysicalFirmwareRev and entPhysicalSoftwareRev, read only SNMPv3 user
snmpwalk -v3 -l authPriv -u inventory -a SHA -A "$AUTH" -x AES -X "$PRIV" \
  switch1.example.internal 1.3.6.1.2.1.47.1.1.1.1.9
snmpwalk -v3 -l authPriv -u inventory -a SHA -A "$AUTH" -x AES -X "$PRIV" \
  switch1.example.internal 1.3.6.1.2.1.47.1.1.1.1.10

What a vendor populates in these columns varies, so check one switch by hand against the CLI before trusting the fleet results.

Step 6: the management CPU's own firmware

On x86 switches with a Linux shell, the standard host tools work:

sudo dmidecode -t bios          # BIOS or UEFI vendor, version and release date
mokutil --sb-state              # is secure boot on?
uname -r                        # running kernel
ethtool -i eth0                 # management NIC driver and firmware version

Step 7: compare, record, alert

Put every record in one place keyed by serial number: NOS version and image hash, container image IDs, kernel, BIOS, ONIE, each CPLD and FPGA, SSD, optics firmware per port, PSU and fan versions where the platform exposes them. Compare each field against an approved baseline per model. Treat any field you cannot read as a finding, not as "fine".

Step table: from wafer to a racked switch

Timeline of the standards and projects behind switch trust

What should a buyer ask a switch supplier?

• Which firmware components are on this model, and which of them can the NOS report? Ask for the full list, including CPLDs, FPGA, SSD, PSUs, fans and retimers.
• Which images are signed, by whom, and which are verified at boot or at update time? Map the answer to NIST SP 800-193's protect, detect and recover.
• Is secure boot enabled at shipment? Which keys are enrolled? Are any development keys present?
• Does the switch have an 802.1AR IDevID? Who runs the issuing CA, and how are the keys generated and protected on the factory line?
• Is there an SBOM for the NOS image, including the container images and the ASIC SDK version? How often is it updated, and in what format?
• How are security advisories published for the NOS, the board firmware and the optics, and how do they map to versions you can read from the device?
• For optics: does the module support CMIS firmware update with A and B images, and does it implement CMIS module authentication?
• Where do you publish image hashes, and over what channel?

Common mistakes

• Treating the NOS version as the whole inventory. The NOS is one row of a dozen. CPLD, BIOS, SSD and optics firmware change independently and carry their own advisories.
• Assuming secure boot covers everything. It covers the boot chain on the management CPU. It says nothing about CPLDs, PSUs or optics, and nothing about known vulnerabilities inside a correctly signed image.
• Not hashing installer images. CISA recommends hash verification against the vendor's published values. Make it a step in the install runbook, not an occasional check.
• Leaving ONIE discovery open on a production network. ONIE will look for installers over DHCP, link local neighbours and HTTP waterfalls. Keep provisioning on an isolated management network and make sure only your server answers.
• Using SNMPv1 or v2c for inventory. Community strings travel in clear text. Use SNMPv3 with authPriv, or gNMI with TLS and mutual authentication.
• Running the same NOS image on boards without the right platform package. SerDes tuning and drivers are per board. A missing platform package shows up as link errors, not as a security warning, but it often leads to ad hoc fixes outside change control.
• Ignoring optics firmware. A module's committed image and running image can differ. Record both.
• Assuming a white box needs no supplier questions. Disaggregation moves the software choice to you, but the board maker still writes the firmware, ONIE build and EEPROM data you depend on.
• Forgetting the container images. On a container based NOS, show version lists image IDs. If those are not in your inventory, you cannot answer the next library vulnerability question quickly.

FAQ

What is inside a network switch?

A forwarding ASIC with its SerDes, optional retimers or PHYs, optics cages, a management CPU with flash and an SSD, several CPLDs, an identity EEPROM, power supplies and fans. Most of these carry their own firmware.

What is a switch ASIC?

The chip that does the forwarding: it parses headers, looks up destinations in SRAM and TCAM tables, applies access lists, and buffers and schedules packets. Its ports, bandwidth, tables and buffer set what the switch can do.

What is merchant silicon in networking?

Switch ASICs designed by a chip company and sold to many system makers, together with a reference design and an SDK. It lets several board makers build switches around the same chip, and it is the foundation of the white box model.

What is ONIE and how does it work?

ONIE, the Open Network Install Environment, is a boot loader plus a small Linux and BusyBox system on the switch's flash. On first boot it finds a NOS installer over DHCP, link local discovery, USB, mDNS or HTTP and TFTP waterfalls, runs it, and then gets out of the way on later boots.

What is a white box switch?

A switch bought as hardware with an install environment such as ONIE, so you choose and install the NOS yourself, as you would with a server.

What is SONiC?

Software for Open Networking in the Cloud, an open source Linux based NOS hosted by the Linux Foundation. It runs functions in Docker containers, keeps state in Redis databases, and reaches the ASIC through the Switch Abstraction Interface on top of the chip vendor's SDK.

What is P4 used for?

P4 is a language for programming the data plane of network devices. On programmable switch ASICs it defines the parser, match action tables and deparser, so new header formats or forwarding behaviours can be added in software. P4Runtime is the API for loading programs and managing table entries.

How do I check the firmware version on a switch?

On SONiC, show platform firmware status lists ONIE, BIOS, SSD, CPLD and FPGA versions, and sfputil show fwversion <port> shows optic firmware. For a fleet, read the OpenConfig firmware-version and software-version leaves over gNMI, or entPhysicalFirmwareRev and entPhysicalSoftwareRev over SNMPv3.

Do network switches support secure boot?

Many x86 based switches do. ONIE documents a shim based UEFI secure boot chain signed by the hardware vendor, and SONiC's design signs shim, GRUB, the kernel and kernel modules. Whether it is enabled at shipment, and which keys are enrolled, varies by model, so ask and check.

Does secure boot protect switch firmware like CPLDs and optics?

No. Secure boot verifies the boot chain of the management CPU. CPLDs, FPGAs, PSUs, fans and optics run on their own processors with their own update paths, so they need separate inventory, hash checks and supplier answers.

Where Safeguard fits

The fit here is partial and indirect, so plainly: Safeguard does not scan switch firmware, CPLD or FPGA images, ASIC SDK binaries or optics, does not produce hardware bills of materials, and does not manage or protect network devices. What it does is software composition work on the software your team builds and ships. If you build your own NOS images from an open source project, the container images inside them and the repositories that produce them can be scanned like any other project (safeguard scan --dir . for a repository, --image <name> for a container image, --sbom <file> for an SBOM your supplier provides), with vulnerability matching and reachability analysis, and the platform shows which projects contain a given component and version. The same applies to the Python or Go tools your network team writes to run the gNMI and SNMP inventory above, and to the containers that run your provisioning servers.

A switch's network operating system is a Linux distribution with hundreds of open source packages and several container images, and the tools your team writes to provision and inventory switches pull dependencies of their own. Board firmware and optics still have to come from their makers, but the open source software you build around the switch is where the steps below apply.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show Safeguard on ordinary software projects, not on switch hardware or firmware. They apply to the code around your switches: NOS build repositories if you build your own images, the inventory collectors that speak gNMI and SNMP, and the provisioning services that answer ONIE and zero touch requests.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, and it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. Point the same flow at your network automation repository and it proposes the dependency fix and runs your tests before anything is committed.

Click through it at your own pace, or open it full screen.

Switch management networks are usually isolated, as CISA recommends for out of band management. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner on a build or jump host inside the management zone can scan the provisioning tooling that lives there without opening that network to the outside.

Click through it at your own pace, or open it full screen.

If your team uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. A network engineer can then ask about vulnerabilities in the projects that hold your automation and NOS build code, using only the tools you allowed.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Open Compute Project, ONIE documentation home and news
• ONIE, Overview
• ONIE, Design Specification
• ONIE, Hardware requirements and TlvInfo EEPROM format
• ONIE, x86 UEFI firmware support and secure boot
• ONIE, Firmware updates
• ONIE, x86 NOS interface
• ONIE, Command line reference
• Open Compute Project, Switch Abstraction Interface
• SONiC Foundation, Linux Foundation project
• SONiC, Architecture wiki
• SONiC, Secure boot high level design
• SONiC, Firmware utility (fwutil) design
• SONiC, Release roadmap
• SONiC, sonic-buildimage README
• SONiC, Command reference
• Linux kernel documentation, Ethernet switch device driver model (switchdev)
• P4 Language Consortium, Specifications
• P4 Language Consortium, P4_16 Language Specification (working draft)
• IEEE 802.3 Ethernet Working Group
• IEEE P802.3df 400 Gb/s and 800 Gb/s Ethernet Task Force
• IEEE P802.3dj 200 Gb/s, 400 Gb/s, 800 Gb/s and 1.6 Tb/s Ethernet Task Force
• IEEE SA, IEEE 802.1AR-2018 Secure Device Identity
• OIF, Common Management Interface Specification revision 5.3 (PDF, 4 September 2024)
• NIST, SP 800-193 Platform Firmware Resiliency Guidelines (May 2018)
• NIST, SP 800-193 full text (PDF)
• CISA, Securing Network Infrastructure Devices
• OpenConfig, gNMI specification
• OpenConfig, openconfig-platform YANG model
• IETF, RFC 6933 Entity MIB (Version 4)
• IETF, RFC 8572 Secure Zero Touch Provisioning (SZTP)

Last reviewed: 23 October 2026. Specifications, NOS releases and firmware baselines change often; check the linked documents and your switch supplier's advisories for the versions that apply to your hardware.