Compatibility matrices, release notes & firmware changes

"Supported" is a statement about a triple: this module, in this platform, on this software release. Vendors publish that triple in compatibility matrices and release notes, and they change it — new optics appear, old ones drop off, checks get stricter. Reading the matrices before buying and re-reading them before upgrading is the cheapest compatibility work there is. This page shows where the information lives, how to read it, and how to run a fleet so that a software upgrade does not turn into an optics outage.

Where vendors publish support

Vendor	Resource	What it lists
Cisco	Transceiver Module Group (TMG) Compatibility Matrix; per-platform data sheets	PN ↔ platform ↔ minimum software; port restrictions
Juniper	Hardware Compatibility Tool (HCT)	optic PN ↔ platform ↔ Junos release, speeds, DDM support
Arista	Transceiver and Cable Guide (PDF/online)	PN, PMD, reach, supported platforms per EOS
Huawei	Hardware Center / product compatibility lists	optical module codes per switch model
H3C	Transceiver Module Compatibility Matrix	per product family
HPE Aruba	Transceiver Guide, QuickSpecs	J/R numbers per switch family and firmware
Dell	Networking Optics/Cables support matrix	SKU ↔ platform ↔ OS10 release
Nvidia/Mellanox	LinkX product pages, Cumulus/Onyx release notes, InfiniBand firmware notes	cable/transceiver PN ↔ switch/HCA ↔ firmware
Extreme, Ruckus	transceiver compatibility guides	per platform
Brocade (SAN)	FOS release notes, supported optics list	branded SFP PNs per FOS version
SONiC / white-box	platform vendor's hardware compatibility list, community wiki	tested optics per platform; often community-maintained
NIC vendors	Intel/Broadcom/Mellanox adapter compatibility lists	supported modules and driver versions

Also read the release notes of the NOS version you run: optics changes hide under "resolved issues", "behaviour changes" and "new hardware support".

Reading a matrix entry

Column	Meaning	Watch for
Part number	the exact string the switch expects in the module (Part numbering)	grade suffixes (`-S`, `-I`, revision letters) treated as distinct PNs
Platform / port	which chassis, line card or port range	uplink-only, "ports 49–52 only", not on breakout ports
Minimum software	first release with support	a newer PN on an older release = unsupported even though branded
Speeds / modes	which rates and breakouts the PN supports on that port	4×25G breakout supported on some platforms only
DDM / DOM	whether diagnostics are exposed	"DOM not supported" on certain combinations
Notes	temperature, reach, FEC requirements, EOL	end-of-sale dates and successor PNs

What changes with software

Change	Effect on optics	Seen as
New or stricter identity validation	previously tolerated third-party or coded modules rejected	ports errdisabled after upgrade (How each NOS validates a module)
Hidden override command removed or renamed	`service unsupported-transceiver` no longer accepted	configuration fails to load, ports down
CMIS handling improved or changed	400G+ modules that needed workarounds now work, or vice versa	modules stuck in LowPwr (CMIS issues)
FEC/AN defaults changed	links that relied on old defaults fail	link down with good levels (FEC & AN)
DDM polling or threshold handling changed	alarms appear or disappear	new syslog noise or silence
Optics PN reaches end of support	still works, no longer listed	future tickets closed as "unsupported"
Module firmware update bundled	vendor-branded modules get new firmware	behaviour changes on the module side (Controller & firmware)

A fleet practice that avoids surprises

Inventory — record vendor, PN, serial, revision and firmware of every module per port (from the switch or from the bench) in the CMDB.
Pin releases — treat the NOS version as part of the compatibility triple; do not upgrade access and core on the same day.
Read release notes for optics-related items before every upgrade.
Test on a lab or canary switch with one of every optics type you run — third-party and coded modules first.
Keep the previous image and a rollback plan; know which ports are errdisable-prone.
Baseline DDM before and after so behaviour changes in monitoring are visible (Monitoring).
Track EOL of optics PNs and their successors so replacements match the matrix.

Third-party and coded optics in this picture

A module coded to an OEM PN is judged by the same matrix entry as the original — the platform cannot tell the difference if the coding is complete — but the vendor's support statement does not extend to it, and a stricter check in a new release can expose it. Keep coded modules identifiable in the inventory (their real vendor and serial), test them first on upgrades, and plan for the case where a release closes the door (Third-party optics, Vendor lock).

NIC and server side

Server adapters have their own matrices (adapter ↔ module ↔ driver/firmware) and their own policies — some Intel families refuse unlisted SFPs unless a driver parameter allows them; Mellanox/Nvidia adapters validate cables for InfiniBand. Driver and firmware updates change these rules just as NOS upgrades do (Port configuration recipes).

In CodingBox

The bench side of the fleet practice: read every module's identity and firmware version into the code database at incoming inspection, compare a suspect module's bytes against the matrix entry on Check transceiver, and keep the coded/original distinction in the database notes so an upgrade-day rejection can be traced to the module in seconds.

NIC driver and firmware policies in detail, by vendor and operating system: Transceiver compatibility on NICs.

The fleet practice as a commissioning checklist — upgrade before configuring, canary tests, DDM baseline, acceptance test: Selecting & commissioning.