transceiver-db/blog-training-data/blog-057-juniper-optic-unlock-ex-qfx.md

title	slug	type	category	tags	seo_focus_keyword
Juniper EX vs QFX Optic Behavior: Why the Same Transceiver Works on QFX5100 but Alarms on EX4600	juniper-optic-unlock-ex-qfx-series	deep-dive	Vendor Compatibility	Juniper EX4600 QFX5100 JunOS no-ddmi third-party optics transceiver alarms	Juniper EX QFX transceiver compatibility

Juniper has a reputation for being more open with third-party transceivers than Cisco, and in broad strokes that's accurate. But "more open" doesn't mean "consistent," and the differences between the EX and QFX product lines on this front have burned enough engineers that it's worth a detailed examination. A transceiver that initializes cleanly on a QFX5100 and passes DOM data without complaint can generate persistent alarm logs on an EX4600, even when the optical performance is identical.

The Source of the Divergence: Different Chassis Management Paths

The QFX series and EX series share JunOS as their operating system, but the underlying chassis management frameworks differ significantly. QFX platforms—particularly the QFX5100, QFX5110, and QFX5200—use a stripped-down chassis management daemon that was designed with data center density in mind. Third-party transceiver support was treated as a practical necessity early in the QFX product lifecycle, partly because the hyperscale data center customers buying these platforms demanded it.

EX platforms, particularly the EX4600 and to some extent the EX4300 series, carry more of the enterprise-grade chassis management heritage from the EX4200 and EX8200 lineage. The chassis daemon on these platforms performs additional validation steps when a transceiver is inserted. In particular, it checks the EEPROM vendor fields against a soft compatibility list and, depending on JunOS version, will raise a XCVR_UNSUPPORTED or XCVR_DOM_UNSUPPORTED alarm for any transceiver not in that list—even if the port comes up and traffic passes normally.

Specific JunOS Version Behavior

On JunOS 18.x running on EX4600 hardware, the behavior is: unrecognized transceivers initialize, the port goes up, but the chassis daemon logs repeated alarms of the form:

CHASSISD_XCVR_MODULE_UNSUPPORTED: FPC 0 PIC 0 PORT 1: Unsupported optics

These alarms don't take the port down, but they fire every few minutes, and on a switch with 48 ports of third-party optics, the syslog volume becomes operationally disruptive.

On JunOS 20.2R3 and later, Juniper introduced more granular alarm suppression for the EX4600, and the frequency of these unsupported-optics alarms decreased substantially. On JunOS 21.4 and 22.x, the behavior on EX4600 more closely approximates the QFX5100 behavior: the alarm fires once at insertion time and is then suppressed unless the optical parameters go out of range.

On QFX5100 running the same JunOS version as an EX4600, the unsupported-optic alarm typically fires once and doesn't repeat, because the QFX chassis daemon's alarm re-evaluation timer is set much longer. This is documented nowhere obvious—you discover it by comparing syslog archives from both platforms.

The no-ddmi Workaround

Juniper provides a configuration knob specifically for third-party optics:

set chassis no-ddmi-information-polling

Or, for per-interface suppression (available on some platforms and JunOS versions):

set interfaces xe-0/0/1 optics-options no-alarm

The no-ddmi-information-polling command at the chassis level tells JunOS to stop polling DDMI (Digital Diagnostics Monitoring Interface) data from all transceivers. This eliminates the alarm-generation cycle because the chassis daemon never fetches the data that triggers the unsupported-module check.

The tradeoff is significant: you lose all DOM visibility across the entire chassis. Temperature, TX power, RX power, bias current—none of it appears in show interfaces diagnostics optics. For a 48-port ToR switch where you're relying on DOM data to catch degrading optics before they cause an outage, this is a meaningful operational sacrifice. We generally recommend against no-ddmi-information-polling as a blanket solution; it's a blunt instrument that trades one problem for another.

The per-interface no-alarm option is more surgical, but it's only available in JunOS 20.x and later, and its behavior differs between EX and QFX platforms. On QFX5100, no-alarm suppresses the DDMI-related alarms but preserves DOM data visibility. On EX4600 running pre-21.4 JunOS, the same configuration option suppresses alarms but also disables DOM polling on that interface, which is the opposite of the intended behavior.

DOM Data Discrepancies Between EX and QFX

There's another subtle difference: the DOM data resolution. QFX5100 presents DDMI data in the standard SFF-8472/SFF-8636 floating-point format with full precision. EX4600, particularly on pre-20.x JunOS, rounds some DOM values to integer precision in its internal representation before displaying them. This means a transceiver measuring -3.2 dBm RX power shows as -3 dBm on the EX4600 and -3.20 dBm on the QFX5100.

This matters in practice for threshold alarm evaluation. If your low-warning threshold is set to -3.0 dBm and actual RX power is -3.1 dBm, the QFX triggers a warning alarm while the EX4600 doesn't—not because the optical power is different, but because of integer rounding in the EX's DOM display path.

What the EEPROM Needs to Say

For transceivers targeting Juniper EX platforms specifically, the EEPROM programming needs to be more careful than for QFX. The Vendor Name field (SFF-8636 bytes 148–163) must match a known-good string. Juniper's internal compatibility check is primarily against the Vendor OUI (bytes 165–167, the IEEE OUI) and a soft-match on the Vendor PN. A properly Juniper-coded QSFP-28 should have the Vendor Name field set appropriately and the Vendor OUI matching the registered OUI of the transceiver manufacturer or the coded-for OUI in Juniper's list.

The Extended Specification Compliance byte (SFF-8636 byte 192) must also be set correctly. For 100GBASE-SR4, this byte should be 0x01. Leaving it at 0x00 or setting it to an application-specific value that Juniper doesn't recognize will cause the EX4600's chassis daemon to categorize the transceiver as "undefined," which triggers more aggressive alarm behavior than a recognized-but-unlisted optic.

Which Platforms Are Actually Consistent

If you're deploying in a mixed EX/QFX environment and want consistent third-party optic behavior, the QFX5110 and QFX5120 are the most predictable on current JunOS (22.x/23.x). Both platforms have received the most attention in terms of third-party optic compatibility updates, and the chassis daemon behavior on these platforms more closely resembles the documented specification.

EX4300-48MP and EX4400 series behave better than the EX4600 on this front, partly because they run a newer chassis management stack. If you're stuck with EX4600 hardware and can't upgrade JunOS past 18.x for some platform-compatibility reason, the practical answer is to accept the alarm noise, filter it in your SIEM, and verify optical performance via periodic manual DOM polling rather than relying on automated alarm escalation.

The fundamental issue is that Juniper's product line spans hardware that was designed over roughly a 15-year period, and "consistent third-party optic support" was retrofitted onto platforms that didn't originally prioritize it. The EX4600 in particular was designed when Juniper's position on third-party optics was more restrictive than it is today. What you're seeing when an optic works on QFX5100 but alarms on EX4600 is that history playing out in your syslog.