Third-Party Optics: What Actually Works
The internet's version of this topic is mostly wrong in both directions. There is no cryptography in a transceiver EEPROM — and third-party modules still cause real problems, for a reason almost nobody names correctly.
What a switch actually reads
A transceiver identifies itself through an I²C EEPROM. Which fields, and where, is set by the relevant MSA — SFF-8472 for SFP, SFF-8636 for QSFP+/QSFP28, and CMIS for QSFP-DD, OSFP, QSFP112 and 800G.
In SFF-8636 the identity lives in a handful of plain ASCII fields on page 00h:
| Bytes | Field |
|---|---|
| 148–163 | Vendor Name — 16 ASCII, space-padded |
| 165–167 | Vendor OUI — IEEE Company ID |
| 168–183 | Vendor Part Number — 16 ASCII |
| 196–211 | Vendor Serial Number — 16 ASCII |
The MSA's entire identity requirement is one sentence, from SFF-8636 Rev 2.12 §6.3.14:
"At least one of the vendor name or the vendor OUI fields shall contain valid serial data."
That is it. No signature, no certificate, no key. "Coding" a module means writing ASCII into those bytes and correcting the two checksums. Anyone describing it as cracking or circumventing something has misunderstood the format.
The real reason third-party optics get a bad name
Here is the part that matters, and it is not vendor lock.
On SONiC, the vendor name and part number read from the EEPROM are used as a lookup key into a media-settings table that selects SerDes pre-emphasis and equalisation for that port. The documented lookup order tries a global range, then a vendor key (vendor name plus part number), then a media key (media type plus compliance code plus length), then port-level settings, and finally Default.
So the EEPROM string does not gate acceptance. It selects tuning. A module whose vendor/PN string matches nothing in the table is not rejected — it silently receives generic SerDes settings. On a clean short channel that is fine. On a marginal one it is precisely how you manufacture intermittent link flap and elevated pre-FEC error rates.
That is the actual mechanism behind "third-party optics are flaky", and it explains why the same module can be flawless in one deployment and troublesome in another. It also means coding to the platform's expected string has a genuine engineering payoff beyond simply being recognised — which is a claim worth making precisely because it is falsifiable.
Platform behaviour differs more than people assume
Cisco
The global-config command service unsupported-transceiver takes no arguments. It is a supportability gate rather than a cryptographic lock. The exact failure mode without it varies by platform family and release — on some it is a syslog warning, on others the port is held down — so verify against your specific NX-OS or IOS-XR version rather than trusting a blanket claim in either direction.
Arista
Arista has a command with the same name and it is not the same thing. On EOS it takes two arguments — a licence name and a licence key:
service unsupported-transceiver <license_name> <license_key>Both values are emitted into the running configuration, which tells you what it is: an acknowledgement and liability mechanism, not encryption. But it does mean you need something issued to you, which a Cisco-shaped assumption will not prepare you for.
SONiC
The clean counterexample. The CMIS driver reads vendor name, part number, serial, revision, date, OUI and full diagnostics, and contains no vendor allowlist and no blocking logic at all. Any CMIS-compliant module is accepted regardless of who made it — which is why the SerDes tuning point above is the one that matters on SONiC, not acceptance.
NVIDIA, and a distinction worth respecting
We were not able to verify NVIDIA's current documented behaviour for Onyx or Cumulus, so we are not going to characterise it. Treat it as requiring bench verification on your specific NOS build.
One thing is worth saying plainly though: InfiniBand is a materially different proposition from Ethernet here. Link training and the cable-parameter database are tighter on Quantum-class InfiniBand fabrics, and third-party InfiniBand optics are a considerably weaker bet than third-party Ethernet optics. If your fabric is InfiniBand, the honest advice is to stay with validated modules.
Does coding affect diagnostics?
No — and the reason is structural. DOM values are produced by the module's own ADC and written by its own firmware into page 00h bytes 22–33 and 34–81. The identity strings live at 148–183, in a different region, and are read-only descriptive ASCII. Rewriting them cannot change what the ADC reports.
Two caveats that the confident version of this claim usually omits:
- Accuracy belongs to whoever made the module. SFF-8636 requires only "better than ±3 °C" on temperature and "better than ±3%" on supply voltage. Coding does not change that in either direction.
- The alarm thresholds are vendor-populated too — page 03h, bytes 128–223. A module with copied or sloppy threshold tables reports correct readings inside a wrong alarm envelope, so monitoring never fires. That is a genuine third-party failure mode and it is much less discussed than it should be.
Also worth knowing: SFF-8636 marks temperature as required only for single-mode modules, and marks Vcc, Rx power, Tx bias and Tx power as optional for every module class. Missing DOM fields are permitted by the MSA — they are a module design decision, not a fault.
FEC: the one real link between coding and stability
The Linux ethtool API defines an AUTO FEC mode, and its own header is explicit about what that means:
"Select default/best FEC mode automatically, usually based link mode and SFP parameters read from module's EEPROM. This bit does not mean autonegotiation."
So a differently-coded module can land in a different FEC default. That is the honest, mechanistic connection between coding and link stability — not a vendor conspiracy, a driver heuristic reading the EEPROM.
Two corrections while we are here, because the internet's FEC advice is largely legacy:
- At 400G and 800G there is nothing to misconfigure. RS(544,514) is built into the 400GBASE-R PCS. It cannot be turned off. A UI offering "FEC off" on a 400G port is offering you a broken link.
- "100G always uses FEC" is wrong. 100GBASE-LR4 and ER4 run clean NRZ over CWDM and use none. Forcing RS-FEC on a port facing an LR4 optic is a self-inflicted outage. FEC negotiation is a 25G and 100G-NRZ conversation.
And the operational point that matters most: watch pre-FEC error rate, not post-FEC. Post-FEC is zero right up until it isn't — RS-FEC goes from correcting everything to failing catastrophically across well under a decade of BER. A marginal module shows up as elevated pre-FEC error rate with clean interface counters, which is invisible to ordinary monitoring until an ambient temperature rise pushes it over the cliff. Third-party optics rarely fail by not working. They fail by quietly consuming FEC margin.
Two things your vendor's FAQ probably gets wrong
Magnuson-Moss does not apply to you
Optics resellers routinely cite the Magnuson-Moss Warranty Act's anti-tie-in provision as proof that third-party modules cannot void a switch warranty. That act governs consumer products — property normally used for personal, family or household purposes. A data centre switch is not a consumer product, and the statute does not reach it. If a supplier's FAQ leans on Magnuson-Moss, they have not checked.
The actual risk is support friction, not a voided warranty
In practice the major vendors do not void hardware warranties over a third-party optic. What they do is decline to support the optic, and reserve the right to ask you to reproduce a fault with a qualified module before escalating. That is a real cost, and it is a different cost from the one people fear. Budget for a support-escalation step, not for losing your switch warranty.
Coding to be recognised is not coding to impersonate
Writing a vendor string so a switch applies the right tuning and brings the port up is ordinary interoperability work. Writing an OEM's name, part number and a plausible serial in that OEM's format, on a module that also physically bears their mark, is something else entirely — that is use of a mark in commerce, and it is where real legal exposure sits.
The line is worth stating out loud rather than leaving implied, because the industry is casual about it and buyers deserve to know which side of it their supplier stands on.
None of this is legal advice. If third-party sourcing is material to your build, get your own counsel's read.
What we will and won't tell you
TORmem sources optics and specifies them as part of rack integration, so we have a position here. Here is what we think a supplier can honestly say:
- The module is MSA-compliant, and programmed to be recognised by a named platform on a named software version.
- It was bench-verified on that platform for link-up, diagnostics read-back and pre-FEC error rate, and soaked at temperature.
- Its SerDes profile is matched to the target platform, which is the difference between a link that works and a link that works in July.
- Support for the module is the supplier's. That is the claim that actually carries weight.
And what nobody can honestly say:
- "100% compatible." It is unfalsifiable, and one NOS upgrade can make it false.
- Anything about what an OEM's warranty will or won't cover. No third party can make representations about someone else's contractual obligations to you.
A supplier who concedes the second list is more trustworthy on the first one.
Related
- AI cluster networking — transceivers by rate, and the full symptom index
- Link flap — where FEC margin and SerDes tuning show up as lost training time
- TORswitch — 32-port 100G AI network switch