CMIS Explained: State Machine, VDMs and Firmware Management

Before CMIS, a 400G module was a black box with a temperature sensor bolted on. After it, the module is a documented state machine you can interrogate lane by lane.

Standards & Specs · Published 2026-10-27 · 6 min read

Ask three vendors for "the register map" of an 800G module and you will get three documents, none of them complete. That is not vendor obstruction; it is what happens when a module contains eight lanes, two firmware images, a programmable datapath and a power negotiation protocol, and the management interface was designed for a fixed-register world. CMIS is the industry's answer - a specification maintained alongside the IEEE 802.3 PMD amendments - and reading it changes how you operate these modules: most concretely, it turns "is the module OK?" from a support ticket into a script.

The problem CMIS was built to solve

The previous generation of management interfaces mapped module functions to fixed memory addresses. That worked when a module was: one laser path in, one out, one power state, maybe four lanes. A 400G or 800G module breaks every one of those assumptions:

• Lanes multiplied. Eight electrical lanes that can be grouped as one 800G port, two 400G ports, or other splits, chosen in software.
• Power became negotiated. The host must know what a module will draw before enabling it, per slot, because a fully populated chassis is a thermal calculation (see the 800G selection guide for where that bites).
• Diagnostics got richer than fixed registers. Per-lane error counters and signal measurements do not fit a static map cleanly.
• Firmware became updatable. Two images, run and committed, on a pluggable module that may move between chassis.

CMIS answers all four with one model: the module is a small computer with a documented state machine, and the host talks to it accordingly.

The state machine is the contract

The part of CMIS that explains most field behavior is the module and datapath state model. The module moves through explicit states, and the host is expected to orchestrate the transitions - not assume the module is simply "up".

Two operational consequences are worth internalizing.

Init failures are a feature

When a lane group fails to reach Ready, CMIS tells you which state it stuck in. "Stuck in DPInit" is a vastly better symptom than "no link", because it usually means a configuration mismatch - unsupported lane mapping, unsupported rate - rather than dead silicon.

Breakout behavior is negotiated, not magic

Splitting an 800G module into 2x400G is a datapath configuration act. If your switch software and module disagree about lane assignment, the disagreement shows up in these states, which is also why the same pair of parts that works in one chassis can refuse in another with older software.

Power classes: a negotiation, not a label

CMIS defines power classes so the host can budget per slot before enabling a module. The classes relevant to current deployments:

The mechanism matters more than the numbers: the module advertises its class, the host grants power, and the datapath states will not complete if the grant never happened. A module that powers up on a bench but sits in ModuleLowPwr in a specific chassis slot is usually telling you the host refused or could not grant the class - a slot budget or qualification decision, not a hardware fault. The same telemetry is the backbone of the thermal shutdown diagnosis, where power class and measured temperature are read together.

VDMs: the telemetry that catches degrading lasers

Vendor Defined Mechanisms are the least glamorously named and most operationally valuable part of CMIS. They provide a standard way to expose measurements beyond the fixed mandatory set, addressed by descriptor, with defined units and scaling.

Pre-FEC error counts deserve emphasis.

Corrected errors are silent

Corrected errors are invisible to the link (that is what FEC is for), which means a lane can degrade for months while the port reports healthy. A nightly script that samples per-lane corrected-bit deltas turns that silent degradation into a trend line, and trend lines are what let you replace a module on your schedule rather than the link's.

VDM availability is per part

Not every module implements every VDM - the standard defines the container and the reporting contract, not a mandatory measurement list. Part of module qualification is writing down which VDMs a given SKU exposes, so your monitoring does not assume telemetry that was never there.

Firmware: two images and a commit bit

CMIS firmware management follows a run/commit model that will be familiar from switch software:

• The module holds two image slots. An update writes the inactive one, so an interrupted update leaves the running image untouched.
• Activation makes the new image running; commit makes it survive power cycles.
• The interface reports versions per slot, which is what makes fleet inventory scriptable.

The discipline that avoids trouble:

Inventory before touching anything

Collect running and committed versions across the fleet; mixed versions are more common than anyone admits and are the usual cause of "one shelf behaves differently".

Canary, soak, commit

Update in a canary group, activate and soak, commit only after a soak period that includes at least one reseat and one chassis power cycle. Committing on the same day as activation is how a latent image mismatch becomes a fleet-wide surprise.

Keep image families uniform per rail

Never mix image families across a rail - same rule as mixing module vendors, for the same reason: alarm thresholds and telemetry behavior drift between versions.

What CMIS does not solve

Three boundaries are worth stating so nobody oversells it:

• Interoperability. CMIS defines the conversation, not the outcome. Two compliant modules can still disagree with a host in subtle ways; that is what qualified-module lists are for.
• Physical quality. No interface makes a dirty MPO connector cleaner. Optical problems still live in the fiber plant.
• Vendor extensions. Everything proprietary still lives behind vendor-specific pages. CMIS standardizes the floor, not the ceiling.

Sources

• QSFP-DD MSA - CMIS documentation - the Common Management Interface Specification (revision history, state machine and VDM framework).
• OSFP MSA - management and mechanical context for OSFP-family modules using CMIS.
• OIF - CMIS-LT project - link training extensions building on CMIS for 800G and beyond.
• IEEE 802.3df Task Force - the 800G PMD amendments whose modules CMIS manages; useful for seeing where the standard ends and the management interface begins.

Implementation details vary by CMIS revision and vendor. Verify state names, VDM availability and firmware behavior against the exact specification revision your modules implement.

FAQ

Is CMIS the same thing as the QSFP-DD or OSFP MSA?

No. The MSAs define the mechanical and electrical envelope; CMIS is the management interface specification published through the same industry group and used across QSFP-DD, OSFP and other 100G-per-lane modules. A module has a form factor and it runs CMIS - the two answer different questions.

What is the minimum CMIS version to look for when buying?

CMIS 4.0 is the practical floor for 800G purchases: it matured the datapath state controls and lane diagnostics that breakouts and scriptable diagnostics depend on. Version 5.x adds refinements in telemetry and firmware handling. Older 400G parts with 3.x-era implementations can behave inconsistently across vendors.

What is a VDM in one sentence?

A Vendor Defined Mechanism: a standardized container for module measurements that the standard does not fix in advance - things like per-lane pre-FEC bit error counts - so vendors can expose real diagnostics without breaking the interface.

Can a CMIS firmware update fail and brick a module?

A proper implementation updates an inactive firmware image and swaps on commit, so an interrupted update leaves the running image intact. The operational risk is not bricking a single module; it is pushing an uncommitted or mismatched image to a fleet and only noticing at the next reseat.

Does CMIS apply to 100G and 400G modules too?

Yes. CMIS is speed-agnostic and appears on 100G-lane modules of several form factors. It matters most at 400G and above because that is where multi-lane datapaths, power classes and breakouts make the old fixed-register model unworkable.