3f44322a2b
45 expert articles covering: Cisco/Juniper/Arista optic compatibility mechanics, 100G/400G/800G optics selection, DWDM/ROADM/WSS architecture, fiber standards, coherent pluggables, AI cluster optics, carrier timing, EEPROM programming, market pricing 2026, hyperscale procurement, transceiver failure analysis, and more.
88 lines
7.8 KiB
Markdown
88 lines
7.8 KiB
Markdown
---
|
||
title: "Cisco QSFP-28 Compatibility Enforcement: What NX-OS and IOS-XE Actually Check"
|
||
slug: "cisco-qsfp28-compatibility-list-nxos-iosxe"
|
||
type: deep-dive
|
||
category: "Vendor Compatibility"
|
||
tags: ["Cisco", "QSFP28", "NX-OS", "IOS-XE", "100G", "third-party optics", "compatibility"]
|
||
seo_focus_keyword: "Cisco QSFP28 compatibility NX-OS IOS-XE"
|
||
---
|
||
|
||
Every few months someone opens a ticket with us because their third-party QSFP-28 works fine in a Nexus 9300 but refuses to initialize in a Catalyst 9500. Same optic, same manufacturer, same part number. The answer is rarely simple, but there's a consistent logic underneath it once you understand what Cisco's compatibility stack actually checks at each layer.
|
||
|
||
## The PID Check and What It Covers
|
||
|
||
Cisco's transceiver enforcement begins with the Product ID (PID) string stored in the EEPROM at byte offset 168 of SFF-8472 (for SFP+) or in the Vendor Name/Vendor PN fields in SFF-8636 (for QSFP28). When a Cisco platform recognizes a transceiver, it queries the Vendor Name (bytes 148–163) and Vendor Part Number (bytes 168–183). It then performs a lookup against a compatibility matrix that is maintained in the platform's ROMMON/firmware and updated with software releases.
|
||
|
||
The PID check itself has two modes depending on platform and software version. On older NX-OS releases — 7.x and early 9.x — it was essentially a hard block: if the PID wasn't in the table, the port came up in err-disabled state or the transceiver showed as "not supported." On NX-OS 9.3(5) and later, Cisco introduced a tiered approach where unrecognized PIDs generate a syslog warning but don't necessarily disable the port. The behavior varies by line card, though, and that's where things get complicated.
|
||
|
||
## NX-OS: Checking What You've Got
|
||
|
||
On a Nexus platform, the canonical command for transceiver status is:
|
||
|
||
```
|
||
show interface ethernet 1/1 transceiver
|
||
```
|
||
|
||
This gives you the basic DOM (Digital Optical Monitoring) readout: temperature, voltage, TX/RX power, and bias current. More useful for compatibility diagnosis is:
|
||
|
||
```
|
||
show interface transceiver details
|
||
```
|
||
|
||
And on newer platforms, specifically for the compatibility state:
|
||
|
||
```
|
||
show hardware internal dev-port-map
|
||
```
|
||
|
||
But the most directly useful command when you're troubleshooting a compatibility failure is:
|
||
|
||
```
|
||
show interface ethernet 1/1 transceiver details | include supported
|
||
```
|
||
|
||
The output will tell you whether the optic is in one of three states: "calibrated and DOM-monitored," "unsupported transceiver type," or—the ambiguous one—"calibrated but unsupported." That last state means the module is electrically functional, DOM is readable, but Cisco won't commit to supporting it.
|
||
|
||
For IOS-XE platforms (Catalyst 9000 series), the equivalent is:
|
||
|
||
```
|
||
show interfaces GigabitEthernet0/0/0 transceiver
|
||
show interfaces transceiver supported-list
|
||
```
|
||
|
||
The `supported-list` command is genuinely useful: it outputs the PIDs in the platform's compatibility table for your specific chassis and line card combination, which saves the guesswork.
|
||
|
||
## Why the Same Optic Behaves Differently Across Line Cards
|
||
|
||
This is where most network engineers get confused. Cisco's compatibility matrix isn't monolithic—it's per-platform-per-ASIC. A Nexus 9300-EX line card uses a Cisco custom ASIC (referred to as Cloudscale in their documentation) with different firmware than the older Nexus 9300 non-EX cards running Trident-based ASICs. Each has its own compatibility table, and those tables are updated on different cadences.
|
||
|
||
The practical implication: a 100GBASE-SR4 QSFP-28 from a Flexoptix-programmed module (properly coded with the right OUI and vendor strings for Cisco compatibility) may work perfectly in a Nexus 93180YC-FX but generate a "transceiver type not supported" on a Nexus 9564PX. The difference isn't the optic—it's that the 9564PX's line card firmware has a more restrictive compatibility table that was updated in NX-OS 9.3(7) to add support for that particular PID string.
|
||
|
||
On Catalyst 9500 and 9600 platforms running IOS-XE, the ASICs are again different (Cisco Silicon One in the 9600 series), and the validation logic is embedded partly in the FPGA bitstream. Firmware-level updates to IOS-XE 17.x progressively loosened some of the stricter checks, but the 9600 series running 17.3.x still rejects certain third-party optics that work fine on 9500 platforms at 17.6.x.
|
||
|
||
## The Bypass Approach: What Works and What Doesn't
|
||
|
||
Cisco doesn't officially document a "third-party optic bypass" for NX-OS or IOS-XE in the same way Juniper documents `no-ddmi` or Arista offers `xcvr-unsupported-digital-data`. For NX-OS, the closest thing is the `service unsupported-transceiver` global command, which has been available since NX-OS 7.0(3)I6(1):
|
||
|
||
```
|
||
switch(config)# service unsupported-transceiver
|
||
```
|
||
|
||
This command doesn't disable the PID check entirely—it changes the platform's response from hard failure to soft warning. The port will come up, DOM data will be displayed, but the syslog will log `%PLATFORM-5-UNSUPPORTED_TRANSCEIVER` repeatedly. Depending on your NOC's alerting, this can get noisy fast.
|
||
|
||
On IOS-XE, there's no equivalent global override. The platform will either accept the optic or it won't. Cisco's position is that IOS-XE platforms require transceivers in the compatibility list. In practice, the compatibility list is updated frequently enough in major 17.x releases that this becomes a software management problem: if a third-party optic doesn't work, upgrading the platform software from 17.6 to 17.9 sometimes adds support without any other changes.
|
||
|
||
## DOM Thresholds and False Alarms
|
||
|
||
Even when a third-party QSFP-28 gets past the PID check, you can still end up with spurious threshold violations. Cisco's DOM display reads the standard SFF-8636 threshold fields, but then applies additional platform-level sanity checks. If the EEPROM thresholds in your optic are set too broadly—say, a receive power high-alarm threshold of +3 dBm when the link is running at -2 dBm—Cisco platforms will sometimes generate alarm conditions even though the optical power level is perfectly normal for the application.
|
||
|
||
The fix here is at programming time, not configuration time. If you're sourcing compatible third-party QSFP-28s, the EEPROM vendor strings and DOM threshold fields need to be programmed appropriately for the target platform. A well-programmed Cisco-compatible QSFP-28 SR4 should have its EEPROM Vendor Name field set to "CISCO-FLEXOPTIX" (or the appropriate OUI), TX/RX power thresholds consistent with the SR4 application (high alarm at +2.4 dBm, low warning at -7.3 dBm, per the 802.3bm spec), and the connector type byte set to 0x0C (MPO-12).
|
||
|
||
## Practical Checklist Before You Deploy
|
||
|
||
Before inserting a third-party QSFP-28 into a Cisco platform, it's worth taking 90 seconds to verify: first, check whether `service unsupported-transceiver` is already configured globally (some operators enable this as a matter of policy); second, verify your NX-OS or IOS-XE version against the transceiver vendor's compatibility matrix—this should be explicit, not implied; third, run `show platform` to confirm which ASIC generation your line card uses, since the same chassis can have multiple generations of line cards with different compatibility tables.
|
||
|
||
If a third-party optic fails after all that, pull it out and re-examine the EEPROM content with an SFF-8636 reader before assuming the optic is defective. Nine times out of ten, the PID string or vendor name field doesn't match what the platform's firmware expects, and that's a reprogramming problem, not a hardware problem.
|
||
|
||
The other 10 percent of the time, it's a genuine hardware compatibility issue—usually a CDR (Clock and Data Recovery) circuit that doesn't meet Cisco's internal PHY requirements for a specific ASIC. In those cases, no amount of EEPROM programming will fix it, and the right answer is a different SKU.
|