Zyxel RGS200-12P prints "% SFP module doesn't support DDMI" for two Avago SFPs
We hand over industrial cabinets with the customer's own monitoring on top, so readable DDMI on the uplink ports is part of the acceptance list. On an RGS200-12P the two ports that matter refuse to print anything at all after DDMI is enabled, even though both links are up and forwarding.
- Zyxel RGS200-12P, DDMI enabled
- port 1/9: AVAGO ABCU-5740RZ-HP8, 1000BASE-T copper SFP
- port 1/11: AVAGO AFBR-5710PZ, 1000BASE-SX
- both links up, clean counters on either side
% SFP module doesn't support DDMIWhat I have already done:
- turned DDMI off and back on, saved, reloaded the switch
- reseated both modules and moved them into other cages - same answer on every port
- verified the links themselves are fine, traffic passes without errors
So which is it: the switch refusing to read optics it did not sell, or two Avago parts that genuinely have no diagnostics to hand over? I need to give the customer one answer or the other before the handover, not a shrug.
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
You have two different causes hiding behind one error string.
The copper port is expected behaviour. 1000BASE-T SFPs as a class implement no digital diagnostics - there is no optical power to report and those parts generally carry no diagnostic page, so 1/9 with the ABCU-5740RZ-HP8 will never show temperature, voltage or power no matter how DDMI is configured. Nothing to fix, nothing to escalate.
The fibre port is the same outcome for a diffeernt reason: that particular Avago part has no DDM/DDMI page in its EEPROM. SFF-8472 makes the diagnostics page optional, and plenty of 1000BASE-SX modules of that generation shipped without one. The switch is not blocking a foreign module here, it is reporting the truth - there is nothing in the module to read.
The check that settles it in five minutes is the one already suggested: a module specified as DDM-capable in the same cage. A Zyxel SFP-LX-10-E in an RGS200-12P prints the complete DDMI block, which proves the switch and the configuration are fine. Usual caveat with this vendor: their stated position is that third-party optics are not covered and can bring packet loss and connectivity problems, so if diagnostics are an acceptance criterion, put "DDM/DOM capable" into the purchase spec instead of hoping.
If the optics cannot be changed on this cabinet, monitor those two ports by link state and interface counters and say so in the handover document. That is an honest answer, and it beats an empty DDMI page that nobody can explain a year later.
Two things worth separating before you write anything down. First, does that switch print DDMI for anything at all? Borrow a module you know is DDM-capable, put it in 1/11 and run the smae command. If a full block comes out, the switch side is proven and the two Avago parts are the only variable left.
Second, do not treat the copper modle as evidence either way, it is a category of its own. And what does the datasheet for the AFBR-5710PZ actually say about digital diagnostics? That part is old enough that I would not assume it has them at all.
Confirmed on the bench. Borrowed an SFP-LX-10-E, dropped it into 1/11 with the same fibre, and DDMI prints the full set - temperature, voltage, bias current, Tx and Rx power. Put the AFBR-5710PZ back and the error string returns immediately. Port 1/9 with the copper module behaves exactly as before, which I now expect instead of chasing.
So the switch is doing its job and the modules are the answer. It goes into the handover as a module property, and DDM capability goes into the spec for the next batch of optics. That saved me an argument about a "broken" switch.
Worth knowing that the same situation reads completely differently depending on the platform, which is why it keeps coming back as a bug report.
On PAN-OS,
show transceiver-detail allprints adiagnostic-monitorfield per module:Yesmeans it implements optical monitoring,Nomeans it does not, and in the second case the module is still identified normally while every diagnostic value comes back asN/A. No error, just blanks - much easier to interpret than a refusal string.On a Nokia 7210 SAS the missing values can be the software instead: early releases do not implement DDM at all, and the documentation adds that for modules Nokia did not supply the data may be displayed but its formatting and accuracy are not guaranteed. Three possible owners for one blank field - module, platform or release.
And sometimes it is only the interface: on TP-Link switches adopted into Omada there is no DDM page in the controller, you open its terminal, type
enableand runshow ddm status.