QSA adapter in a SONiC QSFP28 cage: the 10G optic links but reports no DDM
We are reusing a pile of 10G optics on a whitebox switch running SONiC, so a few QSFP28 cages are fitted with QSA-style adapters (10GTek QSA-100A) carrying plain 10G SFP+ modules. Mechanically and electrically this is fine. The management side is where it falls apart.
- switch: 1U whitebox, SONiC built for that platform
- adapters: 10GTek QSA-100A, QSFP28 cage to SFP+
- optics: 10G SFP+ modules pulled from a decommissioned access switch
- the same optics read normally in a native SFP+ cage on another box
What I see on the adapted ports:
QSFP28 cage -> QSA-100A -> 10G SFP+
link: up, traffic passes
inventory: port still handled as a QSFP cage
DDM/DOM: nothing returned for the portTried so far:
- swapped in a second adapter and a second optic, identical behaviour;
- moved the pair to a different QSFP28 cage, same result;
- verified the optics report full diagnostics in a native SFP+ port elsewhere.
Is the missing diagnostics data something a passive adapter simply cannot carry, or is this on the switch software side? And if it is software, where does the fix belong: the platform layer or the generic transceiver code?
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
Before anyone digs into platform code, one question that splits this in half. Put a native QSFP28 module into that same cage: do you get diagnostics out of it, or is DDM dead on that port no matter what you plug in?
If the native prat reads fine, the cage and the I2C path are healthy and the whole thing comes down to how the port driver interprets what arrives through the adapter. If the native part comes back blank as well, stop reading the rest of the thread, you have a different fault and it has nothing to do with adapters.
Well known and fairly boring difference in the management interface, and the adapter is not the guilty party here.
On the SFP side two I2C addresses are in play: identification data lives at 0x50, the diagnostics map at 0x51. A QSFP part keeps the lot under 0x50 and reaches the rest by switching pages. So a driver that has been told the cage is QSFP goes hunting for pages at a single address and never asks 0x51 anything. Identification comes back plausible enough for the port to come up, diagnostics simply never resolve, which is exactly the shape of what you posted.
The fix belongs in the platform layer, not in the optic and not in the adapter. Every platform ships its own SfpUtil implementation; in yours that port has to be declared an SFP cage instead of a QSFP one. Until someone does that, DDM/DOM on adapted ports stays empty. Afterwards the module is read the way it would be in a native SFP+ cage.
A live link with nothing behind it in the diagnostics is what wrong software looks like on these ports. It is not what a marginal optic looks like.
Worth naming the standards, because then the split is obvious. The SFP side is SFF-8472, where diagnostics live in their own memory map reached at the second address. QSFP and QSFP28 follow SFF-8636, and newer parts CMIS, where everything hangs off a single address behind a page select.
The adapter cannot bridge that. It is a passive mechanical and electrical part, the management wires run straight through it and nothing translates them on the way. So the host has to be told which of the two memory models applies before it reads a single byte, and the adapter has no way of telling it.
For contrast, the same class of problem on Dell ONIE hardware bites harder. A 407-BBRO QSA with a 407-BBOU 10GBASE-SR SFP+ inside (SFP-10GSR-85), in the 40G ports of an S4048-ON and in any port of an S6010-ON, both running OpenSwitch OPX 3.1 dev2:
opx-ethtool identifies the media correctly, marks the transceiver enabled and qualified, admin state up, supported speeds 1000, 10000 and 40000 Mbps, and the port still never comes up, whatever speed, duplex or autoneg is configured, defaults included. Someone opened it on the OPX platform-config repository as an enhancement request, please make the QSA work here, and nobody ever answered. It is still sitting open.
Not a vendor lock and not a bad optic. That cage is simply never put into adapter mode by the network OS, and no combination of interface settings will do it for you.
Related, but pease do not fold the two cases together. What the original post has is a working link with missing diagnostics: the data path is fine, only the management read is wrong, and patching the platform SfpUtil fixes it. The Dell case is a port that never comes up at all, because the port profile for that cage is never applied to begin with. That sits one layer down and needs its own fix.
Someone matching symptoms in a hurry could burn a day rewriting transceiver code while their port is down for an entirely unrelated reason.
Another flavour of "the adapter is a software feature" rather than a mechanical one. On a Z9264F-ON under OS10 10.5.2.7, using QSA28 adapters for 10G SFP+ media means putting the port into the same port-group profile that a 4x10G breakout cable uses:
Port-group profiles on that platform act on pairs of QSFP28 ports, so applying it disables the partner port of every pair. A QSA28 is a single interface and you still pay a breakout-shaped price: 64 usable ports become 32. Neither the OS10 user guides nor the Dell optics spec sheet document a single-port QSA mode.
If you need a lot of native 10G on that box, plan for the 2:1 loss up front or put a separate 10G switch in the rack.
Before anyone orders a tray of these things, I would put two checks on the list. Does the network OS declare QSA support for that exact platform at all, and if it does, what does turning it on cost you: ports, diagnostics, or a profile that drags the neighbouring cage down with it. Fit is never the issue, every one of these adapters goes into the cage without complaint.
The cases in this thread differ only in how far the software goes. On SONiC you get something you can fix yourself, declare the port as SFP and the diagnostics come back. On the Dell platforms above you are waiting on someone else's platform code, and swapping adapters or optics will not move that at all.