QSFP28 Compatibility: MSA, EEPROM, FEC & Support

On paper, choosing a QSFP28 transceiver looks like a checklist: match the speed, wavelength, connector, reach and fiber type, then push the module into a 100G port. In a lab, that is often enough. In a production fabric, it is not.

A QSFP28 module can be fully MSA-compliant, hit the right optical reach, use the correct connector, and still be rejected by the switch the moment you insert it. Another module brings the link up cleanly but reports no optical power, throws intermittent alarms, accumulates FEC errors, or quietly changes behavior after a firmware upgrade. None of those failures show up on a datasheet comparison.

This guide explains how 100G QSFP28 compatibility actually works, what to verify before you buy, and how to lower deployment risk across Cisco, Arista, Juniper, Dell, NVIDIA/Mellanox and white-box/SONiC environments.

What Decides QSFP28 Compatibility

QSFP28 compatibility is not a single yes-or-no condition. A module works in your network only when several layers all pass: the form factor fits the QSFP28 cage, the EEPROM coding matches what the switch expects, the switch firmware recognizes and enables the module, the FEC mode and breakout configuration agree on both ends, the DOM/DDM data is readable by your monitoring tools, and the vendor support policy allows the module in your operational process. Skip any one of these and a module that "matches the spec" can still fail in the field. The rest of this guide walks each layer and shows how to test it.

What QSFP28 Compatibility Really Means

It helps to treat compatibility as four stacked layers. A module can clear the first and still fail one of the others, which is exactly why "MSA-compliant" alone tells you very little about production behavior.

• MSA compliance - the module follows the common form factor, electrical and management-interface expectations.
• Switch compatibility - the host device recognizes, enables and monitors the module.
• Link interoperability - both ends negotiate a stable 100G link with matching speed, FEC and lane settings.
• Operational compatibility - the module behaves predictably with your firmware, monitoring stack, support process and spare-inventory plan.

Physical fit and MSA compliance

At the lowest layer, the module has to mate mechanically and electrically with the QSFP28 cage and speak the expected low-speed management interface. This is what MSA compliance covers. The QSFP28 form factor is defined by the SFF/SNIA SFF-8665 specification, which standardizes the mechanical envelope, latching, host connector and management interface so modules and cages from different makers can interoperate.

What MSA compliance does not guarantee is that every switch vendor will fully accept the module. Mechanical and interface conformance gets the module into the port; it does not decide whether the operating system treats it as a first-class, fully monitored optic. QSFP28 shares its mechanical baseline with later QSFP variants such as QSFP-DD, so the cage fit alone is a weak signal of support - see this QSFP-DD technical overview for how the form factors relate.

Host recognition and EEPROM coding

Every QSFP28 module carries identification and diagnostic data in a small EEPROM that the switch reads on insertion: vendor name, part number, serial number, power class, supported capabilities, wavelength, reach, DOM/DDM fields and checksums. Many switches use this data to decide how to treat the optic.

An optically perfect module can still appear as unsupported, unknown, or only partially monitored if its EEPROM profile is not what the switch is looking for. This is why third-party suppliers sell Cisco-compatible, Arista-compatible, Juniper-compatible and Dell-compatible versions of the same optical type: the optical engine may be identical, but the EEPROM coding is written to match a specific platform family. Vendor coding is, in practice, the single most common reason an otherwise correct QSFP28 module is accepted or refused.

Link interoperability, FEC and monitoring

Recognition is not the finish line. After the switch accepts the module, the link still has to come up and stay up. That depends on speed configuration, FEC mode, breakout mode, fiber type, polarity, distance, optical power levels, and whether the opposite end uses matching settings. Forward Error Correction in particular is governed by the relevant IEEE 802.3 Ethernet standards, and different 100G optical types expect different FEC behavior - a point we return to below.

Because of this, a link-up test on its own is not a compatibility test. A real acceptance check verifies inventory detection, DOM/DDM readings, traffic stability and error counters together, not just whether the interface line goes green.

The 100G QSFP28 Optical Types and How They Differ

