Zyxel RGS200-12P print "% SFP module doesn't support DDMI" voor twee Avago-SFP's
We leveren industriële kasten op met eigen monitoring van de klant erbovenop, dus leesbare DDMI op de uplinkpoorten staat op de acceptatielijst. Op een RGS200-12P weigeren de twee poorten die ertoe doen na het inschakelen van DDMI compleet iets te printen, ook al staan beide links gewoon op en wordt er geforward.
- Zyxel RGS200-12P, DDMI ingeschakeld
- poort 1/9: AVAGO ABCU-5740RZ-HP8, 1000BASE-T koperen SFP
- poort 1/11: AVAGO AFBR-5710PZ, 1000BASE-SX
- beide links op, schone counters aan weerskanten
% SFP module doesn't support DDMIWat ik al gedaan heb:
- DDMI uit- en weer aangezet, opgeslagen, switch herladen
- beide modules opnieuw gezet en naar andere cages verplaatst - op elke poort hetzelfde antwoord
- geverifieerd dat de links zelf gewoon goed zijn, verkeer loopt zonder fouten
Dus wat is het: weigert de switch optiek te lezen die hij niet zelf verkocht heeft, of hebben twee Avago-onderdelen gewoon geen diagnostiek om af te geven? Ik moet de klant vóór de oplevering het ene of het andere antwoord geven, geen schouderophalen.
Show original (English)
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
Er zitten twee verschillende oorzaken achter die ene foutmelding.
De koperen poort doet precies wat je mag verwachten. 1000BASE-T-SFP's implementeren als klasse geen digitale diagnostiek: er is geen optisch vermogen te rapporteren en die onderdelen dragen doorgaans geen diagnostiekpagina, dus 1/9 met de ABCU-5740RZ-HP8 zal nooit temperatuur, spanning of vermogen tonen, hoe DDMI ook is ingesteld. Niets te herstellen, niets te escaleren.
De glasvezelpoort komt op hetzelfde resultaat uit, maar om een andere reden: dat specifieke Avago-onderdeel heeft geen DDM/DDMI-pagina in zijn EEPROM. SFF-8472 maakt de diagnostiekpagina optioneel, en genoeg 1000BASE-SX-modules uit die generatie zijn zonder verscheept. De switch blokkeert hier geen vreemde module, hij meldt gewoon de waarheid: er staat niets in de module om uit te lezen.
De test die het in vijf minuten beslist is degene die al is voorgesteld: een module die in dezelfde cage als DDM-capable bekendstaat. Een Zyxel SFP-LX-10-E in een RGS200-12P print het complete DDMI-blok, wat bewijst dat de switch en de configuratie in orde zijn. Gebruikelijk voorbehoud bij deze fabrikant: hun officiële standpunt is dat optiek van derden niet gedekt is en pakketverlies en connectiviteitsproblemen kan geven, dus als diagnostiek een acceptatiecriterium is, zet "DDM/DOM capable" in het inkoopbestek in plaats van erop te hopen.
Als de optiek in deze kast niet vervangen kan worden, monitor die twee poorten dan op linkstatus en interfacecounters en zet dat zo in het opleverdocument. Dat is een eerlijk antwoord, en het is beter dan een lege DDMI-pagina die over een jaar niemand meer kan verklaren.
Twee dingen om uit elkaar te houden voordat je iets opschrijft. Ten eerste: print die switch DDMI überhaupt voor wat dan ook? Leen een module waarvan je weet dat hij DDM-capable is, zet hem in 1/11 en draai hetzelfde commando. Komt er een volledig blok uit, dan is de switch-kant bewezen en blijven de twee Avago-onderdelen de enige overgebleven variabele.
Ten tweede: behandel de koperen module niet als bewijs in welke richting dan ook, dat is een categorie apart. En wat zegt het datasheet van de AFBR-5710PZ eigenlijk over digitale diagnostiek? Dat onderdeel is oud genoeg dat ik er niet van zou uitgaan dat hij die sowieso heeft.
Bevestigd op de testbank. Een SFP-LX-10-E geleend, in 1/11 gezet met dezelfde vezel, en DDMI print de volledige set: temperatuur, spanning, bias-stroom, Tx- en Rx-vermogen. De AFBR-5710PZ er weer in en de foutmelding komt meteen terug. Poort 1/9 met de koperen module gedraagt zich precies als voorheen, wat ik nu gewoon verwacht in plaats van erachteraan te blijven jagen.
Dus de switch doet gewoon zijn werk en de modules zijn het antwoord. Het gaat als module-eigenschap in de oplevering, en DDM-capability gaat in het bestek voor de volgende batch optiek. Dat scheelde me een discussie over een "kapotte" switch.
Goed om te weten dat dezelfde situatie per platform compleet anders overkomt, en dat is precies waarom het steeds weer als bugreport terugkomt.
Op PAN-OS print
show transceiver-detail allper module een velddiagnostic-monitor:Yesbetekent dat optische monitoring is geïmplementeerd,Nobetekent van niet, en in dat tweede geval wordt de module gewoon normaal herkend terwijl elke diagnostiekwaarde alsN/Aterugkomt. Geen fout, gewoon lege velden: veel makkelijker te interpreteren dan een weigeringsstring.Op een Nokia 7210 SAS kunnen de ontbrekende waarden juist aan de software liggen: vroege releases implementeren DDM helemaal niet, en de documentatie voegt toe dat voor modules die Nokia niet zelf heeft geleverd de data misschien wel getoond wordt, maar zonder garantie op opmaak of nauwkeurigheid. Drie mogelijke veroorzakers voor één leeg veld: module, platform of release.
En soms is het alleen de interface: op TP-Link-switches die in Omada zijn geadopteerd zit er geen DDM-pagina in de controller, dan open je de terminal ervan, typ je
enableen draai jeshow ddm status.