"QSFP28" describes the form factor, not the optics. The 100G optical type inside drives the connector, fiber, lane structure, FEC expectation and breakout behavior - and therefore a large part of the compatibility story. Treating SR4 and DR1 as interchangeable because both are "100G QSFP28" is a frequent mistake.

Two practical takeaways follow from this table. First, the 4x25G family (SR4, PSM4, CWDM4, LR4) is mature and broadly supported, but only the parallel types (SR4, PSM4) are realistic 4x25G breakout candidates, and breakout still depends on the platform. Multimode reach for SR4 hinges on the cabling grade, so confirm your plant against the OM1–OM5 distance limits; for the single-mode types, the fiber grade matters too, which is covered in this OS1 vs OS2 comparison. CWDM4 and LR4 combine four wavelengths onto a single duplex pair, the principle described in this primer on WDM multiplexing.

Second, the single-lambda family (DR1, FR1, LR1) puts the full 100G on one wavelength and is more sensitive to FEC settings and firmware support than the older 4x25G designs. A platform that happily runs LR4 may need a newer software release, or a different FEC default, before it will bring up an FR1 or LR1 link. If you are deploying single-lambda optics, treat firmware support as a hard gating requirement rather than an afterthought.

Why a QSFP28 Module Fails in a "Compatible" Port

When a 100G link misbehaves, the transceiver gets blamed first. More often the real cause is a mismatch between the module, the switch firmware, the port configuration, or the cable plant. Four failure modes cover the large majority of cases.

The switch rejects the module ID

Some platforms validate the optic's identity before they enable the port. If the EEPROM data does not match an expected profile, the symptoms are recognizable: an unsupported transceiver entry in the log, the interface stuck down, or the port driven into an error-disabled state. Correct vendor coding removes most of this, but coding alone does not let you skip testing the exact switch model and software version, because validation tables differ between platforms and releases.

The link settings do not match

A module can be recognized and still refuse to link. The usual culprits are a speed mismatch, an incorrect or mismatched FEC mode, an unsupported breakout configuration, the wrong port mode, a transceiver type the specific line card or port group does not support, or an incompatible module on the far end. FEC mismatches are especially common on single-lambda DR1/FR1/LR1 links, where one side defaults to RS-FEC and the other does not, so the link either never comes up or comes up with a rising FEC-correction count.

DOM/DDM is incomplete or wrong

Digital Optical Monitoring (DOM/DDM) exposes optical transmit and receive power, temperature, supply voltage and laser bias current. In production it is what makes a degrading link visible before it drops. A third-party QSFP28 module can pass traffic while reporting DOM badly, and the failure looks specific: receive power shows N/A, the temperature value is frozen at a fixed number, the fields are present in the CLI but your SNMP or telemetry poller cannot read them, or thresholds never trip because the alarm flags are not populated. That is tolerable on a bench and a real operational gap in a monitored fabric. If DOM matters to your operations team, it belongs in the acceptance test, not the wish list.

Firmware changes validation behavior

Switch firmware decides how optics are detected, parsed and validated, and that logic changes between releases. A module that runs perfectly on one version can behave differently after an upgrade - the change may touch EEPROM validation, DOM parsing, FEC defaults, breakout support, or the supported-transceiver table itself. Before any major firmware upgrade, validate at least one sample of every deployed QSFP28 type on the target release rather than assuming continuity.

QSFP28 Compatibility by Switch Vendor

These notes are planning guidelines, not guarantees. Compatibility is model-, line-card- and release-specific, so confirm the exact combination before buying at scale. Where a vendor publishes an official compatibility tool, use it as the first reference.

Cisco

Cisco platforms tend to be stricter with non-Cisco optics than many enterprise switches, and Cisco states plainly that it does not support third-party optics as part of its entitlement policy. A non-Cisco-coded module may be reported as unsupported or require platform-specific handling depending on the Nexus or Catalyst model and the NX-OS or IOS-XE release. Start from the official Cisco Transceiver Module Group (TMG) compatibility matrix to confirm which optics are listed against your exact device.

Do not buy Cisco-bound QSFP28 modules by optical type alone - a 100G LR4 that works in one Nexus platform may behave differently in another. Before volume purchasing, confirm the exact model, the NX-OS/IOS-XE version, the required Cisco-compatible coding, DOM/DDM behavior, breakout and FEC support, and your support stance on third-party optics. On the box, show interface transceiver detail is the quickest way to confirm recognition and read DOM. Treat Cisco-compatible modules as something you test on the target software, not something you assume because the optical spec lines up.

Arista

Arista switches are generally more permissive with well-built third-party optics than the strictest platforms, and in many EOS environments properly coded QSFP28 modules come up without lockout behavior. That is a tendency, not a free pass. EOS version, switch family, optical type, DOM behavior, power class and port configuration still affect the outcome, and high-power long-reach optics, breakout applications and newer single-lambda modules still warrant testing. Verify recognition and DOM with show interface transceiver, and confirm FEC, breakout behavior, and the thermal/power envelope for long-reach parts.

Juniper

Juniper behavior depends heavily on the exact platform, the Junos release, the port type and the transceiver identifier - a module accepted and fully monitored on one QFX, MX or PTX may not be on another. Check the official Juniper Hardware Compatibility Tool for your target platform; it also flags whether a given optic supports monitoring. Note that JTAC does not provide support for third-party optical modules, so factor that into your support plan. On the device, show interfaces diagnostics optics returns the DOM readings. Verify the platform, Junos release, the PID or compatible EEPROM profile, DOM support, breakout support, and whether the newer DR1/FR1/LR1 types are supported on that hardware.

Dell PowerSwitch

Dell PowerSwitch platforms can be sensitive to EEPROM fields, DOM parsing and software behavior, and some third-party modules pass traffic while showing warnings, incomplete DOM data, or inventory mismatches. Confirm the OS10 or SONiC version, Dell-compatible coding, DOM/DDM readings, the platform's supported-optics list, FEC and breakout requirements, and the behavior across a firmware upgrade. If Dell switches sit in a production fabric, validate the module on the same software build before placing a large order.

NVIDIA / Mellanox

NVIDIA/Mellanox environments are among the more restrictive, particularly in AI, HPC, Ethernet and InfiniBand fabrics where validated interconnects are the norm. Here link stability depends not only on optical reach but on signal integrity, firmware support, FEC behavior and platform validation; a module can be detected and still fail to bring up the link if the platform does not accept it or the settings are unsupported. NVIDIA documents its qualified interconnects on the LinkX cables and transceivers pages, and notes that unqualified third-party devices may work but carry no performance guarantee. Confirm the exact switch and adapter model, Ethernet vs InfiniBand mode, firmware version, the validated cable/module list, FEC requirements, reach and type, and supplier validation against the same platform. For mission-critical AI or HPC fabrics, prefer validated optics or thoroughly tested compatible alternatives.

SONiC and white-box switches

SONiC and white-box switches are usually more open than traditional OEM platforms, but "open" is not "universal." Results depend on the switch ASIC, platform driver, NOS build, EEPROM parser, transceiver-management service, breakout mode and port configuration. A module may link up but report incomplete inventory or DOM data - acceptable in some cost-sensitive or lab settings, not in production fabrics that need accurate monitoring and asset tracking. Test the exact switch model and NOS build rather than assuming all MSA-compliant modules behave alike.

Vendor-Coded vs MSA-Compliant vs Programmable QSFP28 Modules

The right module class depends on your environment, risk tolerance and inventory strategy.

Vendor-coded QSFP28 modules

Vendor-coded modules carry EEPROM data written to match a specific switch vendor or platform family. They are usually the safest choice for production: more predictable recognition, better DOM/DDM behavior, and fewer support complications. Reach for them when you are deploying at scale, the network is production-critical, you run Cisco/Juniper/Dell/NVIDIA platforms, monitoring accuracy matters, or you want to avoid unsupported-module surprises. The trade-off is maintaining separate inventory per switch vendor.

Generic MSA-compliant QSFP28 modules

Generic MSA modules can be fine in open environments, labs, test networks and white-box deployments where strict vendor recognition is not required. They cut upfront cost and simplify a generic optical inventory, but they carry more risk in restrictive switch environments. When not to use them: in a Cisco/Juniper/NVIDIA production fabric, anywhere DOM/DDM accuracy is a monitoring requirement, on single-lambda links with tight FEC/firmware dependencies, or where your support process will ask you to reproduce faults on qualified optics. Do not assume one generic MSA module crosses Cisco, Juniper, Dell and NVIDIA platforms without validation.

Programmable QSFP28 modules

Programmable modules can be recoded for different vendor profiles with a compatible tool, which is genuinely useful for multi-vendor networks, emergency spares and field-service teams. They reduce the need to stock fixed-coded modules for every platform, but they demand process control: trained staff, accurate relabeling after programming, and a clear validation step. The main risk is a module recoded or labeled for the wrong target switch.

How to Choose the Right QSFP28 Module

Map the decision to your scenario rather than to the cheapest line item. The matrix below is the short version.

How to Test QSFP28 Compatibility Before Deployment

The safest path is to qualify samples before buying in volume. Five steps make the test repeatable.

Step 1 - Order samples for every vendor and type

For each switch vendor and module type you intend to deploy, order a small sample. If the network spans Cisco, Arista and Juniper, qualify on all three; do not test one platform and assume the result generalizes.

Step 2 - Verify detection

Insert the module and confirm the switch identifies it correctly: vendor/part-number recognition, correct speed capability, correct transceiver type, DOM/DDM availability, no unsupported-module alarm, and no error-disabled state. If it shows as unknown or unsupported, determine whether the cause is EEPROM coding, firmware support, or platform policy before going further.

Step 3 - Build a real link

Connect to the intended far-end device or a representative stand-in and verify link-up status, correct speed, correct FEC mode, transmit and receive power within range, clean error counters, and stability after both an interface bounce and a physical reseat. A module that is detected but cannot hold a link is not production-ready.

Step 4 - Run traffic

Pass traffic for a meaningful window - a few hours minimum, longer for critical fabrics - and watch CRC errors, FEC-correction counts, link flaps, temperature alarms and packet loss. For critical environments, test under realistic load and at the temperatures the optic will actually see.

Step 5 - Document the approved configuration

For each approved module, record the supplier part number, EEPROM coding target, switch model, firmware version, port type, FEC mode, breakout mode, the test result, and DOM/DDM status. That record becomes your internal compatibility matrix and saves the next person from re-running the whole exercise.

Acceptance criteria

Use an explicit pass/fail bar so "it seemed fine" never decides a purchase.

Field note: where these tests earn their keep

A representative example seen across mixed fabrics: a batch of generic 100G SR4 modules passes a quick link-up test and goes into a leaf-spine layer. The native 100G ports are fine. Weeks later, an attempt to reconfigure some of those ports for 4x25G breakout fails on one port group - the modules are healthy, but that line card's breakout support and FEC defaults were never validated for that mode. Separately, after a routine firmware upgrade, DOM readings on the same modules start returning N/A because the new release parses their EEPROM differently. Neither problem is an optical defect; both would have been caught by a breakout check and a post-upgrade DOM check in the steps above. The cost of skipping qualification shows up later, as a change-window failure and a monitoring blind spot, rather than at purchase.

Conclusion

QSFP28 compatibility is decided by far more than speed and reach. The switch platform, firmware version, EEPROM coding, FEC settings, breakout support, DOM/DDM behavior and your operational support plan all sit between a datasheet match and a stable 100G link. The optical type inside the module - 4x25G versus single-lambda - shifts those requirements again.

For most production networks, vendor-coded or platform-validated QSFP28 modules are the lowest-risk choice; for mixed-vendor estates, programmable modules can keep spare inventory manageable when the recoding process is controlled. The operating rule is short: verify the exact model and firmware before you buy, qualify samples against an explicit pass/fail bar before you deploy, and write down every approved module-and-platform combination so the next deployment starts from evidence instead of assumption.